Another tip is adding all this to .gitconfig:

  [alias]
    b = branch
    co = checkout
    ci = commit
    st = status -sb
    diff = diff --word-diff
    l = log --graph --pretty=oneline --abbrev-commit --decorate

I’ve added my aliases to my bashrc instead.

  alias git="hub"
  alias ga="git add -A"
  alias gap="git add -Ap"
  alias gc="git commit -m"
  alias gs="git status -sb"
  alias gd="git difftool"
  alias gb="git branch"
  alias gco="git checkout"
  alias gm="git merge --no-ff"
  alias gp="git push"
  alias gpl="git pull"
  alias gf="git fetch"
  alias gcl="git clone"
  alias gr="git reset"
  alias gl="git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative"
  alias gre='git remote -v'

I like :

lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative

from http://www.jukie.net/bart/blog/pimping-out-git-log

I use these:

  [alias]
    l = log --oneline --decorate --graph
    co = checkout
    ci = commit
    man = help
    h = help
    a = add
    f = fetch
    d = diff
    dc = diff --cached
    dt = difftool
    dtc = difftool --cached
    ds = diff --stat
    dsc = diff --stat --cached
    s = status --short --branch
    b = branch

Some neat tricks, though I don't know how practical "Checkout a branch, rebase and merge to master" is - I find myself having to do manual mergetool stuff when I rebase off master enough that the one-liner would fail too often to be helpful.

I didn't know about --word-diff though - I'll be aliasing that to be the default for `git diff` for sure!

I envy your understanding—I'm struggling to figure out what that line is supposed to do. Is he switching to a different branch, squashing all of its commits into one, and then merging that branch back into master?

He is on master and probably just pulled/fetched the latest revisions. He has some work on a local feature branch.

* The first command switches over to that feature branch.

* The second command rebases off of master, which basically rewinds the changes on his branch and applies them to the latest version from master - think of this like getting latest and merging in your pending changes.

* The third command switches back to master.

* The fourth command merges the feature branch into master - this should be what is called a "fast-forward merge" and not require a separate merge commit since you rebased your branch.

The rebase is really used to make it a cleaner merge back into master (and a cleaner history in general), not to squash commits in this case (though you also would use rebase to squash, that's another topic).

What I pointed out is that (for me at least) the rebase from master is not usually "clean" - meaning there are merge conflicts that I have to resolve - so chaining together shell commands like this doesn't really help when the second command is going to need intervention from me before I can run the third.

Hope that helps (and I hope my analysis is right or I'll look silly!)

There's also an option to squash at merge time, which is commonly used going from a feature branch to an integration branch.

I may be confused myself, but I think he's doing what's described in the first example here: http://learn.github.com/p/rebasing.html (checkout a feature branch, rebase master onto it, then go back to master and merge in the branch - it gives a more linear-looking history which many people prefer).

If I'm right the point of the tip is just to simplify this set of steps into a one-liner (which would help if you did this rebase and merge often).

In any case, I'm pretty sure that this is separate from squashing all the commits on the feature branch.