序

程序员的圣战有很多，比如缩进使用空格还是tab，编辑器是用Emacs还是Vim，PHP是不是世界上最好的语言，git merge 还是 git rebase……

今天，我们一起来看看 git merge 与 git rebase

这两个命令都可以完成代码的合并，有什么区别，在实际使用中是不是二选一的关系呢？

merge：Join two or more development histories together
rebase：The git rebase command allows you to easily change a series of commits, modifying the history of your repository

实际操作中根据需要，merge与rebase搭配使用更佳

rebase优点

• 调整单个分支的commit
  • git rebase -i commit_id（不包含）会合并提交历史，使得git log清爽简洁
• 用于不同分支之间的合并或者单个分支本地和远端的合并
  • 不会产生类似git merge这样的单独的新commit（冗余）
  • 不容易产生历史树的交叉，美观，易于理解和管理
  • 可以确保分支commit是一个线性结构，方便rollback

rebase需要注意的点

• 会改变提交历史树（会把本分支的commits顶到最顶端），但是看不见分支合并历史

推荐实践

1. 具体使用哪一个，其实是个管理问题和业务问题，包括选型使用git flow或者github flow
   1. 一般想要开发互联网产品，只需要维护一个主分支，所有feature都是会回归到主分支，这时候需要rebase，feature分支在合并回主分支之前需要先rebase，然后提交mr，主分支再merge回来
2. 同一个分支的多人协作开发，比如feature，建议用rebase，git pull —rebase，git push
3. 不同分支多人协作开发，比如feature合并回master，
   1. git co master
   2. git pull
   3. git co feature
   4. git rebase master
   5. git push feature
   6. merge requests
   7. 代码审核员，git co master
   8. git megre feature —no-ff（形成合并历史，方便追溯）

总结

• merge流派
  • 更注重过程，会记录commit所有细节，且方便溯源
  • merge会产生分支，然而从版本管理的角度，多人的工作本来就应该位于不同的分支。单纯为了线条好看而改变实际开发过程中的事实，并不是可取的行为。
• rabase流派
  • 更注重结果，过程细节被rebase整理干净（掩盖）了
  • 历史线干净整洁，没有多余的merge commit
  • 如果经常需要rollback回滚就用rebase