I’ve given my talk about best practices in Git a few times now, and I’ve had several people come up to me asking if I’m going to upload the slides, or “what was that one Git command again?” I thought it might be a good idea to offer a cheatsheet based on the talk to refer them to in the future. Maybe throw in some handy resources.

So here you go 🙂 There’s a lot more options to Git than this, but this is what I use daily to easily keep my commits atomic and my sanity in tact.

Here’s a quick recap of the talk. It explains atomic commits and why they’re a Good Thing™. You’ll need them for the below to help you.

Jump to: interactive rebase | stash | drop | reorder commits | reset a commit | merge two commits together | cherry-pick | stage hunks | bisect

Add changes to your last commit

Stage your changes with git add ., then amend them to your last commit with git commit --am. Edit your commit message and/or description if desired, and write the file.

Change several past commits

Go into interactive rebase with git rebase -i HEAD~5 where 5 is the number of commits you want to go back. Change pick into e for edit on any commit you want to change. Write the file. Make the changes you want to do on that commit. Continue to the next commit with git rebase --continue. It will first offer you to change the commit message and/or description, like while amending.

Stash your changes

You can stash (remove) your changes with git stash and retrieve them later with git stash apply. Very handy if you’ve made some changes that you want to add to a commit further back than your latest one.

Drop a commit

Enter interactive rebase. Simply delete the line that shows the commit you want to drop. Write the file. Done.

Change the order of commits

Enter interactive rebase. Cut the line of a commit you want to move. Paste it anywhere in the list to change the order, and write the file.

Reset a commit

Resetting a commit will remove the commit and make all its changes reappear in your working directory. Especially handy when you’ve made a quick checkpoint commit and want to organize all the changes into relevant commits. Use git reset HEAD~ to reset your latest commit. Add a number to the end to reset that many of your latest commits.

Merge a commit into the last one

This one is very handy for cleaning up messy, non-atomic commits in combination with the previous two. Enter interactive rebase and replace pick with f (for fixup). Write the file. The commit is now merged with the previous commit. squash (s) does the same, but allows you to edit the commit message and description.

Take a commit from another branch

Check out the branch that has the commit. Find the commit with git log. Copy the commit hash. Move back to your own branch. Cherry-pick the commit with git cherry-pick 887ab710ac81a5d8cf6986305e9303ae5771b602 (replace with the commit hash).

Stage a hunk of changes

Instead of staging all the changes in a file, you can stage hunks of changes separately so as to add them to their respective atomic commits. Do this with git add --patch some-file.php. Git will stop at each hunk and ask you if you want to stage it (y, n).

Other options are: – d: Don’t add this and any remaining hunks. You’re finished. – s: Split the hunk into smaller hunks.
– e: Manually edit the hunk. I rarely use this, but hey.

Find the commit that broke something

You’re a bunch of commits along and notice something’s broken along the way. You can either check out every commit separately (takes a while), or use the binary search method (takes less time). Here’s how: – git bisect start – git bisect bad 887ab710ac81a5d8cf6986305e9303ae5771b602 (replace with hash of broken commit) – git bisect good 887ab710ac81a5d8cf6986305e9303ae5771b602 (replace with hash of good commit) Git will now check out a commit somewhere in the middle. Check if it’s broken (bad) or not (good) and mark it in the same way as the last two steps. Repeat this until there’s nothing more to check. – Run git bisect reset and the hash of the commit that broke will show.

Resources

Will be added shortly. Or at some point.

Tags: git, version control Last modified: February 22, 2023