Git教程(7)用合并还是变基？

 

1.合并或变基前的样子

分支experiment与master两个分支都产生了提交。

　　　　　　　　　　　　　　　　图1. 未合并或变基前的样子

2.合并

　　找到两个分支的最末提交和最近的共同祖先，在执行git merge时所处的分支上，新建一个提交，在其中做一个简单的三方合并。

　　合并后，注意c2,c3,c4没有冲突，那么产生新的提交c5，如果有冲突，那么合并工作会暂停，解决冲突后可手动提交。

　　　　　　　　　　　　　　　　图2. 合并后的样子

相关命令:把experiment合并到master分支上。

$ git checkout master
$ git merge experiment

3.变基

　　未变基前参看图1，它的原理是首先找到当前分支 experiment、目的地分支 master 的最近共同最近祖先 C2，然后对比当前分支相对于该祖先的历次提交，提取相应的修改并存为临时文件，然后将当前分支指向目标分支上C2后的第一个提交 C3, 最后以此将之前另存为临时文件的修改依序逐个应用到后面的每个提交。

　　　　　　　　　　　　　　　　图3. 变基中的样子

　　　　　　　　　　　　　　　　图4. 变基后的样子

相关命令：

$ git checkout experiment
$ git rebase master

$ git checkout master
$ git merge experiment 

金科玉律：

• 变基有风险，只在本地变基，不要变基服务器上的分支。
• 变基操作的实质是丢弃一些现有的提交，然后相应地新建一些内容一样但实际上不同的提交。如果有人依赖那些丢弃的提交，会产生问题。
• 如果有人变基服务器上的分支，其它人更新数据时要执行 git pull --rebase 命令，这样尽管不能避免伤痛，但能有所缓解。
• 只要你把变基命令当作是在推送前清理提交使之整洁的工具，并且只在从未推送至共用仓库的提交上执行变基命令，你就不会有事。 

4.对比

　　有一种观点认为，仓库的提交历史即是 记录实际发生过什么。 它是针对历史的文档，本身就有价值，不能乱改。 从这个角度看来，改变提交历史是一种亵渎，你使用谎言掩盖了实际发生过的事情。 如果由合并产生的提交历史是一团糟怎么办？ 既然事实就是如此，那么这些痕迹就应该被保留下来，让后人能够查阅。

　　另一种观点则正好相反，他们认为提交历史是 项目过程中发生的故事。 没人会出版一本书的第一批草稿，软件维护手册也是需要反复修订才能方便使用。 持这一观点的人会使用 rebase 及 filter-branch 等工具来编写故事，怎么方便后来的读者就怎么写。

　　现在，让我们回到之前的问题上来，到底合并还是变基好？希望你能明白，并没有一个简单的答案。 Git 是一个非常强大的工具，它允许你对提交历史做许多事情，但每个团队、每个项目对此的需求并不相同。 既然你已经分别学习了两者的用法，相信你能够根据实际情况作出明智的选择。

5.总的原则

　　只对尚未推送或分享给别人的本地修改执行变基操作清理历史，从不对已推送至别处的提交执行变基操作，这样，你才能享受到两种方式带来的便利。