DEV Community

Joe L. Wroten
Joe L. Wroten

Posted on • Originally published at wrotenwrites.com

Self Code Review with Git Add Patch

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)

Collapse
 
apiarian profile image
Aleksandr Pasechnik

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.

Collapse
 
davearonson profile image
Dave Aronson

Neat way to automate something I usually do manually. Usually I do something like git diff -w master > tmp/diffs.txt (or hg 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.)

Collapse
 
kennethkalmer profile image
Kenneth Kalmer

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.

Collapse
 
voins profile image
Alexey Voinov

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

Collapse
 
oscherler profile image
Olivier “Ölbaum” Scherler

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.