Git 操作补充：cherry-pick、变基

1. 挑选提交合并 git cherry-pick

对于多分支的代码库，将代码从一个分支转移到另一个分支是一种常见的需求，这可以分成两种情况：一种情况是，你需要另一个分支的所有代码变动，那么就采用 git merge；另一种情况是，你只需要部分代码变动（某几个提交），这时可以采用 git cherry-pick，语法为：git cherry-pick <commitHash>，将指定提交合并到另一个分支。

举例来说，假设代码仓库有 master 和 feature 两个分支，提交历史如下，现在将 feture 分支的提交 f 应用到 master 分支。

a - b - c - d   Master
    \
     e - f - g Feature

# 切换到 master 分支
$ git checkout master# Cherry pick 操作
$ git cherry-pick f

上面的操作完成以后，代码库就变成了下面的样子（master 分支的末尾增加了一个提交 f）。

a - b - c - d - f   Master
    \
     e - f - g Feature

# 参数为分支名，表示转移该分支的最新一次提交。
$ git cherry-pick feature# 一次转移多个提交
$ git cherry-pick <HashA> <HashB>
# 上述命令能将 A 和 B 两个提交应用到当前分支，这会在当前分支生成两个对应的新提交。# 转移一系列的连续提交，可以使用下面的简便语法
$ git cherry-pick A..B 
# 上述命令将转移从 A 到 B （不包括A）的所有提交，A、B的顺序一定要正确：提交 A 必须早于提交 B，否则命令将失败，但不会报错。# 转移从 A 到 B （包括A）的所有提交
$ git cherry-pick A^..B

2. 变基 git rebase

在 Git 中，整合来自不同分支的修改，除了 merge，还有一种方法，变基 rebase。git rebase 命令基本是一个自动化的 cherry-pick 命令，它计算出一系列的提交，然后在其地方以同样的顺序一个一个的 cherry-pick 它们。

Git 中有一些修改会覆盖提交历史，列举如下，在使用这些命令时，需要谨慎操作，以免不小心覆盖提交历史，导致代码丢失或者出现其他问题。

1. 使用 git commit --amend 命令修改最近一次提交的信息，会覆盖最近一次提交的记录。
2. 使用 git rebase 命令修改提交记录，这会修改提交的 SHA-1 校验和，覆盖提交历史。
3. 使用 git reset 命令回滚到之前的提交，这会删除之后的提交历史。
4. 使用 git push --force 命令强制推送修改，这会覆盖远程分支的提交历史。

2.1 Case 1：git rebase <upstream> 

假设在一个项目开发过程中，分叉到两个不同分支，每个分支都提交了更新。

可以使用 merge 命令整合分支，它会把两个分支的最新快照（C3 和 C4）以及二者最近的共同祖先（C2）进行三方合并，合并的结果是生成一个新的快照（并提交）。

还有一种方法：使用变基 git rebase 整合分支，git rebase 的语法可以简写为：git rebase [--onto <newbase>] [<upstream> [<branch>]]，表示将 <branch> 分支从 <upstream> 开始的提交应用到 <newbase> 分支上。具体来说，它会将 <branch> 分支自 <upstream> 之后的提交移动到 <newbase> 分支的最新提交之后，使得 <branch> 分支的提交历史看起来像是在 <newbase>分支的基础上进行的。

可以省略的参数是 <newbase> 和 <branch>；如果省略 --onto 参数，将以 <upstream> 参数指定的分支作为基底进行变基操作。也就是说，将当前所在分支（HEAD 指向的分支）与 <upstream> 参数指定的分支之间的差异应用到 <upstream>分支上；如果省略 <branch>，将把当前所在分支，即 HEAD 指向的分支，作为 <branch> 参数传递给 git rebase 命令。

 

$ git checkout experiment$ git rebase master

接下来运行 git checkout master 回到 master 分支，然后运行 git merge experiment 进行一次快进合并。C4' 指向的快照就和使用 merge 得到的 C5 指向的快照一模一样，这两种整合方法的最终 结果没有任何区别，但是变基使得提交历史更加整洁。 你在查看一个经过变基的分支的历史记录时会发现，尽管实际的开发工作是并行的，但它们看上去就像是串行的一样，提交历史是一条直线没有分叉。

