---

Git Cherry-Pick 命令详解：从入门到精通

导言

在日常的 Git 工作流中，我们经常需要在不同的分支之间转移代码变更。最常见的方式是通过 git merge 将一个分支的全部历史合并到另一个分支，或者使用 git rebase 将一个分支的提交应用到另一个分支的顶端。然而，在某些特定场景下，我们可能只需要将某个分支上的个别提交（而不是整个分支的历史）应用到当前工作的分支上。这时，git cherry-pick 命令就派上用场了。

git cherry-pick 直译过来是“挑选樱桃”，这个比喻非常形象地说明了它的作用：从众多的提交（像树上的樱桃）中，挑选出你想要的那一个或几个，然后将它们“摘”下来，“放”到你当前所在的分支上。

本文将从 cherry-pick 的基本概念讲起，深入探讨其工作原理、常见用法、处理冲突的方法、高级选项以及何时应该使用和避免使用它，帮助你从入门到精通地掌握这个强大的 Git 工具。

什么是 Git Cherry-Pick？

git cherry-pick 命令的作用是：将指定的现有提交应用到当前 HEAD 指向的分支上。

简单来说，它会找到你指定的那个提交，计算出这个提交相对于其父提交的修改内容，然后尝试将这些修改应用到你当前所在的分支上。如果应用成功，Git 会在当前分支创建一个新的提交，这个新提交包含了与你指定的那个提交完全相同的代码修改，但它是一个全新的提交，拥有不同的 SHA-1 哈希值、不同的父提交以及可能不同的提交时间（如果不是使用特定选项）。

这与 merge 和 rebase 有本质区别：
* git merge 合并的是整个分支的历史，通常会创建一个合并提交（除非是快进合并）。
* git rebase 将一系列提交按顺序应用到新的基准之上，会重写提交历史。
* git cherry-pick 只针对你指定的单个或多个提交进行操作，将它们作为新的提交应用到当前分支，对被挑选提交的原分支没有影响。

为什么需要使用 Cherry-Pick？

了解 cherry-pick 的适用场景，有助于我们更好地理解其价值。以下是一些常见的使用场景：

1. 热修复 (Hotfix) 的快速应用： 当你在 master 或 main 分支上发现并修复了一个紧急 bug，生成了一个提交。这个修复也需要应用到正在开发的某个功能分支或即将发布的版本分支上。使用 cherry-pick 可以快速将这个 bug 修复提交应用到其他分支，而无需合并整个 master 分支。
2. 将特定功能或修复从一个分支移植到另一个： 你可能在一个实验性分支上开发了某个小功能或重要的 bug 修复，现在希望将其应用到主开发分支或其他功能分支上，但该实验性分支上的其他修改还不成熟，不能进行整体合并。
3. 跨分支协作中共享单个提交： 团队成员在不同分支上并行工作，其中一个分支上有一个提交对另一个分支的工作非常有帮助。可以使用 cherry-pick 来共享这个提交。
4. 清理提交历史（谨慎使用）： 在某些情况下，你可能在一系列提交中完成了多个不相关的修改，现在想将其中某个特定的修改提取出来应用到别处，或者在重写历史时只选择性地保留某些提交。
5. 从已关闭/废弃的分支中挽救工作： 某个分支被废弃，但上面的某个提交包含重要的、未合并到任何地方的代码。cherry-pick 可以帮助你找回这些提交。

Git Cherry-Pick 的基本用法

cherry-pick 的基本语法非常简单：

bash
git cherry-pick <commit-hash>

其中 <commit-hash> 是你要挑选的那个提交的 SHA-1 哈希值。你可以通过 git log 命令来查找提交的哈希值。

示例：

假设你有以下提交历史：

A --- B --- C (master)
\
D --- E --- F (feature)

你当前在 master 分支上，希望将 feature 分支上的提交 E 应用到 master 分支。

1. 首先，确保你在目标分支上（这里是 master）：
   bash
git checkout master
2. 找到提交 E 的哈希值。你可以切换到 feature 分支 (git checkout feature) 使用 git log 查看，或者在 master 分支上使用 git log feature 查看 feature 分支的日志，直到找到 E 的哈希值（假设是 e1f2d3）。
   bash
