Joe L. Wroten
An edge riding web tech architect aimed at realizing the best tools to communicate valuable information to the people who need it.
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.
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.
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:
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.
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 FileAn 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.
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.
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!
The
:Gdiff
command 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.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.