Git笔记(16) 变基

Git笔记(16) 变基


1. 整合分支

Git笔记(12) 分支使用 中提及到使用merge 来整合来自不同分支的修改

在 Git 中还有一种常见的方法:rebase 变基


2. 基本操作

回顾之前在 Git笔记(12) 分支使用 中的一个例子
会看到开发任务分叉到两个不同分支,又各自提交了更新
Git笔记(16) 变基
整合分支最容易的方法是 merge 命令
它会把两个分支的最新快照(C3C4)以及二者最近的共同祖先(C2)进行三方合并
合并的结果是生成一个新的快照(并提交)
Git笔记(16) 变基
然而还有一种方法:
可以提取在 C4 中引入的补丁和修改,然后在 C3 的基础上应用一次

在 Git 中,这种操作就叫做 变基
可以使用 rebase 命令将提交到某一分支上的所有修改都移至另一分支上
就好像“重新播放”一样

在上面这个例子中,运行:
先切到experiment分支,再变基

$ git checkout experiment
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command

首先找到两个分支(当前分支 experiment、目标基底分支 master)的最近共同祖先 C2
然后对比当前分支相对于该祖先的历次提交,提取相应的修改并存为临时文件
然后将当前分支指向目标基底 C3
最后以此将之前另存为临时文件的修改依序应用
Git笔记(16) 变基
现在回到 master 分支,进行一次快进合并

$ git checkout master
$ git merge experiment

Git笔记(16) 变基
此时,C4’ 指向的快照就和上面使用 merge 命令的例子中 C5 指向的快照一样了

这两种整合方法的最终结果没有任何区别
但是变基 使得提交历史更加整洁

在查看一个经过变基的分支的历史记录时会发现
尽管实际的开发工作是并行的,但提交历史是一条直线没有分叉

无论是通过变基,还是通过三方合并
整合的最终结果 所指向的快照始终是一样 的,只不过提交历史不同罢了
变基是将一系列提交按照原有次序依次应用到另一分支上
而合并是把最终结果合在一起


3. 指定目标分支

在对两个分支进行变基时
所生成的“重放”并不一定要在目标分支上应用,可指定另外的一个分支进行应用

如:从一个特性分支里再分出一个特性分支的提交历史
创建了一个特性分支 server,为服务端添加了一些功能,提交了 C3C4
然后从 C3 上创建了特性分支 client,为客户端添加了一些功能,提交了 C8C9
最后,回到 server 分支,又提交了 C10
Git笔记(16) 变基
假设希望将 client 中的修改合并到主分支并发布
但暂时并不想合并 server 中的修改,因为它们还需要经过更全面的测试

这时就可以使用 git rebase 命令的 --onto 选项
master 分支上将在 client 分支里但不在 server 分支里的修改( C8C9)重放:

$ git rebase --onto master server client

以上命令的意思是:取出 client 分支,找出处于 client 分支和 server 分支的共同祖先之后的修改,然后把它们在 master 分支上重放一遍

Git笔记(16) 变基
现在可以快进合并 master 分支了

$ git checkout master
$ git merge client

Git笔记(16) 变基
这样即使提交历史简洁,并且不会影响 server 分支

接下来决定将 server 分支中的修改也整合进来
使用命令可以直接将特性分支(即本例中的 server)变基到目标分支(即 master)上

git rebase [basebranch] [topicbranch]

这样做能省去先切换到 server 分支,再对其执行变基命令的多个步骤

$ git rebase master server

server 中的代码被“续”到了 master 后面
Git笔记(16) 变基
然后就可以快进合并主分支 master 了:

$ git checkout master
$ git merge server

至此,clientserver 分支中的修改都已经整合到主分支里了
可以删除这两个分支:

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

Git笔记(16) 变基


4. 变基的风险

要用变基得遵守准则:

不要对在仓库外有副本的分支执行变基

变基操作的实质:
丢弃一些现有的提交,然后相应地新建一些内容一样但实际上不同的提交

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

来看一个在公开的仓库上执行变基操作所带来的问题
假设从一个*服务器克隆然后在它的基础上进行了一些开发

Git笔记(16) 变基
然后,某人又向*服务器提交了一些修改,其中还包括一次合并

现在抓取了这些在远程分支上的修改,并将其合并到本地的开发分支