git log --oneline feature
# 可能会看到类似这样的输出：
# f4g5h6 (feature) Commit F message
# e1f2d3 Commit E message <-- 这个就是我们要找的
# d9c8b7 Commit D message
# ... (共同祖先及master上的提交)
3. 执行 cherry-pick 命令：
   bash
git cherry-pick e1f2d3

如果 cherry-pick 过程顺利完成（没有冲突），Git 会在 master 分支上创建一个新的提交。你的历史将变成：

A --- B --- C --- E' (master)
\
D --- E --- F (feature)

这里的 E' 是一个新的提交，它包含了提交 E 的所有修改内容。E' 的父提交是 C，而不是 D。

注意事项：

• cherry-pick 默认会为你挑选的提交创建一个新的提交。
• 新的提交的作者信息通常会保留原提交的作者和提交者信息（除非你使用特定选项或Git配置）。
• 如果 cherry-pick 过程中发生冲突，Git 会暂停操作，你需要手动解决冲突。

处理 Cherry-Pick 冲突

像 merge 和 rebase 一样，cherry-pick 也可能导致冲突。这是因为你要应用的修改与当前分支上的修改可能存在重叠或冲突。当冲突发生时，Git 会在终端显示提示，并暂停 cherry-pick 过程。

解决冲突的步骤与解决合并或变基冲突的步骤类似：

1. 查看状态： 使用 git status 命令，Git 会告诉你哪些文件发生了冲突（标记为 unmerged）。
2. 手动解决冲突： 编辑冲突的文件。Git 会在冲突区域使用特殊的标记（<<<<<<<, =======, >>>>>>>）来标识冲突的各个版本。你需要手动编辑文件，保留你想要的修改，删除标记。
3. 暂存已解决的文件： 解决完一个文件的冲突后，使用 git add <file> 将该文件添加到暂存区。重复此步骤直到所有冲突文件都被解决并暂存。
4. 继续 Cherry-Pick： 所有冲突都解决并暂存后，使用以下命令继续 cherry-pick 过程：
   bash
git cherry-pick --continue
   Git 会自动为你创建一个包含已解决冲突的新提交。提交消息通常会预填充为原 cherry-pick 的提交消息，并加上冲突解决的备注。

处理冲突时的其他选项：

• 放弃 Cherry-Pick： 如果在解决冲突过程中决定放弃本次 cherry-pick 操作，不想应用这个提交了，可以使用：
  bash
git cherry-pick --abort
  这会回到 cherry-pick 之前的状态。
• 跳过当前提交： 如果你在 cherry-pick 多个提交时遇到冲突，并且决定暂时跳过当前这个导致冲突的提交，可以使：
  bash
git cherry-pick --skip
  Git 会跳过当前的冲突提交，然后继续尝试 cherry-pick 队列中的下一个提交（如果还有的话）。

Git Cherry-Pick 的高级用法与选项

cherry-pick 命令有很多选项，可以帮助我们更灵活地控制其行为。

1. 挑选多个提交

你可以一次 cherry-pick 多个提交。按顺序指定提交的哈希值即可：

bash
git cherry-pick <hash1> <hash2> <hash3> ...

Git 会按照你指定的顺序依次尝试 cherry-pick 这些提交。如果在处理某个提交时发生冲突，Git 会暂停，直到你解决冲突并 git cherry-pick --continue 后，才会继续处理列表中的下一个提交。

2. 挑选一个提交范围

除了指定单个或多个不连续的提交，你也可以指定一个连续的提交范围进行 cherry-pick。这通常使用 Git 的范围表示法。

最常用的范围表示法是 start..end 或 start^..end。

• start..end: 表示从 start 提交的下一个提交开始，直到 end 提交（包含 end）。更准确地说，它表示所有能从 end 提交到达，但不能从 start 提交到达的提交。
• start^..end: 表示从 start 提交本身开始，直到 end 提交（包含 end）。这里的 ^ 表示 start 提交的父提交，所以 start^..end 表示的是 start 的父提交到 end 之间的所有提交，包括 start 和 end。

