在开发过程中使用git rebase还是git merge，优缺点分别是什么？

提示: 作者被禁止或删除内容自动屏蔽

facetothefate · 2018-10-15 23:08:31

根据你们开发不同的work flow选用

如果你用merge/pull request，这种compare branch的做code review的话差别不是很大。

如果你用gerrit 做code reivew的话，尤其某些写的稀烂的git 钩子，那你几乎很难不rebase，merge会产生多余commit并且把你的修改弄到下面去，你就很难提交一个正确的review，特别是你需要修改的，upload新的change set的时候，gerrit这个时候依赖于commit message的change ID来判断是不是同一个change，这个时候最简单的做法是git commit --amend，保持你的change在最顶端是最快捷的办法。

其实rebase最大的用处就是把你的commit变成HEAD.

匿名用户 · 2018-10-15 23:08:32

提示: 作者被禁止或删除内容自动屏蔽

大花猫 · 2018-10-15 23:08:33

以上回答都没有说出最根本的原因，深入理解rebase的坑
https://medium.freecodecamp.org/git-rebase-and-the-golden-rule-explained-70715eccc372

凯斯 · 2018-10-15 23:08:34

其实很容易理解的...
git merge会改变你的提交历史，而git rebase不会改变你的提交历史。
举个例子:)
如果本地develop分支拉取了最新代码，并且在你的feature功能分支上需要develop分支上的某些代码时，在你的feature分支可以执行git rebase或者git merge的操作。
如果使用git rebase develop，那么会把你feature分支并入到develop分支的后面，feature分支的提交历史不会发生变化。
如果使用git merge develop，那么会把develop分支并入到feature分支中，feature分支的提交历史会包含develop分支的提交历史，同时develop分支不会受到影响。
其实如果用github你会发现，有一个merge request的操作。这个其实就相当于在线上代码(master)分支上合并了开发分支（git merge develop）。这样master分支就能够看到develop的提交历史。
另外，当在feature分支上通过git pull拉取了远程develop分支更新过后的代码，默认会执行一次git mrege的操作，细心的coder会发现git pull成功之后执行git log，会发现提交历史发生了变化。

最后稍稍总结一些：

在自己的分支（feature功能分支）执行rebase操作
在公共分支执行merge操作合并feature分支或develop分支，这样master分支上可以看到提交历史
git pull会默认执行一次git merge的操作，因此提交历史会发生变化

周兴兴 · 2018-10-15 23:08:36

推送到他人可见仓库的分支不应rebase

幽灵代笔 · 2018-10-15 23:08:38

考虑如下几个问题：

为什么git rebase会产生连环冲突，git merge不会
为什么有时候git rebase会产生冲突，git merge不会
有A和B两个分支，为什么A merge B和B merge A是等价的，而rebase的操作却不是
为什么push后merge可以保留正确运行的commit，而rebase不会

健三 · 2018-10-15 23:08:39

用哪个取决你是否想要留下解冲突的commit, merge 之后解冲突会增加一次commit, 而reabse则不会. 所以一般解与别人的冲突用merge, 自己与自己有已知的冲突, 可以用rebase.
例子: 我今天上午hotfix改了个计划脚本并合并master, 下午继续昨天的工作, 发现该计划脚本已经用另一种方法修正过了, 这个解冲突记录就是没有必要留着的, 我会用rebase.

徐磊 · 2018-10-15 23:08:40

如果经常需要rollback就用rebase.

在开发过程中使用git rebase还是git merge，优缺点分别是什么？

8 个回复

浏览过的版块