This is part 5 in my Favourite Git Commands series.

Aliases

git lg

Covered in post 2:

To add it:

git config alias.lg log --graph --pretty=format:'%Cgreen%h%Creset -%Creset %s%C(yellow)%d %Cblue(%aN, %cr)%Creset' --abbrev-commit --date=relative

git heir

Also covered in post 2:

Tells you the hierarchy of your various git branches.

To add it:

git config alias.heir log --all --graph --decorate --oneline --simplify-by-decoration

Shell aliases

For those commands you type frequently, it’s nice to have your shell alias them for you:

alias gs='git status '
alias ga='git add '
alias gb='git branch '
alias gc='git commit'
alias gd='git diff'
alias gds='git diff --staged'
alias go='git checkout '

alias got='git '
alias get='git '

Commands to use sparingly

These are commands that make it very easy to get messy code all up in your git history. And no one wants messy git history.

git commit -a

Are you sure you want to commit every single line? Really really sure? If you’re going to do this always always do a git diff beforehand to make sure silly changes haven’t made their way in. Probably better to use git add --patch and then just git commit though, as discussed in post 1.

git add -A

Really? All?! Be a little selective!

Pushing and pulling

git push --set-upstream [remote] [branch]

Want git push to just work? Just do one push using the above syntax and future git pushes will know what to do. (Shorter: git push -u.)

You should also look into git’s push.default setting, and set it to suit your needs.

git pull --rebase

If you want to apply your local commits linearly on top of the remote commits (rather than in parallel via a merge as would be normal) then you can use this command. I use it if I make changes from two different computers in unrelated areas.

Try not to over-use it - you should only use it where it improves the clarity of the history - git is very clever and a normal git pull resulting in a merge is generally preferred. Rebasing loses context of your commits (by modifying the patches to apply against later versions of the code) which makes it harder for others to understand the reasoning behind your changes.