对于 cherry-pick 一个分支上的连续提交序列，通常使用 start^..end 这种形式，其中 start 是序列中的第一个提交，end 是序列中的最后一个提交。Git 会从 start 开始，依次 cherry-pick 到 end。

示例：

A --- B --- C (master)
\
D --- E --- F --- G (feature)

你希望将 feature 分支上从 E 到 G（包含 E 和 G）的提交都 cherry-pick 到 master 分支。提交 E 的哈希是 e1f2d3，提交 G 的哈希是 g7h8i9。

bash
git checkout master
git cherry-pick e1f2d3^..g7h8i9

Git 会先尝试 cherry-pick e1f2d3 (E)，然后是 f4g5h6 (F)，最后是 g7h8i9 (G)。

A --- B --- C --- E' --- F' --- G' (master)
\
D --- E --- F --- G (feature)

重要区别： git log A..B 显示的是在 B 分支但不在 A 分支的提交。而 git cherry-pick A..B (不带 ^) 行为可能会略有不同，它通常会包含从 A 之后到 B 的所有提交。为了明确包含起始提交 A 本身，并按照 A 到 B 的顺序 cherry-pick，使用 A^..B 是更安全和常见的做法。记住，Git 会按照提交的拓扑顺序（而不是简单的哈希列表顺序）来决定 cherry-pick 的次序，但对于一个简单的线性序列，通常就是你期望的顺序。

3. 只应用修改，不生成提交 (--no-commit)

有时你可能想将一个提交的修改应用到当前分支，但不想立即生成一个新的提交。你可能想将多个 cherry-pick 的修改合并成一个提交，或者在提交前做一些额外的修改。--no-commit 或 -n 选项可以实现这一点。

bash
git cherry-pick --no-commit <commit-hash>

执行此命令后，Git 会将指定提交的修改应用到你的工作区和暂存区，但不会自动生成提交。你可以接着做其他修改，然后使用 git commit 命令手动创建一个提交。

示例：

“`bash
git cherry-pick –no-commit e1f2d3 # 应用提交 E 的修改

现在工作区和暂存区有提交 E 的变化

… 做一些其他修改或 cherry-pick 其他提交 …

git add . # 暂存所有最终想要的修改
git commit -m “Applied E’s changes and some other fixes” # 创建一个新的提交
“`

4. 编辑提交消息 (--edit)

默认情况下，cherry-pick 创建的新提交会沿用原提交的提交消息。如果你想在创建提交时编辑提交消息，可以使用 --edit 或 -e 选项。

bash
git cherry-pick --edit <commit-hash>

执行此命令后，Git 会打开你的默认编辑器，让你修改新提交的提交消息，然后才会完成提交过程。

5. 记录原提交信息 (-x)

使用 -x 选项进行 cherry-pick 时，Git 会在生成的新提交消息中附加一行信息，说明这个提交是基于哪个原提交 cherry-pick 而来的。这有助于追踪代码的来源。

bash
git cherry-pick -x <commit-hash>

新的提交消息底部会加上类似这样的一行：

(cherry picked from commit e1f2d3f4g5h6i7j8k9l0m1n2o3p4q5r6s7t8u9v0)

这对于团队协作和历史追溯非常有用。

6. 保持作者信息 (--committer-action=)

cherry-pick 默认会保留原提交的作者信息，但提交者信息是你当前的用户。你可以使用 --committer-action= 选项来控制提交者的行为，但这通常不是必须的，默认行为已经很合理。

7. 允许空提交 (--allow-empty)

如果 cherry-pick 的提交应用到当前分支后，实际上没有产生任何修改（例如，原提交的修改已经被当前分支的其他提交包含或抵消了），默认情况下 cherry-pick 会失败并提示。使用 --allow-empty 选项可以强制 Git 即使没有修改也创建一个“空提交”。这在某些需要保留提交历史结构的自动化脚本中可能有用。

其他不常用但可能有的选项

• --gpg-sign / -S: 对新的提交进行 GPG 签名。
• --strategy=<strategy>: 指定合并策略（如 recursive, ours, theirs 等），用于解决冲突时。通常不需要手动指定。
• --strategy-option=<option>: 为合并策略指定选项。

