

Git Tips - AdamGibbins
http://mislav.uniqpath.com/2010/07/git-tips/

======
dongsheng
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

~~~
eswat
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'

------
swanson
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!

~~~
esk
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?

~~~
swanson
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!)

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

