git cheat sheet

Here is my personal git cheat sheet.

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

http://gitready.com/beginner/2009/02/02/push-and-delete-branches.html

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.

From http://www.baptiste-wicht.com/2011/06/git-tip-restore-a-deleted-tag/

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}..

http://stackoverflow.com/questions/231211/using-git-how-do-i-find-modifi...

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.

References