UDN-企业互联网技术人气社区

板块导航

浏览  : 1392
回复  : 0

[翻译] 《Git in Practice》翻译 技巧43 —— 变基操作:git rebase

[复制链接]
zhaoyx的头像 楼主
发表于 2015-9-8 15:21:50 | 显示全部楼层 |阅读模式
本帖最后由 zhaoyx 于 2015-9-10 10:21 编辑

技巧43 把提交变基到另外一条分支的顶端:git rebase



   回顾技巧14 你会发现,变基操作与合并操作类似,但是变基操作会重写历史记录。让我们创建一个分支来进行变基操作实验:
         1.        切换到你的版本库目录:例如,
                    cd /Users/mike/GitInPracticeRedux/
         2.        执行 git checkout –b inspiration v0.1
         3.        编辑并修改文件01-IntroducingGitInPractice.asciidoc
         4.        执行git commit –message=”Add Chapter 1 inspiration.” 01-IntroducingGitInPractice.asciidoc
        应该产生类似如下输出:
清单 6.5 输出:预备变基的提交

           # git commit --message="Add Chapter 1 inspiration.
           01-IntroducingGitInPractice.asciidoc
           [inspiration 88e8b4b] AddChapter 1 inspiration.
           1 file changed, 1 insertion(+)

         6.5 显示新分支inspiration . 这条分支只包含一个提交,父提交是标记为 v0.1 的基线提交。

图6.5

图6.5

图示 6.5 最新创建的分支inspiration


        现在,让我们在这条分支上进行变基。


        问题
       你想将inspiration 分支变基到v0.1-release 分支的顶端。

       解决
       1.        切换到你的版本库目录:例如,
       cd /Users/mike/GitInPracticeRedux/
       2.        执行 git checkout inspiration
       3.        执行git rebase v0.1-release
       应该产生类似如下输出:
清单6.6 变基输出

清单6.6

清单6.6


file:///C:\Users\ADMINI~1\AppData\Local\Temp\msohtmlclip1\01\clip_image003.jpg
              1 显示Git 将HEAD 指针移动到了v0.1-release分支的最后一次提交上。这么做的目的是为了在v0.1-release分支的最后一次提交上重新提交inspiration分支上的最新提交。

              2 显示每个被重新提交的提交列表(在本次示例中,只有一次提交)。实际上Git是在新的基础——v0.1-release分支最后的一次提交上,对每个变基涉及到的提交做了一次cherry-pick动作(技巧38)。由于他们的父提交已经发生变化,所以这些提交对应的SHA-1值也发生了变化。

       6.6 显示了被变基的inspiration分支。它依然只有一次提交,但是这个提交的父提交现在已经变为v0.1-release分支的最后一次提交,而不再是标记为v0.1的基线提交。

图6.6

图6.6

图示 6.6 变基之后的inspiration 分支 (原书中图示有误)

file:///C:\Users\ADMINI~1\AppData\Local\Temp\msohtmlclip1\01\clip_image005.jpg
       至此,你已经将inspiration分支变基到了v0.1-release分支的顶部。


       讨论
       任意的引用都可以作为 git rebase 的参数使用。就是说任何提交你都可以变基,但是通常来讲,这不是一个好主意。一般来说你应该变基到一个已更新的分支或者另外一个分支/基线上去。

       如果把一些修改提交到了错误的分支上,你是不能用变基操作来修改它的。但是你可以使用git rebase --interactive 来解决这个问题,这个内容将在 技巧44 进行介绍。

       现在再来通过引用日志看看变基操作之后发生了什么。
清单6.7 变基后的引用日志输出

list6.7

list6.7


file:///C:\Users\ADMINI~1\AppData\Local\Temp\msohtmlclip1\01\clip_image007.jpg
              1 显示变基操作已经成功完成,所以指针移向了已经更新的inspiration分支的变基提交。

              2 显示新提交已经创建完成,而它的父提交即是v0.1-release分支最后一次的提交。Inspiration分支在这次提交成功创建完成之后被更新。这样即避免了变基操作失败导致分支前后不一致的情况发生。

              3 显示在变基操作开始的时候,检出v0.1-release分支的动作,以此方式确定父提交的位置。

              4 显示新提交在变基操作之前已经生成。

       如果你希望回退这次变基操作,你可以执行git branch --force inspiration 88e8b4b 来重置inspiration分支指针,将其指回原来已经存在的提交上,从根本上回退变基操作。

       有时候执行git rebase 也会像执行git merge 或者git cherry-pick 一样操作失败。因为有可能在准备变基的这些提交当中,可能包含了一些已经被修改的内容而发生合并冲突。在解决变基冲突时,最主要的区别是,之前的提交已经解决了合并提交引发的冲突,所以变基冲突中不存在这类的冲突问题。

       如果前述的变基操作失败的话,输出看起来将会是这个样子的。
清单 6.8输出:变基冲突
file:///C:\Users\ADMINI~1\AppData\Local\Temp\msohtmlclip1\01\clip_image009.jpg

list6.8

list6.8

              1 显示前两行的输出和成功变基的输出是一样的;HEAD指针已经重定位,Git正在尝试将变更重新提交到新的位置。唯一不同的是,这次的变化不能自动合并。

              2 显示变基操作正在试图将多个来自同一个文件的修改进行合并。有时会成功,但是在这次操作中合并失败了,所以变基操作告诉用户需要手工解决这次合并。

              3 显示关于解决这次变基冲突的指导说明。

              三条建议分别是:
  • git rebase --continue    当手工解决掉冲突,并且已经使用git add将其标记为已修复之后,应该执行此条命令。它将继续合并变基操作的后续提交,如果都成功,将更新被变基的这条分支。
  • git rebase --skip   这条命令意味着,不解决当前冲突,忽略当前提交,继续合并后面的提交操作。当遇到如下场景,即本次提交的功能,已经在变基到的这条分支上被其他提交实现了,本次提交已经变的多余,那么就应该执行这条命令。
  • git rebase --abort    这条命令可以完全放弃当前变基操作,并恢复分支状态到变基操作之前。

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部