git rebase vs merge翻译

原文,有图片

Merge

git checkout feature
git merge master
//精简：
git merge feature master

之后feature branch上创建了一个merge commit
好处是：非破坏性操作（non-destruction operation)，已经存在的提交 不会有更改
坏处是：master活跃导致merge一次，feature branch一次merge commit，污染feature分支。并且log历史变得复杂。

rebase

git checkout feature
git rebase master

将feature分支的commit整个移动到 master的最新提交上。但是相比较于merge，rebase重写了项目的历史，在feature上创新创建了原有的commit。

• 好处：
  线性的历史记录
• 坏处：
  安全性、可追溯性，提交的历史发生了改变

Interactive Rebasing：

git checkout feature
git rebase -i master

可合并、重排 rebase 生成commit的记录

pick 33d5b7a Message for commit #1
fixup 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3

fixup将1,2commit 合并

rebase黄金法则（golden rule）：

不要将public branch映射到feature上操作（就是不要反向操作）

上面正常的是（Rebasing the feature branch onto master，将feature branch映射到master上)
错误的是（Rebasing the master branch)
导致master上提交，都在feature后面重新commit，然后merge到master。导致历史有重复的提交。而且master是公共的（public）分支，别人就只能merge。

One of the only times you should be force-pushing is when you’ve performed a local cleanup after you’ve pushed a private feature branch to a remote repository

建议：

Local Cleanup

rebase的最佳实践是，对自己的private branch（只有你操作的feature branch）定期进行clean up（清理），然后rebase。
本质就是修改feature branch上的历史，合并小的提交，rebase后别人看起来简洁。

在feature branch内部进行历史修改。

git checkout feature
git rebase -i HEAD~3

查找feature branch最初的base点（从master上分出的点）

git merge-base feature master

如果不熟悉rebase，可以先从feature check out到临时branch，进行clean up

git checkout feature
git checkout -b temporary-branch
git rebase -i master
//Clean up the history
git checkout master
git merge temporary-branch

tips

git pull默认用的merge，但可以改为rebase，通过添加 --rebase参数
不要在pull-request之后rebase
任何需要和他人协作的更改 要用merge，而不是reabse
最好在pull-request前，用interactive reabse清理下feature branch

总结

git rebase有更清晰、线性的历史，可以减少不必要的merge。
git merge好处是保留完整的历史记录，减少重写public commit的风险。