Cherry-Pick 的内部工作原理（简化）

理解 cherry-pick 的工作原理有助于更好地使用它并解决潜在问题。

当你执行 git cherry-pick <commit-hash> 时，Git 大致执行以下步骤：

1. 确定原提交的父提交： Git 找到 <commit-hash> 指定的提交 (C)。
2. 计算差异 (Diff)： Git 计算提交 C 相对于其父提交 (P) 的修改内容。这相当于执行 git diff P C。
3. 将差异应用到当前分支： Git 尝试将步骤 2 计算出的修改内容应用到当前 HEAD 指向的提交 (H) 之上。这类似于一个三方合并过程，基准点是原提交的父提交 (P)，两个分支是原提交 (C) 和当前 HEAD (H)。Git 试图将 C 相对于 P 的变化应用到 H 上。
4. 创建新的提交： 如果应用成功且没有冲突，Git 会在当前分支上创建一个新的提交 (C’)，其内容包含了原提交 C 的修改，父提交是 H。这个新提交 C’ 有一个新的哈希值。
5. 处理冲突： 如果应用修改时与当前 HEAD (H) 上的内容发生冲突，Git 会暂停，将冲突标记到文件，让你手动解决。

关键点在于，cherry-pick 是基于修改内容进行的复制，而不是简单地复制提交对象。它创建的是一个包含相同修改的新提交。

何时应该小心使用 Cherry-Pick？

尽管 cherry-pick 非常有用，但过度或不恰当使用它可能会导致一些问题：

1. 生成重复的修改： Cherry-pick 会创建新的提交。如果之后你又将原提交所在的分支合并到当前分支，Git 可能会检测到同一套修改被引入了两次（一次通过 cherry-pick 的新提交，一次通过合并）。这可能导致冲突，或者更糟的是，Git 可能会认为这些修改已经存在，从而跳过它们，导致你期望通过合并引入的其他修改丢失。虽然 Git 的合并策略在很多情况下能处理这种情况，但重复的修改会使历史变得不那么清晰。
2. 污染提交历史： 频繁地 cherry-pick 大量提交会使得历史分支图变得复杂且难以理解，因为很多提交的修改内容实际上是重复的。
3. 丢失上下文： 单个提交通常是整个功能或修复流程的一部分。Cherry-picking 一个提交而忽略其前后的相关提交，可能会导致应用的代码不完整或引入新的 bug。

何时应优先考虑 Rebase 或 Merge：

• 如果你想将一个分支的所有修改应用到另一个分支，并且希望保留原始的合并历史图，使用 git merge。
• 如果你想将一个分支的所有修改应用到另一个分支，并且希望得到一个干净、线性的提交历史，优先考虑 git rebase。

cherry-pick 最适合处理少量、独立、紧急的提交。

Best Practices for Cherry-Picking

• 仅挑选必要的提交： 不要一次 cherry-pick 大量的提交，如果需要移植大量修改，考虑 rebase 或 merge。
• 在解决冲突时保持谨慎： 仔细检查冲突标记，确保你理解并正确地解决了所有冲突。
• 考虑使用 -x 选项： 在新提交中记录原提交的哈希值，以便追溯。
• 对于连续的、逻辑相关的提交序列，考虑 cherry-pick 一个范围 (start^..end)： 这比一个一个挑要方便且不容易遗漏。
• 对于临时性的、小范围的修改，可以考虑使用 --no-commit： 将多个小改动合并成一个更有意义的提交。
• 在公共/共享分支上谨慎使用： Cherry-pick 会改变分支历史（通过创建新提交），在多人协作的公共分支上频繁使用可能引起混乱。最好在自己的特性分支上进行 cherry-pick。
• 理解 Git 历史图： 使用 git log --graph --oneline --all 查看分支历史图，更好地理解提交之间的关系，这有助于你决定是否需要 cherry-pick 以及挑选哪个提交。

Cherry-Pick 示例演示

让我们通过一个稍微复杂点的示例来演示 cherry-pick 的多种用法。

假设有以下历史：

A --- B --- C (master)
\
D --- E --- F (feature)
\
G --- H (bugfix)

