I frequently switch machines while I'm in the middle of work that I'm not quite ready to commit. Normally I just commit with a sheepish
(WIP) appended as a mea culpa to future repo archaeologists, push the changes, and pull them down on the second machine.
I'm not a Git history purist, but committing in-progress work always feels kind of scritchy — especially on projects where I'm not the only developer.
After years and years of using Git, I recently learned there's built-in way to achieve the same result without building up a bunch of Git history detritus.
Create and apply patch files
On the machine that has your work in progress, run the following from the root of the project:
git diff --patch > ~/Downloads/wip.patch
~/Downloads with whatever path makes the most sense for you; any directory will do)
This generates a
diff-formatted file called
wip.patch that describes all changes to any existing files:
diff --git a/src/site/_includes/layouts/base.njk b/src/site/_includes/layouts/base.njk index d8ce3de..bc99254 100644 --- a/src/site/_includes/layouts/base.njk +++ b/src/site/_includes/layouts/base.njk @@ -1,4 +1,5 @@ <!DOCTYPE html> +<html lang="en"> +<head>
Untracked files — that is, files that have never been committed to the repo — aren't included in
git diff by default. If you have in-progress work in new files, you can include those in the diff with Git's “intent to add” flag (
git add -N <file_1> <file_2>
prior to running the
git diff --patch command above.
wip.patch patch file has been generated, transfer it to the second machine. I'm switching between two Macs, so AirDrop is my go-to method.
Finally, run the following command from the root of the project on the second machine:
git apply ~/Downloads/wip.patch
~/Downloads with the path to wherever the
wip.patch file landed on the destination machine.)
That's it! Work from the first machine is now on the second machine, without any
WIP (sorry!!) commits besmirching your beautiful Git history.