序列化操作
git merge <branch>
git rebase <branch>
git cherry-pick <commit>
...
这些都是git把commit一个个地在当前分支上重演，整个过程可能涉及到不止一个commit应用在当前分支上，所以这是一个序列化的操作行为。
当某个commit在当前分支上的replay发生冲突的时候，就需要解决冲突；
当冲突解决完成之后，就可以使用git merge/rebase/cherry-pick --continue命令来继续完成这个序列化过程，直到结束。
好用的git status -s
使用git status -s来查看工作区状态要比没用-s参数的要方便，但是需要先了解这个简洁版工作状态的表达方式：
一般我们看到的是 XY PATH 这样形式的一个状态表达，这个状态值有如下几种：
- 空白 表示无改动
- M 表示改动
- A 表示添加
- D 表示删除
- R 表示重命名
- C 表示拷贝
- U 表示已更新到索引区但是未合并
- ? 表示还没添加到git库中的文件
- ! 表示已被忽略的文件
上述列表就是X/Y的可能取值，那么在无冲突的情况下，XY分别指代索引区和工作区的状态；在有冲突的情况下，XY就分别指代冲突双方的各自状态了，其中X是我们，Y是他们。
这里举例表述下有冲突的情况下，XY的部分组合： - AU 我们添加了文件
- UD 他们删除了文件
- DD 双方都删除了文件
- UU 双方都修改了文件
除了UU的情况外，其他情况都是可以通过git add/rm搞定；而UU的话，需要手工去解决冲突，然后git add把修改加入索引区，这样才算是解决完了冲突。
关于合并
merge是一件痛苦的事情，尤其是两边的内容有很多不同的时候，这时候可以尝试下使用merge的耐心算法，说不定可以有效的减少merge的痛苦
git merge --strategy-option=patience
