relevant article:
使用git fetch和git rebase处理多人开发同一分支的问题——azureternite 我先update sem.c，但有人update itoa.cpp并且比我先提交。
gir pull:
* 949238e (HEAD -> master) Merge branch 'master' of https://github.com/theArcticOcean/CLib (weistephen<weistephen@garmin.com>, Wed May 30 23:13:23 2018)
|\
| * c20582e (origin/master) :sparkles: update itoa.cpp (weistephen<weistephen@garmin.com>, Wed May 30 22:36:21 2018)
* | b04d196 :sparkles: update sem.c (weistephen<weistephen@garmin.com>, Wed May 30 22:47:02 2018)
|/
* 519b6f8 :memo: update README.md (weistephen<weistephen@garmin.com>, Sat May 26 15:34:23 2018)
git rebase
关于git rebase，解释是这样的：git-rebase - Reapply commits on top of another base tip 因为服务器上已经有了新的修改，我们想要做的事情就是将把那些修改拿过来，然后把我们的修改补上。
这正好符合rebase的场景。
Assume the following history exists and the current branch is "topic":
A---B---C topic
/
D---E---F---G master
From this point, the result of either of the following commands:
git rebase master
git rebase master topic
would be:
A'--B'--C' topic
/
D---E---F---G master
fetch 并且rebase
➜ CLib git:(master) git fetch
➜ CLib git:(master) git rebase
First, rewinding head to replay your work on top of it...
Applying: :sparkles: update sem.c
➜ CLib git:(master) git-tree
git-tree:
* 9044a50 (HEAD -> master) :sparkles: update sem.c (weistephen<weistephen@garmin.com>, Thu May 31 08:10:52 2018)
* c20582e (origin/master) :sparkles: update itoa.cpp (weistephen<weistephen@garmin.com>, Wed May 30 22:36:21 2018)
* 519b6f8 :memo: update README.md (weistephen<weistephen@garmin.com>, Sat May 26 15:34:23 2018)
git-tree的原型是
alias git-tree=“git log --graph --decorate --pretty=format:’%C(red)%h%C(yell ow)%d%C(reset) %s %C(green)(%an<%ae>, %cd)%C(reset)’ --abbrev-commit --date= local $*”
总结：简答的说，git pull中的merge步骤会产生一个新的commit，将两个分支合并，所以有两条线相汇。git rebase branchA [branchB]直接将A分支中的commit放到B分支中，形成一条新的提交线，没有两条线交汇的场景。这两种解决代码冲突的方案，rebase的history显得更加“干净”一些。