• master 是主分支。
• feature 分支从 A 分出，有 D, E, F 三个提交。
• bugfix 分支从 feature 的 E 分出，有 G, H 两个提交。

场景：

1. 提交 G 是在 bugfix 分支上修复了一个重要的 bug。这个 bug 也存在于 master 和 feature 分支上。我们需要将 G 应用到 master 和 feature。
2. 提交 F 是在 feature 分支上完成了一个小功能。现在这个小功能也需要集成到 master 上，但 feature 分支上的其他工作（比如 F 之后的提交，如果存在）还不适合合并。
3. 我们发现 feature 分支上的提交 E 实际上引入了一个问题，我们希望在 master 分支上避免这个提交，但 bugfix 分支的工作 (G, H) 是基于 E 的。

操作步骤：

Part 1: 将 Bug 修复 G 应用到 master 和 feature

• 将 G 应用到 master：

  1. 切换到 master 分支：git checkout master
  2. 找到提交 G 的哈希值（假设是 g7h8i9）。
  3. Cherry-pick G：git cherry-pick g7h8i9
  4. 解决可能出现的冲突（如果 G 的修改与 master 上的 C 冲突），然后 git add . 并 git cherry-pick --continue。
     完成后历史：A --- B --- C --- G' (master)

• 将 G 应用到 feature：

  1. 切换到 feature 分支：git checkout feature
  2. Cherry-pick G：git cherry-pick g7h8i9
  3. 解决可能出现的冲突（如果 G 的修改与 feature 上的 F 冲突），然后 git add . 并 git cherry-pick --continue。
     完成后历史：A --- D --- E --- F --- G'' (feature) (注意 G’ 和 G” 是不同的提交，但包含相同修改)

Part 2: 将功能 F 应用到 master

• 将 F 应用到 master：
  1. 切换到 master 分支：git checkout master
  2. 找到提交 F 的哈希值（假设是 f4g5h6）。
  3. Cherry-pick F：git cherry-pick f4g5h6
  4. 解决可能出现的冲突（如果 F 的修改与 master 上已有的 C 或 G’ 冲突），然后 git add . 并 git cherry-pick --continue。
     完成后历史：A --- B --- C --- G' --- F' (master)

当前的整体历史可能类似：

A --- B --- C --- G' --- F' (master)
\
D --- E --- F --- G'' (feature)
\
G --- H (bugfix)

Part 3: 使用 --no-commit 合并 bugfix 的 G 和 H 到 master (另一种方式，假设 Part 1/2 还没做)

假设我们决定不单独 cherry-pick G，而是将 bugfix 分支上的 G 和 H 合并到 master 的一个新提交中。

1. 切换到 master 分支：git checkout master
2. 找到提交 G 的哈希值（g7h8i9）和 H 的哈希值（h0i1j2）。
3. 使用 --no-commit 挑选 G 和 H：
   bash
git cherry-pick --no-commit g7h8i9 h0i1j2
   Git 会将 G 和 H 的修改内容应用到工作区和暂存区。
4. 做一些额外的清理或合并工作（可选）。
5. 检查 git status 确保所有期望的修改都在暂存区。
6. 创建新的提交：
   bash
git commit -m "Applied bug fixes G and H from bugfix branch"
   Git 会创建一个新的提交，包含 G 和 H 的所有修改。

总结

git cherry-pick 是一个强大而灵活的工具，它允许你精确地选择并应用 Git 仓库中的单个或一系列提交到当前工作分支。它在处理热修复、移植特定功能以及从复杂分支历史中提取有用修改等场景中表现出色。

然而，像所有强大的工具一样，cherry-pick 应该被谨慎使用。过度或不恰当的使用可能导致历史混乱、重复修改以及潜在的未来合并问题。在决定使用 cherry-pick 之前，请考虑 git merge 或 git rebase 是否是更合适的解决方案，特别是当你需要集成大量修改或整个分支历史时。

熟练掌握 cherry-pick 及其选项，理解其背后的工作原理，并结合冲突解决的技巧，将显著提升你在复杂 Git 工作流中的效率和灵活性。希望本文能帮助你从 Git cherry-pick 的新手蜕变为精通者！

---