一般这样做的目的是为了确保在向远程分支推送时能保持提交历史的整洁，例如向某个其他人维护的项目贡献代码时。在这种情况下，你首先在自己的分支里进行开发，当开发完成时你需要先将你的代码变基到 origin/master 上，然后再向主项目提交修改。这样的话，该项目的维护者就不再需要进行整合工作，只需要快进合并便可。

2.2 Case2：git rebase [--onto <newbase>] [<upstream> [<branch>]] 

假设你的项目提交历史如下：你创建了一个特性分支 server，为服务端添加了一些功能，提交了 C3 和 C4。然后从 C3 上创建了特性分支 client，为客户端添加 了一些功能，提交了 C8 和 C9。 最后，你回到 server 分支，又提交了 C10。

 

你希望将 client 中的修改合并到 master 主分支并发布，但暂时并不想合并 server 中的修改，因为它们还需要经过更全面的测试。这时，你可以使用 git rebase 命令的 --onto 选项，选择在 client 分支里但不在 server 分支里的修改（即 C8 和 C9），将它们应用在 master 分支上。

运行命令：git rebase --onto master server client，其含义是：“取出 client 分支，找出处于 client 分支和 server 分支的共同祖先之后的修改，然后把它们在 master 分支上重放一遍”。然后将 client 合并到 master。

$ git rebase --onto master server client
$ git checkout master
$ git merge client
$ git rebase master server
$ git checkout master
$ git merge server$ git branch -d client
$ git branch -d server

2.3 Case3：变基使用不当的风险

警告：不要对仓库外有副本的分支执行变基。如果你遵循这条金科玉律，就不会出差错。 否则，人民群众会仇恨你，你的朋友和家人也会嘲笑你，唾弃你。-- Scott Chacon

只要你把变基命令当作是在推送前清理提交使之整洁的工具，并且只在从未推送至共用仓库的提交上执行变基命令，就不会有事。 假如在那些已经被推送至公用仓库的提交上，执行变基命令，并因此丢弃了一些别人的开发所基于的提交，那你就有大麻烦了，你的同事也会因此鄙视你。

2.3.1 变基使用不当的例子

假设你从一个中央服务器克隆然后在它的基础上进行了一些开发，提交历史如图所示：

一段时间后，其他项目成员向中央服务器提交了一些修改，其中包括一次合并。 

你抓取了这些在远程分支上的修改，并将其合并到你本地的开发分支，你的提交历史如下：

接下来，这个成员又决定把合并操作回滚，改用变基，并用 git push --force 命令强制推送修改，这会覆盖远程分支的提交历史。

此时，你从服务器抓取更新，会发现多出来一些新的提交。如果你执行 git pull 命令，你将合并来自两条提交历史的内容，生成一个新的合并提交 C8。

此时，如果你执行 git log 命令，你会发现有两个提交的作者、日期、日志居然是一样的，这会令人感到混乱。 此外，如果你将这一堆又推送到服务器上，实际上是将那些已经被变基抛弃的提交又找了回来，这会令人感到更加混乱。很明显对方并不想在提交历史中看到 C4 和 C6，因为之前就是他把这两个提交通过变基丢弃的。

2.3.2 解决方法

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

方案1：git fetch + git rebase：在一个被变基然后强制推送的分支上再次执行变基

对于这种，有人推送了经过变基的提交，并丢弃了你的本地开发所基于的一些提交，不要使用 git pull，而是先 git fetch，再执行 git rebase teamone/master, Git 将会：

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

想要上述方案有效，还需要对方在变基时确保 C4' 和 C4 是几乎一样的。 否则变基操作将无法识别，并新建另一个类似 C4 的补丁（而这个补丁很可能无法整洁的整合入历史，因为补丁中的修改已经存在于某个地方了）。

方案2：使用 git pull --rebase 而不是直接用 git pull

如果你或你的同事在某些情形下，不得不强制推送经过变基的提交，请一定要通知每个人执行 git pull --rebase 命令，这样尽管不能避免麻烦，但能有所缓解。