Git Add Interactive

In common with most development projects these days, I'm using git more and more. It's interesting though that the way that I use this tool just keeps on changing and evolving even after about 4 years of regular use. Today I thought I'd share a new habit that I've developed: using git's ability to stage changes interactively.

The staging area in git seemed like an irritating hurdle when I came to git from SVN. In SVN, you can only really make changes that you want to commit. With git (and other more modern VCSes), you can make all the changes your heart desires, then curate a sane series of commits out of the chaos. For a long time my commit preparation method looked like this:

  1. Run git status
  2. Run git diff, and try to remember which files should be part of this next commit
  3. Use git add to get those files added. If only part of a file is needed, use git add -p
  4. Now git commit and write a note to future Lorna in the commit message

I teach git often, which means I use it with an audience on a fairly regularly basis. I got a great question recently about adding interactively and I demoed how to do that. Since then, I found that I'm rolling the above steps together and just adding interactively by default. So now I do something that's more like:

  1. Run git status (this is just a nervous tic, I do it when I'm thinking)
  2. Next, do git add -p and stage anything that is relevant to the thought you were just having
  3. Now git commit and write a note to future Lorna in the commit message

When you're doing the interactive add, you see the same output as you do from git diff but with options to add this section, or not, or split it. I find this is a really good way of making sure you read the diff, and then only add related changes to the commit.

If there were any changes that didn't get staged, this is a good time to figure out why and do something with them, usually they just need to be a different commit because they're part of a different idea. Which means that there are basically no excuses for commits with 10 files included and the message "all of the bug fixes"!

3 thoughts on “Git Add Interactive

  1. Pingback: Git Add Interactive | Advanced PHP |

  2. But this raises the question of why you are only committing only some of your changes? That means you are working on multiple things at once and only checking in some of them. Which means that the particular batch of changes that you check in has never been built in isolation until the moment you commit. They will only be built once committed. In other words this way of working has a high chance of 'breaking the build'.

    I realize that in everyday work, one doesn't always practice feature-branching, but generally one does.

    Interested to hear your use case that involves working on multiple units-of-work on the same branch. Maybe it is not code (ie maybe it is a book or something?).

    • It's code, but perhaps I refactored an existing method to improve it while I was building a feature that used it. It's much nicer to commit those two things separately just in case either my new feature or my refactoring needs to be added/reverted independently of the other thing. To be totally correct I should complete only one thing, and then the other, but my brain doesn't always work that way. This enables me to keep it clean for committing, and to run the test suite on each commit so that if there's a breakage, I know which thing caused the issue.

Leave a Reply

Please use [code] and [/code] around any source code you wish to share.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>