git rebase 的使用
rebase
在 Git 中整合来自不同分支的修改主要有两种方法:merge
以及 rebase
。 在本节中我们将学习什么是“rebase”,怎样使用“rebase”,并将展示该操作的惊艳之处,以及指出在何种情况下你应避免使用它。
rebase的基本操作
整合分支最容易的方法是 merge
命令。 它会把两个分支的最新快照(C3
和 C4
)以及二者最近的共同祖先(C2
)进行三方merge,merge的结果是生成一个新的快照(并提交)。
还有一种方法:你可以提取在 C4
中引入的补丁和修改,然后在 C3
的基础上应用一次。 在 Git 中,这种操作就叫做 rebase。 你可以使用 rebase
命令将提交到某一分支上的所有修改都移至另一分支上,就好像“重新播放”一样。
在上面这个例子中,运行:
$ git checkout experiment
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command
它的原理是首先找到这两个分支(即当前分支 experiment
、rebase操作的目标基底分支 master
)的最近共同祖先 C2
,然后对比当前分支相对于该祖先的历次提交,提取相应的修改并存为临时文件,然后将当前分支指向目标基底 C3
, 最后以此将之前另存为临时文件的修改依序应用。
现在回到 master
分支,进行一次快进merge。
$ git checkout master
$ git merge experiment
此时,C4'
指向的快照就和上面使用 merge
命令的例子中 C5
指向的快照一模一样了。 这两种整合方法的最终结果没有任何区别,但是rebase使得提交历史更加整洁。 你在查看一个经过rebase的分支的历史记录时会发现,尽管实际的开发工作是并行的,但它们看上去就像是串行的一样,提交历史是一条直线没有分叉。
一般我们这样做的目的是为了确保在向远程分支推送时能保持提交历史的整洁——例如向某个其他人维护的项目贡献代码时。 在这种情况下,你首先在自己的分支里进行开发,当开发完成时你需要先将你的代码rebase到 origin/master
上,然后再向主项目提交修改。 这样的话,该项目的维护者就不再需要进行整合工作,只需要快进merge便可。
请注意,无论是通过rebase,还是通过三方merge,整合的最终结果所指向的快照始终是一样的,只不过提交历史不同罢了。 rebase是将一系列提交按照原有次序依次应用到另一分支上,而merge是把最终结果合在一起。
更有趣的rebase例子
在对两个分支进行rebase时,所生成的“重放”并不一定要在目标分支上应用,你也可以指定另外的一个分支进行应用。 你创建了一个特性分支 server
,为服务端添加了一些功能,提交了 C3
和 C4
。 然后从 C3
上创建了特性分支 client
,为客户端添加了一些功能,提交了 C8
和 C9
。 最后,你回到 server
分支,又提交了 C10
。
假设你希望将 client
中的修改合并到主分支并发布,但暂时并不想merge server
中的修改,因为它们还需要经过更全面的测试。 这时,你就可以使用 git rebase
命令的 --onto
选项,选中在 client
分支里但不在 server
分支里的修改(即 C8
和 C9
),将它们在 master
分支上重放:
$ git rebase --onto master server client
以上命令的意思是:“取出 client
分支,找出处于 client
分支和 server
分支的共同祖先之后的修改,然后把它们在 master
分支上重放一遍”。 这理解起来有一点复杂,不过效果非常酷。
现在可以快进merge master
分支了。
$ git checkout master
$ git merge client
接下来你决定将 server
分支中的修改也整合进来。 使用 git rebase [basebranch] [topicbranch]
命令可以直接将特性分支(即本例中的 server
)rebase到目标分支(即 master
)上。这样做能省去你先切换到 server
分支,再对其执行rebase命令的多个步骤。
$ git rebase master server
然后就可以快进merge主分支 master 了:
$ git checkout master
$ git merge server
至此,client
和 server
分支中的修改都已经整合到主分支里了,你可以删除这两个分支,最终提交历史会变成图 最终的提交历史 中的样子:
$ git branch -d client
$ git branch -d server
rebase的风险
呃,奇妙的rebase也并非完美无缺,要用它得遵守一条准则:
Do not rebase commits that exist outside your repository.
如果你遵循这条金科玉律,就不会出差错。
rebase操作的实质是丢弃一些现有的提交,然后相应地新建一些内容一样但实际上不同的提交。 如果你已经将提交推送至某个仓库,而其他人也已经从该仓库拉取提交并进行了后续工作,此时,如果你用 git rebase
命令重新整理了提交并再次推送,你的同伴因此将不得不再次将他们手头的工作与你的提交进行整合,如果接下来你还要拉取并整合他们修改过的提交,事情就会变得一团糟。
让我们来看一个在公开的仓库上执行rebase操作所带来的问题。 假设你从一个中央服务器克隆然后在它的基础上进行了一些开发。 你的提交历史如图所示:
然后,某人又向中央服务器提交了一些修改,其中还包括一次merge。 你抓取了这些在远程分支上的修改,并将其merge到你本地的开发分支,然后你的提交历史就会变成这样:
接下来,这个人又决定把merge操作回滚,改用rebase;继而又用 git push --force
命令覆盖了服务器上的提交历史。 之后你从服务器抓取更新,会发现多出来一些新的提交。
结果就是你们两人的处境都十分尴尬。 如果你执行 git pull
命令,你将merge来自两条提交历史的内容,生成一个新的merge提交,最终仓库会如图所示:
此时如果你执行 git log
命令,你会发现有两个提交的作者、日期、日志居然是一样的,这会令人感到混乱。 此外,如果你将这一堆又推送到服务器上,你实际上是将那些已经被rebase抛弃的提交又找了回来,这会令人感到更加混乱。 很明显对方并不想在提交历史中看到 C4
和 C6
,因为之前就是他把这两个提交通过rebase丢弃的。
如果你 真的 遭遇了类似的处境,Git 还有一些高级魔法可以帮到你。 参考 https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E5%8F%98%E5%9F%BA
rebase vs. merge
至此,你已在实战中学习了rebase和merge的用法,你一定会想问,到底哪种方式更好。 在回答这个问题之前,让我们退后一步,想讨论一下提交历史到底意味着什么。
有一种观点认为,仓库的提交历史即是 记录实际发生过什么。 它是针对历史的文档,本身就有价值,不能乱改。 从这个角度看来,改变提交历史是一种亵渎,你使用_谎言_掩盖了实际发生过的事情。 如果由merge产生的提交历史是一团糟怎么办? 既然事实就是如此,那么这些痕迹就应该被保留下来,让后人能够查阅。
另一种观点则正好相反,他们认为提交历史是 项目过程中发生的事。 没人会出版一本书的第一版草稿,软件维护手册也是需要反复修订才能方便使用。 持这一观点的人会使用 rebase 及 filter-branch 等工具来编写故事,怎么方便后来的读者就怎么写。
现在,让我们回到之前的问题上来,到底merge还是rebase好?希望你能明白,这并没有一个简单的答案。 Git 是一个非常强大的工具,它允许你对提交历史做许多事情,但每个团队、每个项目对此的需求并不相同。 既然你已经分别学习了两者的用法,相信你能够根据实际情况作出明智的选择。
总的原则是,只对尚未推送或分享给别人的本地修改执行rebase操作清理历史,从不对已推送至别处的提交执行rebase操作,这样,你才能享受到两种方式带来的便利。
git rebase 的使用的更多相关文章
- git rebase
git rebase -i HEAD~[number_of_commits] git rebase -i HEAD~2
- git rebase与 git合并(error: failed to push some refs to)解决方法
1.遇到的问题 本地有一个git仓库,在github上新建了一个空的仓库,但是更新了REWADME.md的信息,即在github上多了一个提交. 关联远程仓库,操作顺序如下: git remote a ...
- 聊下 git rebase -i
在使用git作为源代码管理工具的时候,开发的时经常会面临一个常见的问题,多个commit 需要合并为一个完整的commit提交. 在一个基本的迭代周期里,你会有很多次commit,有跟配置文件相关的, ...
- [git]rebase和merge
转自:http://blog.csdn.net/wh_19910525/article/details/7554489 Git merge是用来合并两个分支的. git merge b # 将b分支合 ...
- git merge 和 git rebase 小结
Git merge是用来合并两个分支的. git merge b # 将b分支合并到当前分支 同样 git rebase b,也是把 b分支合并到当前分支 ---------------------- ...
- [译]git rebase -i
使用rebase -i会在终端出现一个交互页面. 在这个交互页面中我们可以对要rebase的commit做一定的修改. 用法 git rebase -i <master> 把当前的分支的c ...
- [译]git rebase
rebase就是重新定义你分支的起点, 分支上的commit将生成对应的新的commit并放在你指定的新的起点commit后, 分支上的老commit将被删除. rebase就是将你的分支从一个com ...
- git rebase简介(高级篇)
原文:http://gitbook.liuhui998.com/4_3.html 一.基本 对于git rebase,你亦可以选择进行交互式的rebase.这种方法通常用于在向别处推送提交之前对它 ...
- git rebase简介(基本篇)
原文: http://gitbook.liuhui998.com/4_2.html 一.基本 git rebase用于把一个分支的修改合并到当前分支. 假设你现在基于远程分支"origin& ...
- Git merge 与 git rebase的区别
Git merge的用法: git merge Dev // Dev表示某分支,表示在当前分支合并Dev分支 git merge -m "Merge from Dev" Dev ...
随机推荐
- mongodb 索引,全文索引与唯一索引
唯一索引创建: db.createIndex({name: 1}, {unique: true})
- .net 4.0 中的特性总结(一):dynamic
在新版本的C#中,dynamic关键词是一个很重要的新特性,现在你可以创建动态对象并在运行时再决定它的类型.而且.net 4.0为CLR加入了一组为动态语言服务的运行时环境,称为DLR(Dynamic ...
- IIS中找不到dll文件的依赖项问题
1. 文件是否被锁定了2. 文件是否具有了everyone用户的读写权限.3. 文件是不是编译为了AnyCPU模式.4. 文件依赖的文件是否在bin目录下存在5. 停止IIS,把.net Framew ...
- yii2 配合bootstrap添加按钮
新增一个按钮 1.bootstrap 官网:http://getbootstrap.com/ 2.bootstrap 中文官网:http://v3.bootcss.com/ 在视图文件中: <? ...
- 使用pycharm以及用pycharm句子切分调试
c在D盘建立了个文件夹,然后把segment1.py文件放进去. 然后双击segment1,就自动用pycharm打开了.然后就可以运行和debug.之前最开始的时候我segment1.py文件放桌面 ...
- springboot + websocket + spring-messaging实现服务器向浏览器广播式
目录结构 pom.xml <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http:// ...
- git忽略已加入到版本库的文件
项目中,我们会用到 '.gitignore' 来忽略一些文件,不记录这些文件的版本控制. 然而,经常发现,已经添加到了 '.gitignore' 的文件/目录,每次的修改等扔会记录版本. 产生这种原因 ...
- .Net转Java.05.为啥MySQL没有nolock
今天忽然想到一个问题,原来为了提高SQL Server性能,公司规定查询语句一般都要加 WITH (NOLOCK)的 现在转Java了,用了MySQL为啥不提这个事情了? 先在MySQL里写了一个查询 ...
- mount: wrong fs type, bad option, bad superblock
mount: wrong fs type, bad option, bad superblock on 125.64.41.244:/data/img, missing codepage ...
- bootstrap-3-fileinput上传案例
效果 导入的js和css <link rel="stylesheet" href="https://cdn.bootcss.com/bootstrap/3.3.7/ ...