git-变基（rebase）的原理和最佳实践

红太狼 2022-11-21 11:33 171阅读 0赞

# 前言 #

在 Git 中整合来自不同分支的修改主要有两种方法：`merge` 以及 `rebase`。

其中`merge`是一个**三方（分支master最新快照，分支dev最新快照，分支master和dev的共同祖先快照）合并**的方式来整合修改，并且整合之后会生成新的提交快照。

`merge`之前的三方（`c4`，`c5`及共同祖先`c2`）：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NzZWhz_size_16_color_FFFFFF_t_70_pic_center]  
`merge`之后产生新的提交快照（`c6`）  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NzZWhz_size_16_color_FFFFFF_t_70_pic_center 1]  
`merge`之后，`iss53`分支的`c3`和`c5`提交快照消失了。

为了避免提交快照因为合并而移除的问题，发明了`rebase`方法来整合不同分支的修改。

> 更多`merge`的用法请参考[分支的新建与合并][Link 1]。

# 变基的原理 #

假设日常开发中出现了如下图所示的场景：分支`experiment`和分支`master`分别在共同祖先`C2`上生成了提交快照`C4`和`C3`。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NzZWhz_size_16_color_FFFFFF_t_70_pic_center 2]

首先找到这两个分支（即当前分支 `experiment`、变基操作的目标基底分支`master`） 的最近共同祖先 `C2`，然后对比当前分支相对于该**祖先**的历次提交，提取相应的修改并存为临时文件， 然后将当前分支指向目标基底 `C3`, 最后以此将之前另存为临时文件的修改依序应用。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NzZWhz_size_16_color_FFFFFF_t_70_pic_center 3]  
此时，只需要在目标基底分支`master`上和合并`rebase`过的`experiment`分支即可。

$ git checkout master
    $ git merge experiment

这样，两个分支的提交快照都保留了下来，效果如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NzZWhz_size_16_color_FFFFFF_t_70_pic_center 4]

# 更复杂的变基 #

在对两个分支进行变基时，所生成的“重放”并不一定要在目标分支（下文的`server`分支）上应用，你也可以指定另外的一个分支（下文的`master`分支）进行应用。 你创建了一个主题分支`server`，为服务端添加了一些功能，提交了`C3` 和`C4`。 然后从`C3`上创建了主题分支`client`，为客户端添加了一些功能，提交了`C8`和`C9`。 最后，你回到`server`分支，又提交了`C10`。

整个项目的提交状态如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NzZWhz_size_16_color_FFFFFF_t_70_pic_center 5]  
`master`分支和`server`分支的共同祖先是`C2`，`server`分支和`client`分支的共同祖先的`C3`。

假设你希望将`client`中的修改合并到主分支并发布，但暂时并不想合并`server`中的修改， 因为它们还需要经过更全面的测试。这时，你就可以使用 git rebase 命令的 `--onto` 选项， 选中在`client`分支里但不在`server`分支里的修改（即`C8`和 `C9`，也就是`server`和`client`共同祖先`C3`之后的修改），将它们在`master`分支上重放：

git rebase --onto master server client

`--onto`参数指定的分支是最后要变基的基底分支，这里是`master`，而`server`用于确定`client`分支要基于的共同祖先`C3`之后的提交快照。

以上命令的意思是：“取出`client`分支，找出它从`server`分支分歧之后的补丁， 然后把这些补丁在`master`分支上重放一遍，让 client 看起来像直接基于`master`修改一样”。这理解起来有一点复杂，不过效果非常酷。

使用`--onto`参数，`client`分支需要重播的提交是`C3`之后的提交，而不是`C2`之后的提交。这样，用于确定共同祖先的分支（`server`）和最终要变基的基底分支（`master`）是独立的。

最终`rebase`后的效果如下：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NzZWhz_size_16_color_FFFFFF_t_70_pic_center 6]  
同样，此时要在目标基底分支`master`合并`client`分支来整合`C8`和`C9`提交：

$ git checkout master
    $ git merge client

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NzZWhz_size_16_color_FFFFFF_t_70_pic_center 7]  
接下来你决定将`server`分支中的修改也整合进来。 使用 `git rebase <basebranch> <topicbranch>` 命令可以直接将主题分支 （即本例中的`server`）变基到目标分支（即`master`）上。 这样做能省去你先切换到`server`分支，再对其执行变基命令的多个步骤。

$ git rebase master server

![在这里插入图片描述][20201101115826303.png_pic_center]  
然后就可以快进合并主分支`master`了：

$ git checkout master
    $ git merge server

![在这里插入图片描述][20201101115938141.png_pic_center]  
至此，`client`和`server`分支中的修改都已经整合到主分支里了， 你可以删除这两个分支，最终提交历史会变成上图中的样子：

$ git branch -d client
    $ git branch -d server

# 使用变基的原则 #

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

简单的说就是只在自己的分支变基，然后在公共分支上合并变基后的提交记录。

# 本地变基后推送到远程 #

在本地分支变基（可能要解决冲突）后，本地分支和远程分支会变得不一样，特别是有冲突的时候，推送上去会提示要`merge`还是`rebase`。如果远程的分支只有自己修改，可以使用`git push --force`让本地分支直接覆盖远程分支，使远程分支最新。如果远程分支可能有其他人修改，最好使用`git push --force-with-lease`，这个命令在检测到远程分支修改时，不会强制覆盖。此时需要先`fetch`远程分支，然后整合分支修改，然后再使用`git push --force-with-lease`推送代码。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NzZWhz_size_16_color_FFFFFF_t_70_pic_center]: /images/20221120/0aebba160c7541c3820ec64cb47328a8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NzZWhz_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221120/053ecaa298394eb0854cdf95e1a46357.png
[Link 1]: https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E5%88%86%E6%94%AF%E7%9A%84%E6%96%B0%E5%BB%BA%E4%B8%8E%E5%90%88%E5%B9%B6#_basic_merging
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NzZWhz_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221120/1b59b511acea41cdbbf9fbce42add387.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NzZWhz_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221120/7a75fff2c33a4834a60519eafbe76ec2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NzZWhz_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221120/5c9943ecd88a4c6d95a801bbca0ea256.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NzZWhz_size_16_color_FFFFFF_t_70_pic_center 5]: /images/20221120/7b87b8d1e0a442f89a049f0f9d959c08.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NzZWhz_size_16_color_FFFFFF_t_70_pic_center 6]: /images/20221120/db3c49b36ad9480cb56357ad7bd707c0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NzZWhz_size_16_color_FFFFFF_t_70_pic_center 7]: /images/20221120/2141b5b3dc3541fb854aedacbf3986e9.png
[20201101115826303.png_pic_center]: /images/20221120/43c2ee2d6c8640d699d143d364fca94a.png
[20201101115938141.png_pic_center]: /images/20221120/bf39aea3b4884d3b9518868545285150.png