Working with git

Useful hints

Aliases

Aliases are a handy way to simplify the commands needed for your own common tasks. For example, you could add a "what's upstream" command to easily find out which commits will be pulled

 git config --global alias.wu '!sh -c "git fetch && git log origin..HEAD"'

From now on, just run

 git wu

and it will list the commits which would be merged in by a pull. Similarly, it can be useful to have a "what's downstream" command to know which commits would be pushed:

 git config --global alias.wd "log origin..HEAD"

Another useful example is if you often find yourself wanting to do the stash-pull-pop sequence, you could create an alias for that:

 git config --global alias.sp '!sh -c "git stash && git pull --rebase && git stash pop"'

Easy rebasing with mergetool

Rebasing is mostly painless with git. The only problem arises when there is a conflicting commit and you have to manually intervene. In this case, the mergetool command can be invaluable:

 git mergetool

This will present a diff utility (opendiff on Mac OSX) which allows you to easily select which changes you want. Once you have finished, save and quit, then run

 git rebase --continue

If you want more manual control, edit the conflicting files manually and get them how you want them. Make sure to add them:

 git add <conflicting-files>

and then continue the rebase:

 git rebase --continue

Remove files unknown to git

Sometimes you just want to get rid of all files which aren't under version control. For this use the clean command. First, run

 git clean -n

to do a dry-run and see what will be deleted. If you're happy with this change, run

 git clean -f

to actually get rid of the files.

Oops, I didn't mean to do that

Don't worry if you accidentally do an operation which you didn't intend to do. It can usually be recovered. For this, the reflog command can be very useful. It essentially lists all recent operations. For example, say you accidentally deleted the last commit using reset and now you realise that you actually do want it after all. Simply run

 git reflog

and find the SHA1 of the commit you want in the list, then cherry-pick that commit

 git cherry pick <commit-sha1>

Aargh, I made a total mess

It can happen that you get your repository into a hopeless mess and just want to get it back to its original state, disregarding all local changes. This can be achieved using the -f option to checkout

 git checkout -f HEAD

This will throw away all local changes and will bring your repository back to the state it would be in if you freshly checked it out (with the exception of files which aren't under version control).

Saving credentials in your keyring

Git will ask for credentials when it needs to authenticate itself against a server to push/pull changes. By default it will ask for credentials each time it needs access which can be cumbersome. The usual solution is to use ssh public key based access and add the key to the keyring managed by ssh-agent (or equivalent). For https based access this does not work and one can instead use git's credendtial helpers introudced in version 1.7.9 (man page or bitbucket tutorial). A simple approach that mimics what svn does is to cache the credentials in memory for a while:

 git config --global credential.helper cache
 git config --global credential.helper 'cache --timeout=3600'

A more comprehensive approach would use gnome-keyring (source code only, included in git 1.8.0) or osxkeychain or an encrypted .netrc file.