Git Cheatsheet(s)

Setting Up

Before starting to use git one should take the few minutes to set it up.

Set up your personal information that will end up on your commits:

git config --global user.email <your-mail@example.org>
git config --global user.name "<Name>"

Set the default branch name to main instead of master The reasons I do this are because there was some controversy around the word "master" in this particular context and and I quickly realised that "main" is way easier to type.

git config --global init.defaultBranch main

You could set your editor for git commit messages (and other git features) using:

git config --global core.editor <editor-command>

If you (like me) have one editor you want to use for everything: Set the EDITOR variable in your ~/.profile and git along with a whole range of other programs will pick up on that.

Partial Adding

Situation: You have made changes to one file but they should be in two different commits.

git add -p [<file>]

git will then chop up the changes into hunks and ask interactively if you want to add/stage (y) a change, ignore/not stage it (n), further subdivide (s) or even edit (e) it. You can use ? to get summary of all options currently available.

Undoing Things

Undo last Commit

Situation: You just made a git commit but you committed too much by accident.

Note: If you just messed up the commit message or need to add changes use git commit --amend.

git reset is your friend here, without any arguments it helps when you git added too much, it makes git go into the state it was in at the last commit.

git reset HEAD^1

The HEAD^1 resets git to the parent commit of the last commit. Effectively acting as if the last commit never happened. (You can still recover it using the revlog)

git reset will only change your git history, not the files you have currently checked out so when using it as described above you won't loose any changes.

Warning: git reset --hard is intended to throw changes away and it is possible to loose uncommitted data when using it with the --hard flag enabled.

Restore File from last Commit

Situation: You messed up a file and want to throw away the changes since the last commit.

git restore <filename>

This is less destructive than git reset --hard which throws away all your changes in a repository since the last commit.

Shallow clone

Situation: You have a very large git repository and limited time and/or bandwidth and only need the latest few commits.

git clone --depth 3 <url>

This example will only fetch the last 3 commits of the main upstream branch.

Shallow fetch

In case you need additional branches:

git fetch --depth 3 origin <branch>
git switch --detach FETCH_HEAD
git switch --create <branch>

After that you can use all branches you fetched as usual

Fetching additional Branches

Sometimes you don't get all branches you need with a regular pull, assuming you want to fetch the branch example from origin and use it.

# fetch the branch
git fetch origin example:example
# switch to it
git switch example

You may have noticed that example is mentioned twice in the fetch command, that is because the syntax is {remote branch name}:{local branch name} where you have the opportunity to rename your local branch should you need it (i.e. when working with multiple upstream repositories).

Detecting changes in scripts

To detect any differences of the working tree to the last commit in shellcripts you can use git status --porcelain=v1 which outputs a machine readable summary of the changes or nothing at all if there are no changes.

To only detect changes to files already checked into git, but not new files or changes you have already staged (TL;DR only changes that git diff would show) for the next commit you can use git diff --quiet which exits with a scess exit code when there are no changes and fail if there are changes.

Throwing away changes

To get back to the state that is stored in the last commit you can use the following commands.

Warning, destructive commands: These commands arre destructive and you can throw away quite a bit of work with no way to restore it. Use them with care. For a non-destructive version have a look at git stash.

To revert files already checked into git to their original state if they were altered or deleted you can use git restore <path> where path is a path to a file or whole directory.

To remove new files that are not checked in (git stauts shows them as "Untracked files") you can use git clean -f <path>, here too, the path argument can point to a file or a directory to operate on.

These commands can be useful if you had all changes checked in and a failed build made a mess of your git worktree.

Other Peoples Git Guides

These are guides made by other people that I think are useful.

In My unorthodox, branchless git workflow Drew DeVault explains how to make use of the fact that the git history of a repository isn't set in stone, I mainly use these tricks to completely avoid a lot of merge conflicts in my personal projects.

Learn to change history with git rebase! is Drew DeVault's cheatsheet for altering git history in general and the rebase based workflow in the blogpost liked above.

In Dealing with diverged git branches Julia Evans explains how to deal with the situation that changes happend on both the local and remote git repository. (She explains it better than I do here.)

Ein kurzer Blick in .git/ is a talk held at DiVOC in 2020 by Florian Hars diving into the .git directory, unfortunately no one has translated it to English yet.

Inside .git is a blogpost by Julia Evans that also dives into the .git directory and explains what is inside.