同样更新分支,git merge 和 rebase 有什么区别?
文章目录
最近在给 kubernetes 提交代码,k8s 社区要求非常严格,既要分支保持与主干的代码同步,还要一次只能有一条 commit。过程中我错误地使用了一把 git merge 和 git rebase,特此总结一下。
区别
同样更新分支,git merge 和 rebase 有什么区别?让我们从这个例子来看:
|
|
我们在 Commit 2
创建分支 second_branch
写代码,并提交了一个 commit
: 3b36f32
,在这之后,主干有人也提交了代码 Commit 3
。
问题来了:如何把 Commit 3
拉到我们的分支继续开发?(你的领导或同事肯定经常让你这样干!)
这时候用 git merge master
或 git rebase master
都能更新 second_branch
,也许有时候还要处理下冲突。但他们的结果却不相同,如下图:
git merge master | git rebase master |
---|---|
合并 master 的记录到分支,合并之后的所有 commit 会按提交时间从新到旧排列。 |
当前分支的 HEAD 会移动到 master 的结尾,但会变成一个新的 commit 。 |
用 git log --graph 查看的话,会有一条丑陋的边! |
git log --graph 是一条漂亮的直线 |
保持了所有 commit 的连贯性 |
commit 历史被修改了,3b36f32 被修改成了 a018520 |
什么时候用 rebase,什么时候用 merge?
- 用
merge
来把分支合并到主干。(废话!) - 如果你的分支要跟别人共享,则不建议用
rebase
,因为rebase
会创建不一致的提交历史。 - 如果只有你个人开发推荐使用
rebase
。 - 如果你想保留完整的提交历史,推荐使用
merge
,merge
保留历史 而rebase
重写历史。 rebase
还可以压缩、简化历史,通过git rebase -i
可以在分支合并到主干前,整理自己分支的提交历史,把很多细碎的commit
整理成一条详细的commit
。rebase
一次只处理一个冲突,merge
则一次处理全部冲突。处理冲突rebase
更方便,但如果有很多冲突的话,撤销一个rebase
会比merge
更复杂,merge
只需要撤销一次。
微信公众号
