区别：merge和rebase

Git提供了两种代码合并方式，merge和rebase，我们先看看这两种方式有什么区别？

1. 代码合并前的状态

• topic是基于master分支上B节点拉出的特性分支。
• master分支是主分支，在B节点后，有新的提交F。
• 后续需要将topic分支的代码合入到主分支

2. 执行git merge后的效果

• topic分支的内容保持不变；
• 在topic和master两个分支的最新版本上做一次三方合并，并生成一个新的commit节点G。如果merge的过程有冲突，解决冲突后，也会将差异内容记录到新生成的commit中。
• 新生成的G节点有两个父节点，分别是F和E。

3. 执行git rebase后的效果

• 原来的topic已经被替换，master分支保持不变
• 将topic分支的基线版本切换至F，并【reapply】C、D、E节点的修改，并生成新的C’、D’、E’节点
• 之后可以将topic分支直接推送到远端仓库的master分支: git push origin topic:master

rebase会为每个在topic分支上的commit，重新生成新的commit节点，如果没有冲突，则除了commit-date被修改为执行rebase的时间，其他内容保持不变，如果有冲突，则同时记录新的修改。

可以在《Git常见问题-如何解决冲突》找到如何处理冲突

流程

使用rebase

1. 获取最新代码：git checkout master && git fetch
2. 合并：git checkout topic && git rebase master
3. 解决冲突：git add <conflict-file> && git rebase --continue
4. 推送：git push origin topic:master

使用merge

1. 获取最新代码：git checkout master && git fetch
2. 合并：git merge topic
3. 解决冲突：git add <conflict-file> && git merge --continue
4. 推送: git push

选哪种

就小编个人的偏好，【首选rebase】，原因：代码提交历史清晰，和实际代码上库的顺序一致，不会出现merge操作导致的代码路径混乱的问题。 看看下面git merge的log信息，如果驾驭不了的话，还是用rebase吧。