Git笔记(16) 变基
接下来,这个人又决定把合并操作回滚,改用变基
继而又用 git push --force 命令覆盖了服务器上的提交历史

之后从服务器抓取更新,会发现多出来一些新的提交

Git笔记(16) 变基
结果十分尴尬
如果自己执行 git pull 命令抓取,将合并来自两条提交历史内容,生成一个新的合并提交

Git笔记(16) 变基
此时如果执行 git log 命令,会发现有两个提交(C6C4’)的作者、日期、日志相同
此外,如果将这一堆又推送到服务器上,实际上是将那些已经被变基抛弃的提交又找了回来
很明显对方并不想在提交历史中看到 C4C6
因为之前那个人就是把这两个提交通过变基丢弃的


5. 用变基解决变基

如果团队中的某人强制推送并覆盖了一些你所基于的提交
需要做的就是检查自己做了哪些修改,以及他们覆盖了哪些修改

实际上,Git 除了对整个提交计算 SHA-1 校验和以外
对本次提交所引入的修改计算了校验和—— 即 “patch-id

如果拉取被覆盖过的更新并将手头的工作基于此进行变基的话
一般情况下 Git 都能成功分辨出哪些是你的修改,并把它们应用到新分支上

如果遇到前面提到的情境:
有人推送了经过变基的提交,并丢弃了你的本地开发所基于的一些提交
Git笔记(16) 变基
如果不是执行合并,而是执行

git rebase teamone/master

Git 将会:

  • 检查哪些提交是我们的分支上独有的(C2,C3,C4,C6,C7)
  • 检查其中哪些提交不是合并操作的结果(C2,C3,C4)
  • 检查哪些提交在对方覆盖更新时并没有被纳入目标分支(只有 C2 和 C3,因为 C4 其实就是 C4’)
  • 把查到的这些提交应用在 teamone/master 上面

从而将得到与 将相同的内容又合并了一次,生成了一个新的提交 中不同的结果
如图 在一个被变基然后强制推送的分支上再次执行变基 所示:
Git笔记(16) 变基
要想上述方案有效,还需要对方在变基时 确保 C4’ 和 C4 是一样的
否则变基操作将无法识别,并新建另一个类似 C4 的补丁
而这个补丁很可能无法整洁的整合入历史,因为补丁中的修改已经存在于某个地方了


6. 手动解决变基

在本例中另一种简单的方法是使用 git pull --rebase 命令而不是直接 git pull
又或者可以手动完成这个过程,先 git fetch,再 git rebase teamone/master

如果习惯使用 git pull ,同时又希望默认使用选项 --rebase
可以执行这条语句来更改 pull.rebase 的默认配置

git config --global pull.rebase true

只要把变基命令当作是在推送前清理提交使之整洁的工具
并且只在从未推送至共用仓库的提交上执行变基命令,就不会有事

假如在那些已经被推送至共用仓库的提交上执行变基命令
并因此丢弃了一些别人的开发所基于的提交,那就麻烦了

如果你或你的同事在某些情形下决意要这么做,请一定要通知每个人执行命令

 git pull --rebase

这样尽管不能避免伤痛,但能有所缓解


7. 整合原则

变基 与 合并,到底哪种方式更好

首先讨论一下提交历史到底意味着什么

有一种观点认为,仓库的提交历史即是 记录实际发生过什么
这些痕迹就应该被保留下来,让后人能够查阅

另一种观点则正好相反,认为提交历史是 项目过程中发生的事
没人会出版一本书的第一版草稿,软件维护手册也是需要反复修订才能方便使用

现在,让回到之前的问题上来,到底合并还是变基好?
这并没有一个简单的答案
总的原则是,只对尚未推送或分享给别人的本地修改 执行变基操作清理历史
从不对已推送至别处的提交 执行变基操作
这样,才能享受到两种方式带来的便利


参考: git
以上内容,均根据git官网介绍删减、添加和修改组成


相关推荐:

Git笔记(15) 远程分支
Git笔记(14) 分支开发工作流
Git笔记(13) 分支管理
Git笔记(12) 分支使用
Git笔记(11) 分支简介


谢谢

Git笔记(16) 变基Git笔记(16) 变基 氢键H-H 博客专家 发布了242 篇原创文章 · 获赞 327 · 访问量 304万+ 他的留言板 关注
上一篇:git rebase -i 命令详解


下一篇:Git rebase