Git Cheat Sheet – Intermediate
This article gives a handful of intermediate level git commands and how to use them, following on from my basic git cheat sheet. They help with the following scenarios:
1. Git config better default settings
– Auto set upstream branch name
– Auto correct prompt
– Better git diff algorithm & display options
2. Search for which commit a string was added or deleted from
3. Searching for the last working commit (when you don’t know which commit introduced a bug)
1. Git config better default settings
There are a couple of things that I see very often that you can set a better default for.
Auto set upstream branch name
The first one is when you create a new branch locally and push it upstream / remotely (e.g. to github), there is always an error as you need to set the upstream branch name.
git push fatal: the current branch my-branch-name has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin my-branch-name
I don’t think I’ve ever set the upstream branch name to anything different to my local branch name, and to save you copying and pasting the above command every time, you can tell git to automatically set the upstream branch as the same name with the following:
git config --global push.autoSetupRemote
Auto correct prompt
If you make a typo with a git command, it usually guesses what you are trying to do and suggest thats option.
git addd . git: 'addd' is not a git command. See 'git --help'. The most similar command is add
We can make this much more useful by actually take this command and prompt if you’d like to use it or not, which saves you from having to type in the command or edit it again. You can set this behaviour with:
git config --global help.autocorrect prompt
and now we get this instead:
git addd . WARNING: You called a Git command named 'addd', which does not exist. Run 'add' instead [y/N]?
Better git diff algorithm & display options
Git diff shows the changes in your working directory, but there are actually 4 different algorithms that you can choose for git to create this diff, which might make what has happened a bit clearer when things are changed and moved around.
The recommended algorithm is the histogram one, which you can apply with:
git config --global diff.algorithm histogram
You can also set it to show when a line was moved (instead of it showing as deleted in one place and added in another), using:
git config --global diff.colorMoved plain
For this trivial example we moved ‘import collections’ to the top, and added ‘import os’. Before:
+import collections +import os import random import time -import collections import click
after:
+import collections +import os import random import time -import collections import click
2. Search for which commit a string was added or deleted from
During the debugging process I often need to find when a certain string or line was added or deleted from the files in repo, since I know this was the line that introduced a bug (whethere by adding or deleting).
git log -S "Your String" commit 1cc3f0bf1dab04b1bb5d30ea7b84acdb107f93fe Author: Andy <info@andypi.co.uk> Date: Mon Jan 20 11:59:28 2025 -0500 add function for marketing campaign commit 6c9a69e1c753189e95c5d394afeccc2a93521013 Author: Andy <info@andypi.co.uk> Date: Mon Nov 11 09:58:52 2024 +0000 revisions to campaign commit f82922f8c263925ac4bf8818eb4f166d5720f58f Author: Andy <info@andypi.co.uk> Date: Mon Jan 22 12:30:14 2024 +0000 campaign api changed to v2
If you don’t need the author & date you can add
--oneline
to just display the abbreviated commit name and the commit message, and add
--reverse
to display the oldest commit first (thus you can find the first point commit the string was added at):
f82922f campaign api changed to v2 6c9a69e revisions to campaign 1cc3f0b add function for marketing campaign
(Note there are also ways to search for strings inside commit messages)
3. Searching for the last working commit (when you don’t know which commit introduced a bug)
If you don’t know exactly what caused a bug (so you can’t search for a string), or exactly which commit introduced the bug, you can
use git bisect to find which commit in your project’s history introduced a bug. You use it by first telling it a “bad” commit that is known to contain the bug, and a “good” commit that is known to be before the bug was introduced:
git bisect start
git bisect bad f82922f
git bisect good 1cc3f0b
Then git bisect picks a commit between those two endpoints and asks you whether the selected commit is “good” or “bad”, and checks it out. You can then run whatever command or test you need, and see if it is working or has an error. If it works correctly, enter
git bisect good
or if not, enter
git bisect bad
Git will then reply with something like:
Bisecting: 337 revisions left to test after this (roughly 9 steps)
This process is then repeated, continuing to narrow down the range until it finds the exact commit that introduced the change, and the command will print out a description of the first bad commit.
After a bisect session, to clean up the bisection state and return to the original HEAD, issue the following command:
git bisect reset
There are various other commands you can run to visualize, and view what the state of this process is, use the man page for info:
git bisect --help
Leave a Reply