git cheat sheet

Here is my personal git cheat sheet.

Simple commands

Pull commits from remote repository

git pull

Will pull commits from the "origin" remote repository and merge any changes into your local repository.

git pull --rebase

Will pull commits from the "origin" remote repository and replay your local changes on top of these commits. You will not get a extra "merge commit" but it can only be used on a repo without local changes. All changes must be committed or stashed.

Branches and tags

List branches local and remote

git branch -a

Make a local branch track a specific remote branch

git branch --set-upstream localbranch origin/remotebranch

push and delete remote branches

Restore a deleted tag

This is stolen from Baptiste Wicht blog post Git Tip : Restore a deleted tag.

If you just deleted a tag by mistake, you can restore it following these steps. First, use

git fsck --unreachable | grep tag

then, you will see the unreachable tag. If you have several tags on the list, use

git show KEY

to find the tag you ate looking for and finally, when you know which tag to restore, use

git update-ref refs/tags/NAME KEY

and the previously deleted tag with restore with NAME.


Show current tag

If you have checked out a tag this command will give you the name of it.

git describe --always --tag

Diffs and patches

Changes between the index and your last commit; what you would be committing if you run "git commit" without "-a" option.

git diff --cached

No prefixes, remove the a and b directory prefixes.

git diff --cached --no-prefix 

Manage commits

Squashing Commits

To squash multiple commits into one before pushing to a remote repository you can use git-rebase. In it's simplest form and provided you want to manage all commits since last push.

git rebase -i origin

For more details see: Squashing Commits How To.

Show incoming and outgoing commits

To mimic hg incoming:

git log ..@{u}

To mimic hg outgoing:

git log @{u}..

git-svn - Bidirectional operation between a Subversion repository and git

git svn is a simple conduit for changesets between Subversion and git. It provides a bidirectional flow of changes between a Subversion and a git repository.

So when you find yourself in a project that uses subversion this is a excelent way to allow you to use git on your client.

Getting the latest updates from the remote repo

To get the latest version from the remote repo (same as svn update) you use

git svn rebase

This command requires that no local changes are present in the workspace. If you have any you can stash these away.

$ git stash
Saved working directory and index state WIP on master: 9748ed9 Did some changes
HEAD is now at 9748ed9 Did some changes
$ git svn rebase
Current branch master is up to date.
$ git stash pop
# On branch master
# Changes not staged for commit:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#	modified:   aTestFile.txt
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#	aLocalFile.txt
no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (479b130cd7b333eb41c496a5a0e1ab1ca6f4d7f6)

To automate this you can create an alias in your .git/config. The second alias is of course to automate the commit process since this also requires a workspace without local changes.

        svnpull = !sh -c 'git svn rebase || (git stash && git svn rebase && git stash pop)'
        svncommit = !sh -c 'git svn dcommit || (git stash && git svn dcommit && git stash pop)'

RCS Keywords

Most traditional version control systems do have support for keywords which is substituted by the version control system on check-out (or in some case check-in). Git does not provide this feature, since these types of substitutions does not make sense in DSCM tools like Git. Since there can be many different repositories independent of each other somebody could refer to version “1.41” of a file but your version “1.41” of that file is different.

Even though I agree with Linus on the topic of keywords.

The whole notion of keyword substitution is just totally idiotic. It's
trivial to do "outside" of the actual content tracking, if you want to
have it when doing release trees as tar-balls etc.

Some old projects really relies on them to be there and it can be a pain to remove them.

Lucky enough there is project on git hub that provides git keyword filters.


Some good aliases to put into your ~/.gitconfig

# Colour full logging
lg1 = log --graph --abbrev-commit --decorate --date=relative --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all
lg2 = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n''          %C(white)%s%C(reset) %C(dim white)- %an%C(reset)' --all