I have a habit of constantly making minor edits to my code whenever I spot something I don't like - be it a bug or just some sloppy piece of code I see how to improve. Neurosis-Driven Development.

The problem is this habit doesn't work well with VCS. I can be working on a new function and, by the time I finish it, I have 10 unrelated edits in different parts of the code (usually in the same file). I am left with three options:

  • Every time I want to make a minor edit, switch to work branch, commit the progress, switch to master, make the minor change, commit, switch back to work.
  • Feel free to edit as much as I want, then commit everything together. But mixing conceptually different edits in one commit is a bad practice.
  • Same as above, but when the time comes for the big commit, try to disentangle the edits with tools like git add --patch and commit them separately

Any of these options makes me want to give up on VCS whatsoever. Is there a fourth option I don't see or is one of the above not as bad as it sounds?


2 Answers 2


Use git add --patch right after you make the change. Make many small commits whenever you have a meaningful step. Later you can rebase and squash related commits together. It's far easier to use rebase to merge multiple commits into one than it is to split one diff to multiple commits.

  • I agree, but: I would not squash all commits together in the end. New implementations and changes should be separate commits from drive-by changes (they should be marked with a clear naming scheme, IMO). There are two reason not squashing "live" changes with drive-by changes: "in the now", if applicable, such a commit is hard to review, in the future it would be harder to understand why a change was made (or what the change actually indended to change) Apr 13, 2016 at 22:02
  • @try-catch-finally I don't suggest merging unrelated changes, but if one logical change spans multiple commits (ie, "add a; fix bug with a"), they can be squashed into one commit ("add a").
    – Daenyth
    Apr 13, 2016 at 22:24

Here is what I do:

  1. Remain disciplined, only make the changes which are applicable to the current working branch.
  2. Create a branch off of master called MyDevBranch.
  3. Create a branch off of MyDevBranch that addresses a specific functionality/feature (MyFeatureBranch).
  4. Make lots and lots of commits... Each time I finish part of a feature that addresses some certain aspect of that feature I do a commit to MyFeatureBranch (i.e. write a method, or create an unimplemented method stub).
  5. When I finish the entire feature, I will merge the MyFeatureBranch to the MyDevBranch.

This has worked for me so far, when I complete all 5 of these steps I will merge MyDevBranch to the master. Then push my master branch up to a bare repository on our server, where it merges with the existing master.

If you happen to make some changes and you don't want to integrate them right away, you can also stash the changes then pop them later on.. See this link here.

Maybe also check out this question somebody asked about stashing here.

I was the exact same way as at first, until I read more about Git and asked questions to see what others were doing.

Not the answer you're looking for? Browse other questions tagged or ask your own question.