Git Add Interactive
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:
- Run
git status - Run
git diff, and try to remember which files should be part of this next commit - Use
git addto get those files added. If only part of a file is needed, usegit add -p - Now
git commitand 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:
- Run
git status(this is just a nervous tic, I do it when I’m thinking) - Next, do
git add -pand stage anything that is relevant to the thought you were just having - Now
git commitand 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”!
Pingback: Git Add Interactive | Advanced PHP | Scoop.it
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.
Hey Lorna Jane,
Why not have the best of both worlds?
2. Next, do [code]git add -p[/code] and stage anything that is relevant to the thought you were just having
-3. Now [code]git commit[/code] and write a note to future Lorna in the commit message
+3. Run [code]git stash –keep-index[/code], build and test.
+4. If everything runs to your liking, run [code]git commit[/code] and write a note to future Lorna in the commit message