Recently, I’ve been doing some semi-experimental UI work, where I know what changes I need to make but some of the details aren’t clear to me. So, I end up making the changes, but I’ve changed more files than I want to include in a single commit. Using git, there are a few different ways to pick and choose which changes should be staged for a commit. One of the most common methods I use goes like this:
- make changes
- stage some of the changes for commit (using
- reviewing the staged (added) changes
- making the commit
In this post, I am briefly going to explain how I do step #3 above, “reviewing the staged (added) changes”.
Basically, if I have just staged changes using
git add, then a normal
git diff won’t show me those changes. It will only show me the changes that have not been staged. So, I add the
git diff --cached
…and, voila! I can see the diff of the changes that are currently staged for commit.
If you are new to git, this is how you can scroll up and down, and exit the diff, using the following keyboard shortcuts:
- j scroll down
- k scroll up
- q quit
So, if I’m satisfied with the changes, I can go ahead and commit:
git commit -m 'my commit message'
…or, if I realize that the changes should not be combined, I can “un-stage” them:
git reset HEAD .
From the official docs:
This form is to view the changes you staged for the next commit relative to the named