Over a million developers have joined DZone.

Git Add Interactive

DZone's Guide to

Git Add Interactive

· DevOps Zone ·
Free Resource

Read why times series is the fastest growing database category.

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"!

Learn how to get 20x more performance than Elastic by moving to a Time Series database.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}