Wrap things up

Time to read:
2 minutes

Command summary

Subcommand	Syntax	Description
diff	git diff	Show unstaged changes
diff cached	git diff --cached	Show staged changes
patch	git diff > file.patch	Save diff as a patch file
format-patch	git format-patch -N HEAD	Generate email-ready patches from commits
apply	git apply file.patch	Apply a patch to the working directory
apply check	git apply --check file.patch	Test if a patch applies cleanly
apply reverse	git apply -R file.patch	Reverse a patch
am	git am file.patch	Apply an email-format patch and create a commit
send-email	git send-email *.patch	Send patches via email

When to use patches

Patches are most useful when:

• Blend in project workflow: If you are contribution to a project that rely on this workflow then you have no other choice than to adopt and embrasse it.
• Peer programming: Real time collaboration can encourage parallel work and sharing a patch to the one who will perform final commit and pull-request is simple and effective way to share the work.
• Sharing a quick-fix: maybe you have some fancy debug code that you want to share with the team, maybe it's just some temporary code that should not become a pull-request and should event not be merge.
• Share for validation: You want to share a code change to have it reviewed, or maybe even tested, before opening a pull-request.
• Cross-repository cherry-pick: Sometime you may need to "borrow" a commit from another repository. Then cherry-pick is not an option, but patches are reaseonable option.

When to use alternatives

• Pull requests: A more modern approach to deliver code and request feedback.
• Branches: If you do not use forks, then branches are also an alternative to manual patch files.

Patches are a very manual and opiniated tool that operates at a low-level.

They are probably not part of your daily workflow. But, as for many other subjects, knowing and understanding what they are and how they work is a significant step on your patch to Git understanding and mastery.