Code reviews reduce logical errors, call out typos, and prevents accidentally committing more code than intended (1). They're essential for all sized teams pushing to the same code base while maintaining sanity.
Should a developer find themselves discovering any accidental "oops!" in their pull request it's a good indicator of a flaw in workflow. Introducing the interactive self code review:
git add --interactive
Interactive adding in git offers a choose-your-own-adventure style "What Now>" series of options.
The Useful Bit: Git Patch
Today let's look at the patch option. We can skip to the patch option in the future with this handy shortcut:
Example pretends we have file.ext and have added a line that defines a version...
git add -p
diff --git a/file.ext b/file.ext
index sha1..sha2 sha3
-- a/file.ext
++ b/file.ext
{
"name": "example json",
+"version": "1.0.0",
"private": true,
Stage this hunk [y,n,q,a,d,/,e,?]?
Looks like a huge chunk of stuff! Broken down, the response describes what file was modified followed by a chunk of color coated git diff.
Now What? Staging Hunks of Code
Many options are provided in the "Stage this hunk?" prompt following a git add patch.
Pressing ? in response to the prompt explains each valid response. These are some essentials:
- y - stage this hunk
- n - do not stage this hunk
- q - quit
You'll find that by going through this process you can read every line you'd like to add to a commit and make better choices about them.
Splitting s
These "magical" feeling chunks aren't always smart enough. Sometimes there's a need to split (with the s response) a chunk into smaller chunks. This comes up more often than you'd think if you're developing empathetically.
a Add or d Don't Add Entire File
An a response will stage the current hunk and all the following within the current file automatically. This is not recommended because you're opting to skip parts of your personal code review.
However, d is a nice way to skip adding anything from an entire file and can save a lot of time.
Manually Editing
Typos or "oops!" can be quickly corrected with the e response. This will open just the chunk for quick adjustments including line adding and removal.
Summary
Git patch has become a core part of my workflow to ensure quality and boost personal confidence in the code I ship. Give it a try today!
Top comments (5)
The
:Gdiffcommand in tpope/vim-fugitive is really handy for this too (see also vimcast 32. I've seen magit for emacs do similar things, too. Really useful for making sure you don't put in any unnecessary changes into a commit after a furious bout of writing. And for splitting an otherwise-too-big set of changes across logical commits.Neat way to automate something I usually do manually. Usually I do something like
git diff -w master > tmp/diffs.txt(orhg diff -r default > tmp/diffs.txt), and examine that, both looking for things that shouldn't be there (like debugging calls and such) and to compose a detailed pull request description. (Sometimes I'll also do this before an individual commit.)I've been completely hooked on SourceTree because it facilitates this way of staging content by default.
It works so well that I've completely abandoned
git add -p(which was my default), and I'm having a hard time using magit in emacs because of SourceTree. When I'm sorting out a smaller set of changes into separate commit, I can still get away with magit.I do prefer magit for interactive rebasing though, which I do often when I inevitably forgot to stage a hunk in a previous commit.
True. But please, be aware, that when you commit only portions of what you've changed, it will be probably the code that you've never actually tried to compile or run or test. And there's no guarantee, that this particular state of code is good. So it is very nice to have some kind of CI server running in the background to catch this kind of problems
I do that, very useful. You can also 'git add -N file' with new files, it adds their existence but not their content, so the latter appears in git diff and git add -p.