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:
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…
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.
? 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.
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 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.
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!