git 进阶学习：git rebase

git rebase学习

---

---

变基介绍

在 Git 中整合来自不同分支的修改主要有两种方法:merge 以及 rebase。 在本节中我们将学习什么是“变基”，怎样使用“变基”，并将展示该操作的惊艳之处，以及指出在何种情况下你应避免使用它。

变基作用

• 合并分支
• 解决冲突
• 重新排序提交
• 压缩提交
• 拆分提交

---

变基的用法

合并分支

git rebase master experiment

• master： 需要合并上去的分支，“基底”
• experiment：需要被合并的提交的分支
  合并之前：
  

合并之后：

通过这个合并图可以得知，rebase是将提交在master上重放了一下，所以提交顺序是master之后的，不同于merge的按真实的提交时间排序。

git rebase —onto master server client

• 取出client分支，找出它从server分支分歧之后的补丁，然后把这些补丁在master分支上重放一遍。

• 合并之前的分支情况
  

• 合并之后的分支情况
  

整理提交

git rebase -i HEAD~3

HEAD:表示当前分支的最后提交
HEAD～3 ==HEAD～2^ :表示最后提交的前3次提交
修改指定提交时，需要选中该次提交的前一提交，HEAD～3 只能修改倒数3次提交（包括最后提交）

运行这个命令，会打开一个文本框，示例如下：

重新排序提交

- pick 选中提交

修改历史提交

- reword 编辑提交信息
- edit 修改改次提交

压缩提交

• squash ，合并3次提交，示例如下
  

拆分提交

• edit，原理很简单，使用edit 修改指定提交，然后在该次提交中，执行两次commit

git rebase --continue

当修改某次提交之后，执行该命令可以进入下一次修改。

变基的原理

1. 首先找到这两条分支的最近共同祖先
2. 然后对比当前分支相对于该祖先分支的历次提交，提取相应的修改并存为临时文件
3. 接着将当前分支指向目标基底
4. 最后以此将之前另存为临时文件的修改依序应用

变基的风险

金科玉律：如果提交存在于你的仓库之外，而别人可能基于这些提交进行开发，那么不要执行变基。

如果你已经将提 交推送至某个仓库，而其他人也已经从该仓库拉取提交并进行了后续工作，此时，如果你用git rebase命令 重新整理了提交并再次推送，你的同伴因此将不得不再次将他们手头的工作与你的提交进行整合，如果接下来你 还要拉取并整合他们修改过的提交，事情就会变得一团糟。

案例

1. 克隆一个仓库，然后在它的基础上进行了一些开发

2. 抓取别人的提交，合并到自己的开发分支

3. 有人推送了经过变基的提交，并丢弃了你的本地开发所基于的一些提交

4. 你将相同的内容又合并了一次，生成了一个新的提交

问题

此时如果你执行git log命令，你会发现有两个提交的作者、日期、日志居然是一样的，这会令人感到混乱。 此外，如果你将这一堆又推送到服务器上，你实际上是将那些已经被变基抛弃的提交又找了回来，这会令人感到 更加混乱。 很明显对方并不想在提交历史中看到 C4 和 C6，因为之前就是他把这两个提交通过变基丢弃的

变基解决变基

对于上述问题，可以使用‘’魔法“打败”魔法“，如果你拉取被覆盖过的更新并将你手头的工作基于此进行变基的话，一般情况下 Git 都能成功分辨出哪些是你的修改，并把它们应用到新分支上。执行git rebase， git会

• 检查哪些提交是我们的分支上独有的分支
• 检查其中哪些提交不是合并操作的结果
• 检查哪些提交在对方覆盖更新时并没有被纳入目标分支
• 把查到的这些提交应用在 teamone/master 上面
• git pull —rebase 等价于 rebase 远程分支

---

在一个被变基然后强制推送的分支上再次执行变基

变基vs 合并（rebase vs merge）

合并：记录实际发生过什么

合并会有一条合并提交记录

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

变基：提交历史是项目过程中发生的事

变基，会改变真实的提交历史的提交时间或顺序

没人会出版一本书的第一版草稿，软件维 护手册也是需要反复修订才能方便使用。 持这一观点的人会使用 rebase 及 filter-branch 等工具来编写故 事，怎么方便后来的读者就怎么写。