git使用—rebase还是merge

转载自：https://segmentfault.com/q/1010000007704573/

我猜现实中的情况是这样的：

使用 git 的人群中，不会用 rebase（哪怕是基础功能的）的至少一半（这个估计恐怕很保守了）
剩下一半里真正理解何时应该正确 rebase 的恐怕也就一半……
merge 还是 rebase 并不是一个二者选其一的问题，而是应该根据具体情况来选择使用，而这个“具体情况”在现实中实在是不好一一列举出来了，对于大多数开发者来说在团队中的职能比较单一，也不是经常有机会遇到，所以在这里我只总结两个人人都应该理解并遵守的准则：

当你从 remote 去 pull 的时候，永远使用 rebase（除了一个例外，后面会讲）
当你完成了一个功能（假定你是单独开本地分支去做的）后打算合并到主干分支的时候，永远使用 merge
开发者应当理解：不同的合并策略影响的或许不是最终的代码结果，但却会影响 git 如何记录提交的历史（尽管很多时候这种理解只对个别人受益，而对自己没有什么影响）。其他的人在使用这些历史的时候（比如 code review 的时候，或者 bisect 的时候等等）会因为过去你做过的事情而感到无比幸福或痛苦。

第二点比较容易理解，把开发一个功能的具体细节隐藏在本地分支中，而把最终的结果作为一条完整的记录合并（merge）到主干分支去。

关键是第一点。大多数情况下大家会选择默认的 pull，也就是 fetch + merge，于是我们会看到主干上不停的出现 Merge commit xxx into xxx 之类的干扰信息。如果所有的人都图方便这么干，那就永远都别想有干净漂亮的历史树了，取而代之是类似这样的东西：

如果你去 clone 一个正确使用 git 的项目，你绝对不会看到上图这样乱七八糟的 master。为什么呢？答案就是：git pull –rebase，这条命令会使用 rebase 来代替默认的 pull 对合并的历史树进行变基处理，就可以避免因为无法快进（fast forward）而产生的额外合并记录。

现在绝大多数的 git 客户端都允许设置 git pull 的默认行为是 –rebase，所以掌握了这个诀窍可以让大部分的日常拉取操作都产生清爽漂亮的历史记录，但这并不是完美的结局。有一种例外是这样的：

在你使用 git merge 完成了一个功能分支向主干分支的合并之后（当然是 –no-ff 的）
在你运行 git fetch 发现远程主干又领先你若干提交
此时你若 git pull –rebase，你会发现你刚才合并功能分支的记录没了……
这是因为变基会忽略合并记录，因此变基命令会有一个特别的参数叫做：–preserve-merges 用于重建被忽略的合并记录。所以比 git pull –rebase 更好的方案就是用 git fetch + git rebase -p 代替之。

当然这个仅针对上面提到的特殊情况，随着 git 的升级说不好哪一天就不存在这种问题了也不一定。我一般都不会遇到这种情况，因为我都是这么做的：

完成功能分支之后先不 merge，而是回到主干分支去 git pull –rebase
如果主干有更新，rebase 更新的内容到功能分支来预检一下，看看在加入了最近别人的改动之后我的功能是否依然 OK（在这个过程中可能会有冲突处理，别怪我没提醒哦）
一切就绪之后再次 git fetch 主干看看有没有变动（因为在第二步的进行期间没准又有人 push 了新的变化），有的话重复第二步，没有则——
合并功能分支到主干然后 push，收工。
我这么做可以避免前面提到的意外，看似复杂了些但其实做熟练了之后也没什么难度，更重要的原因是 git rebase -p 是有缺陷的：

不能和 git pull 连用，一条命令分成俩，怎么都觉得“亏”了（虽说你可以写脚本，但最好不要因为习惯了之后反而有时候会害了你）
由于无法和 git pull 配合使用，所以你必须指明目标分支给 rebase，这一点比较烦人，特别是很多 GUI 客户端压根不支持 git rebase -p 的时候（我经常会在 CLI／GUI 之间切换环境使用 git）
ORIG_HEAD 会被破坏。
ORIG_HEAD 在很多情形下非常有用，比如说你可以用 git log -p -reverse ORIG_HEAD 来回看最近一次合并所产生的所有变化等等。–preserve-merges 会让它失去本来应该指向的位置，你不得不先找到正确的 hash 来代替它，这会有点烦。

以上答案最终说明一件事情，现实的复杂性永远超出你在菜鸟时期所能做出的想象，真想把 git 用好那就要在日常工作的基础上好好理解 git 的工作原理吧，可以去看官方网站电子书（中文版），里面的 git internal 一节仔细看懂之后，该用什么命令心里就有数了。

补充一点：如果你的团队不在乎主干分支上有很多不重要的干扰提交记录，那你可以始终使用 rebase，这样至少可以不会出现很多分岔，处理得当也可以得到干净（但是啰嗦）的主干分支历史记录。

git使用—rebase还是merge相关推荐

Git：Rebase和Merge之间的区别，看完这篇文章你就懂了！
社区中长期以来一直在争论我们应该使用Merge还是Rebase. 有人会说Merge更好,因为它保留了最完整的工作历史.其他人则认为,Rebase变得更整洁,这使审阅者的生活更轻松,更高效.本文将解释 ...
GIT/IDEA使用 rebase 和 merge 的正确姿势（转）
GIT使用 rebase 和 merge 的正确姿势 (同Rebase the current branch on top of incoming changes 与 Merge incoming c ...
Git分支合并：Merge、Rebase的选择
git代码合并:Merge.Rebase的选择 - iTech - 博客园 http://www.cnblogs.com/itech/p/5188932.html Git如何将一个分支的修改同步到另一 ...
Git笔记(三)——[cherry-pick, merge, rebase]
书接上回,直入主题!这篇继续实践剩下的几个命令. 现在的SourceTree状态如下: cherry-pick - 妈妈,我也要 cherry-pick其实在工作中还挺常用的,一种常见的场景就是,比如 ...
13.Git分支-变基（rebase）、rebase VS merge
1.变基的基本操作在Git中整合来自不同分支的修改主要有两种方法:merge和rebase. 看下面的例子: 开发任务分叉到了两个不同的分支,并且都有了新的提交. 这时候我们可以使用 git mer ...
高级GIT教程——Cherry-Pick vs Rebase vs Merge
目录 GIT分支机构概述 Merge 什么是合并提交? Rebase Cherry-Pick Merge.Rebase和Cherry-Pick的摘要 GIT最重要的功能之一就是分支.多个功能的开发可以 ...
Git合并操作之merge、rebase、squash详解
文章目录 1 git merge和git rebase 1.1 git merge 1.2 git rebase 1.2.1 rebase交互模式 1.2.2 git pull --rebase 2 ...
Git必学的merge和rebase区别
rebase or merge? 一.git merge 场景一 :先pull再commit 场景二:先commit再pull 二.git rebase 场景一:先pull再commit 场景二:先c ...
Git rebase 和 merge讲解
git合并代码方式主要有两种方式,分别为: 1.merge处理,这是大家比较能理解的方式. 2.rebase处理,中文此处翻译为衍合过程. 先来两张合理使用rebase,merge和只使用merge的 ...

git使用—rebase还是merge

git使用—rebase还是merge相关推荐

最新文章

热门文章