序列化操作

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