中国领先的IT技术网站
51CTO旗下网站
Git Rebase教程： 用Git Rebase让时光倒流
本文作者 Christoph Burgdorf自10岁时就是一名程序员，他是HannoverJS Meetup网站的创始人，并且一直活跃在AngularJS社区。他也是非常了解gti的内内外外，在那里他举办一个thoughtram的工作室来帮助初学者掌握该技术。
作者：译者：geekpi来源：Linux中国| 11:01
想象一下你正在开发一个激进的新功能。这将是很灿烂的但它需要一段时间。您这几天也许是几个星期一直在做这个。
你的功能分支已经超前master有6个提交了。你是一个优秀的开发人员并做了有意义的语义提交。但有一件事情：你开始慢慢意识到，这个疯狂的东西仍需要更多的时间才能真的做好准备被合并回主分支。
m1-m2-m3-m4 (master)
f1-f2-f3-f4-f5-f6(feature)
你也知道的是，一些地方实际上是交叉不大的新功能。它们可以更早地合并到主分支。不幸的是，你想将部分合并到主分支的内容存在于你六个提交中的某个 地方。更糟糕的是，它也包含了依赖于你的功能分支的之前的提交。有人可能会说，你应该在第一处地方做两次提交，但没有人是完美的。
m1-m2-m3-m4 (master)
f1-f2-f3-f4-f5-f6(feature)
mixed commit
在你准备提交的时间，你没有预见到，你可能要逐步把该功能合并入主分支。哎呀！你不会想到这件事会有这么久。
你需要的是一种方法可以回溯历史，把它并分成两次提交，这样就可以把代码都安全地分离出来，并可以移植到master分支。
用图说话，就是我们需要这样。
m1-m2-m3-m4 (master)
f1-f2-f3a-f3b-f4-f5-f6(feature)
在将工作分成两个提交后，我们就可以cherry-pick出前面的部分到主分支了。
原来Git自带了一个功能强大的命令git rebase -i
，它可以让我们这样做。它可以让我们改变历史。改变历史可能会产生问题，作为一个经验，应尽快避免历史与他人共享。不过在我们的例子中，我们只是改变我们 的本地功能分支的历史。没有人会受到伤害。就这么做了！
好吧，让我们来仔细看看f3提交究竟修改了什么。原来我们共修改了两个文件：userService.js和 wishlistService.js。比方说，userService.js的更改可以直接合入主分支而wishlistService.js不能。因 为wishlistService.js甚至不存在在主分支里面。它是f1提交中引入的。
专家提示：即使是在一个文件中更改，git也可以搞定。但这篇博客中我们先简化情况。
我们已经建立了一个，我们将使用这个来练习。为了便于跟踪，每一个提交信息的前缀是在上面的图表中使用的假的SHA。以下是git在分开提交f3时的分支图。
现在，我们要做的第一件事就是使用git的checkout功能checkout出我们的功能分支。用git rebase -i master开始做rebase。
现在接下来git会用所配置的编辑器打开（默认为Vim）一个临时文件。
该文件为您提供一些rebase选择，它带有一个提示（蓝色文字）。对于每一个提交，我们可以选择的动作有pick、rwork、edit、 squash、fixup和exec。每一个动作也可以通过它的缩写形式p、r、e、s、f和e引用。描述每一个选项超出了本文范畴，所以让我们专注于我 们的具体任务。
我们要为f3提交选择edit选项，因此我们把内容改变成这样。
现在我们保存文件（在Vim中是按下后输入:wq,最后是按下回车）。接下来我们注意到git在编辑选项中选择的提交处停止了rebase。
这意味这git开始将f1、f2、f3生效仿佛它就是常规的rebase，但是在f3生效之后停止。事实上，我们可以看一眼停止的地方的日志就可以证明这一点。
要将f3分成两个提交，我们所要做的是重置git的指针到先前的提交（f2）而保持工作目录和现在一样。这就是git
reset在混合模式在做的。由于混合模式是git reset的默认模式，我们可以直接用git reset
head~1。就这么做并在运行后用git status看下发生了什么。
git status告诉我们userService.js和wishlistService.js被修改了。如果我们运行 git diff 我们就可以看见在f3里面确切地做了哪些更改。
如果我们看一眼日志我们会发现f3已经消失了。
现在我们有了准备提交的先前的f3提交，而原先的f3提交已经消失了。记住虽然我们仍旧在rebase的中间过程。我们的f4、f5、f6提交还没有缺失，它们会在接下来回来。
让我们创建两个新的提交：首先让我们为可以提交到主分支的userService.js创建一个提交。运行git add userService.js 接着运行 git commit -m &f3a: add updateUser method&。
太棒了！让我们为wishlistService.js的改变创建另外一个提交。运行git add wishlistService.js，接着运行git commit -m &f3b: add addItems method&.
让我们在看一眼日志。
这就是我们想要的，除了f4、f5、f6仍旧缺失。这是因为我们仍在rebase交互的中间，我们需要告诉git继续rebase。用下面的命令继续：git rebase --continue。
让我们再次检查一下日志。
就是这样。我们现在已经得到我们想要的历史了。先前的f3提交现在已经被分割成两个提交f3a和f3b。剩下的最后一件事是cherry-pick出f3a提交到主分支上。
为了完成最后一步，我们首先切换到主分支。我们用git checkout master。现在我们就可以用cherry-pick命令来拾取f3a commit了。本例中我们可以用它的SHA值bd47ee1来引用它。
现在f3a这个提交就在主分支的最上面了。这就是我们需要的！
这篇文章的长度看起来需要花费很大的功夫，但实际上对于一个git高级用户而言这只是一会会。
注：Christoph目前正在与Pascal Precht写一本关于的书，您可以在leanpub订阅它并在准备出版时获得通知。
本文作者 Christoph Burgdorf自10岁时就是一名程序员，他是HannoverJS Meetup网站的创始人，并且一直活跃在AngularJS社区。他也是非常了解gti的内内外外，在那里他举办一个的工作室来帮助初学者掌握该技术。
本的教程最初发表在他的。
作者： 译者： 校对：
原创翻译， 荣誉推出【编辑推荐】【责任编辑： TEL：（010）】
大家都在看猜你喜欢
原创头条头条外电头条
24H热文一周话题本月最赞
讲师：0人学习过
讲师：0人学习过
讲师：5人学习过
精选博文论坛热帖下载排行
本书全面深入地介绍网络安全的配置与实现技术，包括系统管理、用户账户、病毒防御、灾难恢复、文件备份、安全策略、注册表等服务器安全，用...
订阅51CTO邮刊问题对人有帮助，内容完整，我也想知道答案
问题没有实际价值，缺少关键内容，没有改进余地
发现执行git rebase -i HEAD~10时候有时候会遇到冲突，目前发现一种会产生冲突的情况。如下：从master分支创建出b1,b2分支，两个分支都修改了同一个位置。在master分支先后merge b1、b2，merge b2时出现冲突，解决冲突并产生merge commit。此时git rebase -i HEAD~10会出现问题：
b1、b2的两个commit会产生冲突
rebase -i时候没有看到merge commit
冲突明明在merge commit中解决了，为什么还会有冲突，且merge commit没了。该如何正确地解决冲突？显然我要到得到的结果在merge commit里。或者什么样的工作流能避免冲突？
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
手工把冲突的文件改好后git add/git commit
不管你用什么工作流，只要两个人有可能同时去改同一个文件，你就没法避免merge conflict，所以要从分工作起。
同步到新浪微博
分享到微博？
Hi，欢迎来到 SegmentFault 技术社区！⊙▽⊙ 在这里，你可以提出编程相关的疑惑，关注感兴趣的问题，对认可的回答投赞同票；大家会帮你解决编程的问题，和你探讨技术更新，为你的回答投上赞同票。
明天提醒我
关闭理由：
删除理由：
忽略理由：
推广（招聘、广告、SEO 等）方面的内容
与已有问题重复（请编辑该提问指向已有相同问题）
答非所问，不符合答题要求
宜作评论而非答案
带有人身攻击、辱骂、仇恨等违反条款的内容
无法获得确切结果的问题
非开发直接相关的问题
非技术提问的讨论型问题
其他原因（请补充说明）
我要该，理由是：
扫扫下载 App1330人阅读
对于git rebase,你亦可以选择进行交互式的rebase。这种方法通常用于在向别处推送提交之前对它们进行重写。交互式rebase提供了一个简单易用的途径让你在和别人分享提交之前对你的提交进行分割、合并或者重排序。在把从其他开发者处拉取的提交应用到本地时，你也可以使用交互式rebase对它们进行清理。
如果你想在rebase的过程中对一部分提交进行修改，你可以在'git rebase'命令中加入'-i'或'--interactive'参数去调用交互模式。
$ git rebase -i origin/master
这个命令会执行交互式rebase操作，操作对象是那些自最后一次从origin仓库拉取或者向origin推送之后的所有提交。
若想查看一下将被rebase的提交，可以用如下的log命令：
$ git log github/master..
一旦运行了'rebase -i'命令，你所预设的编辑器会被调用，其中含有如下的内容：
pick fc62e55 added file_size
pick 9824bf4 fixed little thing
pick 21d80a5 added number to log
pick 76b9da6 added the apply command
pick c264051 Revert &added file_size& - not implemented correctly
# Rebase f408319..b04dc3d onto f408319
# Commands:
#& p, pick = use commit
#& e, edit = use commit, but stop for amending
#& s, squash = use commit, but meld into previous commit
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
这些信息表示从你上一次推送操作起有5个提交。每个提交都用一行来表示，行格式如下：
(action) (partial-sha) (short commit message)
现在你可以将操作（action）改为'edit'（使用提交，但是暂停以便进行修正）或者'squash'（使用提交，但是把它与前一提交合并），默认是'pick'（使用提交）。你可以对这些行上下移动从而对提交进行重排序。当你退出编辑器时，git会按照你指定的顺序去应用提交，并且做出相应的操作（action）。
二、pick操作
如果指定进行'pick'操作，git会应用这个补丁，以同样的提交信息（commit message）保存提交。
三、squash操作
如果指定进行'squash'操作，git会把这个提交和前一个提交合并成为一个新的提交。这会再次调用编辑器，你在里面合并这两个提交的提交信息。所以，如果你（在上一步）以如下的内容离开编辑器：
pick&& fc62e55 added file_size
squash 9824bf4 fixed little thing
squash 21d80a5 added number to log
squash 76b9da6 added the apply command
c264051 Revert &added file_size& - not implemented correctly
你必须基于以下的提交信息创建一个新的提交信息：
# This is a combination of 5 commits.
# The first commit's message is:
added file_size
# This is the 2nd commit message:
fixed little thing
# This is the 3rd commit message:
added number to log
# This is the 4th commit message:
added the apply command
# This is the 5th commit message:
Revert &added file_size& - not implemented correctly
This reverts commit fc62ed5a7eca38e84.
一旦你完成对提交信息的编辑并且退出编辑器，这个新的提交及提交信息会被保存起来。
四、edit操作
如果指定进行'edit'操作，git会完成同样的工作，但是在对下一提交进行操作之前，它会返回到命令行让你对提交进行修正，或者对提交内容进行修改。
例如你想要分割一个提交，你需要对那个提交指定'edit'操作：
pick&& fc62e55 added file_size
pick&& 9824bf4 fixed little thing
& 21d80a5 added number to log
pick&& 76b9da6 added the apply command
pick&& c264051 Revert &added file_size& - not implemented correctly
你会进入到命令行，重置（reset）该提交，然后创建两个（或者更多个）新提交。假设提交21d80a5修改了两个文件，file1和file2，你想把这两个修改放到不同的提交里。你可以在进入命令行之后进行如下的操作：
$ git reset HEAD^
$ git add file1
$ git commit 'first part of split commit'
$ git add file2
$ git commit 'second part of split commit'
$ git rebase --continue
现在你有6个提交了，而不是5个。
五、丢弃提交操作
交互式rebase的最后一个作用是丢弃提交。如果把一行删除而不是指定'pick'、'squash'和‘edit''中的任何一个，git会从历史中移除该提交。
&&相关文章推荐
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：637775次
积分：7684
积分：7684
排名：第2505名
原创：170篇
转载：112篇
评论：89条
(2)(1)(2)(1)(3)(4)(8)(6)(1)(2)(5)(1)(1)(3)(15)(7)(22)(8)(7)(1)(2)(2)(8)(3)(18)(42)(80)(28)Git之rebase操作分享
招聘信息：
进入点融之前，笔者的版本控制一直用的是SVN。在加入点融后，接触到了GIT，也使笔者有机会学习到更为广泛应用的GIT版本控制。通过同事帮助和自主学习，以及在一些网络上学习到Git相关知识的基础之上，笔者将从大的方面来阐述一下GIT与SVN的区别。1、控制版本最核心的区别，GIT是分布式控制版本，而SVN不是。GIT跟SVN一样有自己的集中式版本库或服务器，但是GIT更倾向于被使用于分布式模式，也就是每个开发人员从中心版本库/服务器上checkout代码后会在自己的机器上克隆一个自己的版本库。举个例子，如果你被困在一个不能连接网络的地方时，如飞机上，地下室，电梯里等，你仍然能够提交文件，查看历史版本记录，创建项目分支等等。2、存储方式GIT把内容按元数据方式存储，而SVN是按文件。所有的资源控制系统都是把文件的元信息隐藏在一个类似.svn，.cvs等的文件夹里。如果你把.git目录的体积大小跟.svn比较，你会发现它们差距很大。因为.git目录是处于你的机器上的一个克隆版的版本库，它拥有中心版本库上所有的东西，例如标签，分支，版本记录等。3、分支GIT分支和SVN的分支不同。分支在SVN中一点不特别，就是版本库中的另外的一个目录。然而，处理GIT的分支却是相当的简单和有趣。你可以从同一个工作目录下快速的在几个分支间切换。你很容易发现未被合并的分支，你能简单而快捷的合并这些文件。4、rebase命令的操作言归正传，接下来，本文将主要介绍的rebase命令的操作。在实际项目开发过程当中，开发人员都会从远程主分支克隆代码到本地，然后在此基础之上，进行自己的功能开发。在本地开发的同时，远程主分支也会不断有其他同事开发的功能被push上去。在本地开发的代码，可以通过fetch，然后在merge提交到本地或者直接pull到本地来做作为本地同步远程代码的目的，当然在此笔者主要想讲述的是如何通过统一远程和本地的代码的log，从而神不知鬼不觉的去同步代码。我们来具体演示一下rebase的用法。首先克隆远程主分支到本地主分支(master)，然后创建自己的分支(test)，具体demo如下图所示：此时test分支的版本如下：主分支master，在其他同事的不断push后，现在的版本如下：如上图所示，当前主分支有新的代码提交，本地分支开发人员每天也会有新的代码提交。但是往往一个功能模块的开发是需要好几天才能完成的，故一个功能点往往会产生多个log，关于如何合并多个提交log，后面会讲述(详见步骤８)。接下来，在本地开发人员进行功能开发结束后，如下图所示：如上图所示，可以看到开发人员在本地分支提交了３次代码，完成了功能开发，接下来就要进行rebase操作，如下图所示：在rebase过程当中可能需要处理一些冲突，具体操作如下图所示：如上图所示，rebase结束，具体结果如下所示：接下来主要看一下，如果合并分支多次提交log，运行命令如下：gitrebase -i 9b67ef73baad76de0dee444fa9d892会跳出vim编辑模式，修改除第一个外的后面几个pick为s或者squash，将log改为：test合并之前提交的1,2,3；如下所示：到此合并结束，具体结果如下：至此，这个rebase基本功能用法就介绍完毕了。在操作过程当中，可能要解决一些冲突，merge一些代码，提交之后，才可以继续操作。一般情况下，敲入命令:git status，查看当前版本下的提示情况之后，再进行相应操作，就可以了。希望笔者对此命令的一些心得体会可以帮助更多的开发人员理解GIT，可以更好的上手应用GIT，有更多关于GIT的心得体会，欢迎与笔者探讨。
微信扫一扫
订阅每日移动开发及APP推广热点资讯公众号：CocoaChina
您还没有登录！请或
点击量4638点击量4618点击量4560点击量4111点击量3762点击量3269点击量2787点击量2696点击量2694
&2016 Chukong Technologies,Inc.
京公网安备89