本文适合对git rebase命令，尤其是对使用git rebase命令合并提交的方法不太熟悉的开发人员阅读。读者朋友们在阅读过程中如有任何问题，欢迎留言评论。

前言

相信有一定开发经验的朋友对git都不会感到陌生，可能也或多或少听说过git rebase（变基）的大名。作为一个相对来说比较“高级”的git命令，其目的说到底还是为了帮助我们更好的协作。概括来说变基的功能主要有两个：

合并代码¹，类似于merge，但是变基后的分支历史更加简洁
合并提交，把几个实际上干了同一件事的提交合并成一个，目的也是为了简洁

从上面可以总结出，变基追求的就是“简洁²”。简洁的分支历史降低了代码审查的成本，自然也就提高了审查的效率，而代码审查可以说是保证代码质量的最重要的手段之一。本文的主题是功能二。

合并：最简单的情况

作为攻略的开始，我们先来研究一个最简单的情况，如下图所示（git log --oneline）：

提交42e5e66和2856d1f实际上做了同一件事，那就是修改启动成功日志的文案。如果你是代码审查者（实际上，我们自己往往是自己代码的第一个审查者），你肯定希望这两个提交合成一个，这样看起来更方便。那么我们该怎么做呢？
首先我们需要选择一个“参考提交”。什么是参考提交？参考提交是任意一个在我们需要合并的提交之前（更旧）的提交，在这个例子里就是05e4a0a。注意一定要是之前，因为参考提交本身是不参与合并的，举例来说如果你用2856d1f作为参考提交，那就没办法把它和42e5e66合并，因为你在交互界面根本看不到它。
解释完毕，我们开始实操。我们以05e4a0a为参考提交，进入变基操作的交互模式：

git rebase -i 05e4a0a

可以看到：

这个界面是怎么回事呢？可以分成两个部分来看，空行上面是参考提交之后的、我们可以修改的提交历史。空行下面则是说明书，告诉我们可以进行哪些操作，以及这些操作对应的含义。
这里我们需要注意一下提交历史的顺序，最旧的在最上面，但是我们合并是从新往旧合，也就是从下往上合。具体操作一下大家就清楚了，下面我们来合并2856d1f和42e5e66：

输入i进入编辑模式；
把42e5e66这一行的pick改成f或fixup，如果需要编写新的提交说明，在f或fixup后面添加-c或-C参数；
改完之后输入:wq确认并退出，如果在上一步添加了-c或-C参数，这时会进入一个新的编辑页面，按照提示编辑后输入:wq确认并退出即可。

到这里就合并成功了。我们再次查看提交历史：

可以看到我们已经成功的把两个提交合并成了一个新的提交。检查代码确定所有变更都在。接下来要做的是把本地的变更推送到远端。

推送：一定要小心

把合并后的提交历史推送到远端，可以分成两种情况来讨论：
第一种，如果修改的提交都是本地提交，换言之都还没有推送到远端的话，这种情况是比较简单的，可以直接拉取或推送，就如同没有修改提交一样。
第二种，如果修改的提交已经推送到远端，这种就比较麻烦了，因为别的用户也许已经基于远端的提交做出修改。这种情况下如果要提交，只能强制提交。
由于强制提交存在一定的风险，建议只修改本地未推送到远端的提交。

修改：更复杂的情况

所谓更复杂的情况，其实就是需要修改更多的提交历史。这里所说的修改不限于本文的主题合并，你也可以调换提交的顺序，只需把要调整的提交所在的行剪切到新的位置就行了，其它的操作和最简单的情况一样。你也可以执行交互界面下方说明书里列出来的任意操作。为了贴合主题，本节的例子还是讲合并，其它操作这里不再演示。请看下面的提交历史：

选定在这四个提交之前的05e4a0a作为参考提交，在交互界面对提交历史进行修改：

将红框中的三个提交与2856d1f合并，同时保留f1b5058，确定并退出后，再次查看提交历史：

合并成功。另外可以看到参考提交之后的提交ID都发生了变化，包括实际上没有参与合并的f1b5058。

参考文档

git-rebase Documentation

功能一相对简单，操作和merge差不太多，但是建议各位读者在实际应用之前，一定要弄懂变基到底做了什么事，和merge的区别在哪里，否则小心挨同事锤哈哈。参考链接在此。 ↩︎
虽说功能一和功能二的目的都是为了简洁，但是两个简洁的地方不一样，简单来说一个是合并历史，一个是提交历史，具体的可以参考这个链接或网上的其它资料，这里不再赘述。 ↩︎

git rebase合并提交攻略相关推荐

git rebase合并多次commi
将多次commit合并,只保留一次提交历史. 1.首先使用git log查看一下提交历史 [demo@ubuntu1204:zh_cn(bugfix/ycs-MOS-1503-notify-templ ...
从git commit号码 revert_git revert amp; git rebase amp; commit 分支图
今天学了几个git技巧,分享下: 问题一:上线后的代码出现问题,如何回滚代码? 代码合入master之后,上线发现有问题,其他同事也等待上线,怎么办? 使用git revert .参考 How to ...
git rebase：永远不要衍合那些已经推送到公共仓库的更新
衍合把一个分支整合到另一个分支的办法有两种:merge(合并) 和 rebase(衍合).在本章我们会学习什么是衍合,如何使用衍合,为什么衍合操作如此富有魅力,以及我们应该在什么情况下使用衍合. 衍 ...
git rebase 和 git merger
& git merge 在上图中,每一个绿框均代表一个commit.除了c1,每一个commit都有一条有向边指向它在当前branch当中的上一个commit. 图中的项目,在c2之后就开了另 ...
你什么时候使用git rebase而不是git merge？
什么时候建议使用git rebase与git merge ? 成功改造后我还需要合并吗? #1楼在合并/ rebase之前: A <- B <- C [master] ^\D <- ...
git rebase用法
开发任务分叉到两个不同分支,又各自提交了更新整合分支最容易的方法是 merge 命令. 它会把两个分支的最新快照(C3 和 C4)以及二者最近的共同祖先(C2)进行三方合并,合并的结果是生成一个新的 ...
这一次彻底搞懂 Git Rebase
使用 Git 已经好几年了,却始终只是熟悉一些常用的操作.对于 Git Rebase 却很少用到,直到这一次,不得不用. 一.起因上线构建的过程中扫了一眼代码变更,突然发现, commit 提交竟然 ...
git merge 与 git rebase的区别
转自:https://blog.csdn.net/liuxiaoheng1992/article/details/79108233 其实这个问题困扰我有一段时间,相信也有人和我一样有这个困扰,网上已有 ...
git rebase 变基
概念变基(Rebase)也是合代码的一种手段. 变基与合并(Merge)不同的是,他可以修改历史,使用rebase来代替merge合代码的话,得到的历史记录是一条直线提交历史,无分叉,很漂亮. 然而 ...

git rebase合并提交攻略

前言

合并：最简单的情况

推送：一定要小心

修改：更复杂的情况

参考文档

git rebase合并提交攻略相关推荐

最新文章

热门文章