Git cherry-pick 如何同时应用多个 commit – wiki基地

作者： /

深入解析 Git cherry-pick: 高效处理与同时应用多个提交

在日常的 Git 工作流中，我们经常需要在不同的分支之间转移代码变更。最常见的操作是使用 git merge 或 git rebase 来整合整个分支的历史。然而，有时我们并不需要或不希望集成整个分支的所有提交，而只需要将其中几个特定的提交（commit）应用到当前分支上。这时，git cherry-pick 命令就显得尤为重要。

git cherry-pick 允许你“挑选”一个或多个提交，并将它们应用到当前 HEAD 指向的分支上。这个过程就像是从一个分支的提交历史中摘取“樱桃”一样，因此得名。虽然 cherry-pick 最常见的用法是挑选单个提交，但在实际开发中，尤其是需要将一系列相关的 bug 修复或小功能从一个分支转移到另一个分支时，同时应用多个提交的能力是极其强大且高效的。

本文将深入探讨 git cherry-pick 的基本概念，重点介绍如何同时应用多个提交，包括不同的方法、实际操作示例、可能遇到的问题及解决方案，以及何时应该使用或避免使用 cherry-pick。

第一部分：理解 Git cherry-pick 的核心概念

在详细讲解如何应用多个提交之前，我们先快速回顾一下 cherry-pick 的工作原理和基本用途。

1.1 cherry-pick 是什么？

git cherry-pick <commit> 命令的作用是将指定的 <commit> 所代表的修改内容应用到当前 HEAD 所指向的分支上。本质上，Git 会找到指定提交与其父提交之间的差异（diff），然后尝试将这个差异应用到当前分支的最新提交之后。如果应用成功，Git 会在当前分支上创建一个新的提交，这个新提交包含了原提交的修改内容，但拥有不同的 SHA-1 哈希值和新的父提交。

关键点： cherry-pick 创建的是一个新的提交，而不是简单地移动或复制原有的提交。这意味着原提交的历史信息（如作者、提交信息、提交时间）会被保留（可以通过 -x 或 --signoff 选项添加额外信息），但提交本身在图谱上是一个全新的节点。

1.2 为什么使用 cherry-pick？

cherry-pick 在以下场景中特别有用：

  • 回溯修复 (Backporting Bug Fixes): 当你在开发分支（如 develop）或主分支（如 main）上修复了一个严重的 bug，而这个 bug 也存在于一个或多个已发布的稳定版本分支（如 release-1.0, release-1.1）上时，你可以使用 cherry-pick 将包含 bug 修复的提交单独应用到这些稳定分支上，而无需合并整个开发分支。
  • 选择性地引入功能/修改: 有时一个特性分支包含多个提交，其中一部分是核心功能，另一部分可能是实验性或不相关的修改。你可能只想将核心功能的几个提交应用到另一个分支上。
  • 清理合并历史: 在某些情况下，你可能需要将一个分支上的零散提交整理到另一个分支上，同时避免引入不相关的历史。cherry-pick 结合 --no-commit 选项可以帮助实现这一点。
  • 从错误的分支上抢救提交: 如果你不小心在一个错误的分支上完成了一些提交，可以使用 cherry-pick 将这些提交转移到正确的分支上，然后丢弃错误分支上的提交。

1.3 与 merge 和 rebase 的对比

理解 cherry-pick 的最佳方式之一是将其与 merge 和 rebase 进行对比：

  • git merge: 将整个分支的历史合并到当前分支。它会创建一个新的合并提交（默认情况下），保留两个分支的完整历史。适用于整合一个完整的功能或版本分支。
  • git rebase: 将当前分支的提交“移动”或“重写”到目标分支的最新提交之后。它会创建一系列新的提交（每个原提交对应一个新提交），形成一个更线性的提交历史。适用于将特性分支的修改同步到主干分支，保持历史整洁。
  • git cherry-pick: 只选择性地应用一个或多个提交的修改到当前分支，创建新的提交。不关心原分支的整体历史。适用于只需要部分提交的场景。

简单来说，merge 和 rebase 是“批量处理”分支集成，而 cherry-pick 是“精细选择”单个或多个提交应用。

第二部分：如何同时应用多个提交 (Applying Multiple Commits)

git cherry-pick 命令不仅支持单个提交的哈希值作为参数，也支持同时指定多个提交。这极大地提高了在需要转移一系列相关提交时的效率。以下是几种常用的方法：

2.1 直接指定多个提交的哈希值

这是最直观的方法，你只需在 git cherry-pick 命令后依次列出你想要应用的提交的哈希值。

语法:

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

其中 <hash1>, <hash2>, <hash3> 等是你要挑选的提交的完整或缩写 SHA-1 哈希值。

工作原理:

Git 会按照你在命令行中指定的顺序，依次将这些提交应用到当前分支上。如果一个提交应用成功，Git 会自动生成一个新提交，然后继续尝试应用下一个提交。如果某个提交在应用过程中发生冲突，Git 会暂停 cherry-pick 过程，需要你手动解决冲突，然后使用 git cherry-pick --continue 继续，或使用 git cherry-pick --skip 跳过，或使用 git cherry-pick --abort 中止整个过程。

示例:

假设你在 feature/new-feature 分支上有三个提交，你想将它们应用到 main 分支上：

* c2b3f4a (HEAD -> feature/new-feature) Commit 3: Add logging
* a1b2c3d Commit 2: Implement core logic
* e5f6g7h Commit 1: Initial setup for feature
* ... (main branch commits)

切换到 main 分支：

bash
git checkout main

然后挑选这三个提交：

bash
git cherry-pick e5f6g7h a1b2c3d c2b3f4a

注意顺序: 在这个例子中，提交 e5f6g7h 是最旧的，c2b3f4a 是最新的。按照提交的逻辑顺序（通常是创建顺序，从旧到新）进行 cherry-pick 可以最大程度地减少冲突，因为这样应用修改的顺序与原提交的创建顺序一致。Git 会先尝试应用 e5f6g7h 的修改，成功后创建新提交，然后尝试应用 a1b2c3d 的修改，依此类推。

如果你颠倒顺序（例如先 c2b3f4a），Git 依然会尝试应用，但冲突的可能性会大大增加，因为新的提交依赖于旧提交引入的代码或结构。因此，推荐按照提交的原始时间顺序（从旧到新）来指定多个哈希值。

2.2 使用提交范围 (Commit Ranges)

当需要挑选一系列连续的提交时，手动输入每个提交的哈希值会非常繁琐。Git 提供了提交范围的表示方法，可以方便地指定一系列提交。

2.2.1 双点语法 ..

最常用的提交范围语法是 start..end。它的含义是：包含 end 提交，但不包含 start 提交。也就是 end 的所有祖先提交中，排除掉 start 的所有祖先提交。

当用于 cherry-pick 时，git cherry-pick <start-commit>..<end-commit> 会挑选从 <start-commit> 的下一个提交开始，直到 <end-commit>（包括 <end-commit>）之间的所有提交。

语法:

bash
git cherry-pick <start-commit>..<end-commit>

<start-commit> 和 <end-commit> 可以是提交的哈希值、分支名、标签名或其他任何指向提交的引用。

工作原理:

Git 会确定 <start-commit> 和 <end-commit> 之间的所有提交，然后按照这些提交在原始历史中的时间顺序（从旧到新）依次应用它们。这比手动指定哈希值更加智能，因为它自动处理了应用的顺序问题。

示例:

继续上面的例子，假设你想从 feature/new-feature 分支挑选从 e5f6g7h（不含）到 c2b3f4a（含）的所有提交到 main 分支。

提交历史（简化）：

... -- o -- e5f6g7h -- a1b2c3d -- c2b3f4a (feature/new-feature)
\
X -- Y -- Z (main)

切换到 main 分支：

bash
git checkout main

使用范围选择：

bash
git cherry-pick e5f6g7h..c2b3f4a

或者使用分支名作为范围的结束：

bash
git cherry-pick e5f6g7h..feature/new-feature

甚至可以使用分支名来表示整个范围，如果范围的起始点是该分支的某个祖先提交：

假设 e5f6g7h 是 feature/new-feature 分支从 main 分支分出来时的第一个提交。main 分支当时的 HEAD 是 o。那么 e5f6g7h 是 o 的子提交。

... -- o (main)
\
e5f6g7h -- a1b2c3d -- c2b3f4a (feature/new-feature)

如果你想挑选 feature/new-feature 上相对于 main 分支（或 o 提交）的 所有 提交，你可以使用 main..feature/new-feature。

bash
git cherry-pick main..feature/new-feature

这个命令会挑选 feature/new-feature 分支上有，但 main 分支没有的所有提交。在上面的例子中，就是 e5f6g7h, a1b2c3d, c2b3f4a 这三个提交。Git 会按时间顺序应用它们。

2.2.2 独点语法 ^

另一种表示范围的方式是使用 ^ 符号。<commit>^ 表示 <commit> 的父提交。

语法:

bash
git cherry-pick <start-commit>^..<end-commit>

这个语法表示从 <start-commit> 本身开始，直到 <end-commit>（包含）之间的所有提交。它与 start-commit..end-commit 的区别在于是否包含 start-commit 本身。

示例:

如果你想包含 e5f6g7h 提交本身，可以使用：

bash
git cherry-pick e5f6g7h^..c2b3f4a

假设提交历史如下：

... -- o -- e5f6g7h -- a1b2c3d -- c2b3f4a (feature/new-feature)

  • e5f6g7h..c2b3f4a 挑选：a1b2c3d, c2b3f4a
  • e5f6g7h^..c2b3f4a 挑选：e5f6g7h, a1b2c3d, c2b3f4a

这两种语法在挑选连续提交时非常有用，特别是当你知道范围的起始点和结束点时。使用范围语法比手动输入多个哈希值更不容易出错，并且能确保提交按正确的顺序应用。

2.3 使用 git log 和 xargs (高级用法)

有时，你可能需要挑选不连续的、但满足特定条件的多个提交（例如，所有包含特定关键词的提交信息，或者由某个作者在某个时间段内提交的）。在这种情况下，可以结合使用 git log 来查找提交哈希，然后通过管道和 xargs 将这些哈希传递给 git cherry-pick。

示例:

假设你想挑选 feature/new-feature 分支上所有提交信息中包含 “bugfix” 的提交，并将它们应用到 main 分支。

  1. 查找符合条件的提交哈希（通常按时间顺序排列）：

    bash
    git log feature/new-feature --grep="bugfix" --pretty=format:"%H" --reverse
    * feature/new-feature: 在这个分支的历史中查找。
    * --grep="bugfix": 过滤提交信息包含 “bugfix” 的提交。
    * --pretty=format:"%H": 只输出提交的完整哈希值。
    * --reverse: 将输出结果按时间顺序从旧到新排列（这对于 cherry-pick 很重要）。

    假设这个命令输出：
    hash_A
    hash_B
    hash_C

  2. 切换到目标分支：

    bash
    git checkout main

  3. 将哈希值传递给 git cherry-pick：

    bash
    git log feature/new-feature --grep="bugfix" --pretty=format:"%H" --reverse | xargs git cherry-pick

xargs 命令会将管道（|）前面命令的输出作为参数传递给后面的命令。在这里，它会将每个哈希值作为 git cherry-pick 的一个参数。因为我们在 git log 中使用了 --reverse，所以 cherry-pick 会按照从旧到新的顺序接收和应用这些提交。

这种方法非常灵活，可以结合 git log 的各种过滤选项（--author, --since, --until, --grep, --pickaxe 等）来精确地选择需要应用的提交序列。

第三部分：处理冲突 (Handling Conflicts)

当 cherry-pick 一个或多个提交时，冲突是可能发生的。冲突的原因是 Git 尝试应用提交的修改时，发现目标分支上的相关代码已经被修改过了，Git 无法自动决定保留哪种修改。

当使用 git cherry-pick 并且发生冲突时，Git 会在第一个冲突的提交处暂停。命令行会提示你存在冲突，并且 git status 会显示哪些文件发生了冲突。

3.1 解决冲突的步骤

  1. Git 暂停: 当出现冲突时，Git 会停止 cherry-pick 过程，并给出提示。
  2. 查看状态: 运行 git status 查看冲突的文件。
  3. 手动解决: 打开冲突的文件，查找 Git 标记的冲突部分（通常是 <<<<<<<, =======, >>>>>>>）。手动编辑文件，保留你想要的修改，删除标记行。
  4. 暂存文件: 解决完所有冲突后，使用 git add <conflicted-file> 将修改后的文件添加到暂存区。
  5. 继续或中止:
    • 继续: 如果你想继续应用剩余的提交，运行 git cherry-pick --continue。Git 会在你解决完当前冲突并暂存文件后，自动创建一个新的提交（包含当前提交的修改），然后继续尝试应用队列中的下一个提交。
    • 跳过: 如果你决定放弃当前冲突的提交，不想将其应用到当前分支，运行 git cherry-pick --skip。Git 会丢弃当前正在处理的提交，然后继续尝试应用队列中的下一个提交。
    • 中止: 如果你想完全取消本次 cherry-pick 操作，恢复到 cherry-pick 开始之前的状态，运行 git cherry-pick --abort。Git 会撤销所有已成功应用的提交（如果已经应用了多个中的一部分），并将 HEAD 指针恢复到 cherry-pick 开始时的位置。

3.2 解决多个提交冲突的注意事项

当同时 cherry-pick 多个提交时，冲突处理流程是串行的：每遇到一个提交的冲突，Git 就暂停，直到你解决并选择 continue 或 skip，它才会处理下一个提交。这意味着你不需要一次性解决所有提交的冲突，而是逐个处理。

重要提示: 尽量按照提交的原始顺序（从旧到新）进行 cherry-pick，这样后续提交基于之前提交的修改，发生冲突的可能性相对较小。如果顺序颠倒，后面的提交可能会依赖于尚未应用的早期修改，从而更容易导致冲突。

第四部分：Git cherry-pick 的高级选项

git cherry-pick 提供了几个有用的选项，可以在应用提交时提供更多控制。

  • -n, --no-commit: 执行 cherry-pick 操作，但不自动生成提交。Git 会将选定提交的修改应用到工作目录和暂存区，但保持在“未提交”状态。这在你想将多个挑选的提交合并成一个大提交时非常有用。应用所有需要的提交后，你可以手动执行 git commit 来创建一个包含所有这些修改的新提交。

    示例:
    “`bash
    git cherry-pick –no-commit hash1 hash2 hash3

    解决任何潜在冲突

    git add .
    git commit -m “Applied multiple bug fixes from feature branch”
    “`

  • -x, --allow-empty: 在新生成的提交信息中添加一行记录原提交哈希和主题行的信息，格式通常是 (cherry picked from commit ...)。这是一个非常推荐使用的选项，因为它有助于追踪哪些提交是 cherry-pick 来的，方便日后查阅历史。--allow-empty 允许 Git 在挑选的提交没有实际修改内容时（例如，原提交只是改了一个.gitignore文件但目标分支上这个文件已经被删除了，或者原提交是合并提交）依然创建一个空提交。

    示例:
    bash
    git cherry-pick -x e5f6g7h^..c2b3f4a
    新生成的提交信息会类似这样：
    “`
    Commit message of c2b3f4a

    (cherry picked from commit c2b3f4a)
    “`

  • --signoff: 在提交信息中添加一个 Signed-off-by 行，表明你对该修改负责。这在一些项目（如 Linux 内核）中是要求的。

    示例:
    bash
    git cherry-pick --signoff a1b2c3d

  • -s <strategy>, --strategy=<strategy>: 使用指定的合并策略来应用修改。虽然 cherry-pick 主要针对单个提交，但其底层使用了合并机制。了解不同的合并策略（如 recursive, resolve, ours, theirs 等）可能在解决特定类型的冲突时有用，但这通常是高级用法。

  • -m <parent-number>, --mainline <parent-number>: 这个选项主要用于 cherry-pick 合并提交（merge commits）。合并提交有两个或多个父提交。你需要指定以哪个父提交为主线来计算差异。例如，git cherry-pick -m 1 <merge-commit> 会以第一个父提交为主线，应用合并提交相对于第一个父提交的修改。这通常用于撤销合并提交的反向操作（git revert -m 1 <merge-commit>），在 cherry-pick 中不常用。

第五部分：使用 cherry-pick 的场景与最佳实践

5.1 典型场景

  • Bug 修复回溯: 这是 cherry-pick 最常见的用例。在 main 或 develop 分支上修复了 bug，然后将修复的提交 cherry-pick 到较旧的稳定分支上。
  • 选择性特性引入: 一个大型特性分支包含了多个子功能。在某个节点，你决定只将其中一个子功能的几个提交引入到主分支或另一个特性分支。
  • 代码审查后的修改: 代码审查过程中提出了一些小的修改，这些修改被提交到临时的审查分支上。审查通过后，你可以将这些修改的提交 cherry-pick 到原分支上。
  • 从废弃分支挽救工作: 一个分支因为策略改变或方向错误而被废弃，但其中包含了少量有价值的提交，可以 cherry-pick 到新分支上。

5.2 最佳实践与注意事项

  • 谨慎使用: cherry-pick 会创建新的提交，导致同样的修改在仓库历史中出现多次（不同的哈希）。这会使历史看起来不那么清晰，并且在将来进行分支合并时，Git 可能无法识别这些是重复的修改，从而再次引发冲突。因此，cherry-pick 应该作为合并或 rebase 的补充工具，而不是首选。只有当你确实只需要特定提交时才使用它。
  • 按照原始顺序: 当 cherry-pick 多个提交时，务必按照它们在原始分支中的时间顺序（从旧到新）来指定或使用范围。这能最大程度地减少冲突。
  • 使用 -x 选项: 始终考虑使用 -x 选项。它能在新提交信息中记录原始提交的哈希，这对于追踪修改来源非常有帮助，尤其是在复杂的项目历史中。
  • 解决冲突要仔细: 冲突解决是 cherry-pick 过程中最容易出错的部分。仔细检查冲突标记，确保你理解了原始修改和目标分支修改之间的差异，并正确地合并它们。
  • 与团队沟通: 如果你的工作流程依赖于清晰、线性的历史，频繁使用 cherry-pick 可能会干扰这一点。在共享仓库中大量使用 cherry-pick 之前，最好与团队成员沟通，确保大家理解和接受这种做法带来的历史变化。
  • 考虑替代方案: 在使用 cherry-pick 之前，先思考 merge 或 rebase 是否更适合你的需求。如果你的目标是整合整个分支的功能或保持线性历史，它们可能是更好的选择。

第六部分：cherry-pick 的潜在问题

虽然 cherry-pick 是一个强大的工具，但它的使用并非没有代价。最主要的潜在问题是：

  • 重复的修改历史: 正如前面提到的，cherry-pick 会为每个选定的原提交创建一个新的提交。这意味着同样的修改内容会以不同的提交哈希存在于仓库的不同位置。这使得通过 git log 追踪某个修改的来源变得更复杂，也可能在后续合并包含这些原提交和 cherry-picked 提交的分支时导致 Git 混淆，再次出现冲突或需要手动解决重复应用的问题。
  • 可能破坏原子性: 原始分支上的多个提交可能是一个原子性功能的组成部分，它们之间有依赖关系。如果只 cherry-pick 其中一部分提交，可能会导致目标分支上的代码处于一个不完整或无法工作的中间状态。
  • 冲突解决的复杂性: 如果挑选的提交之间的依赖性很强，或者与目标分支的差异很大，解决冲突可能会非常耗时且复杂。

第七部分：总结

git cherry-pick 是 Git 工具箱中一把锋利的瑞士军刀，它赋予你精确选择和应用特定提交的能力，而无需引入整个分支的历史。这对于 bug 回溯、选择性功能引入等场景至关重要。

本文详细介绍了 cherry-pick 的核心概念，并着重讲解了同时应用多个提交的不同方法：

  1. 直接列出多个提交哈希（推荐按时间顺序）。
  2. 使用 start..end 提交范围（自动按时间顺序应用）。
  3. 使用 start^..end 提交范围（包含起始提交）。
  4. 结合 git log 和 xargs 来挑选满足特定条件的提交。

同时，我们探讨了冲突的解决流程、--no-commit 和 -x 等重要选项，以及 cherry-pick 的典型应用场景。

然而，我们也要清醒地认识到 cherry-pick 的局限性和潜在问题，尤其是它会创建重复修改的历史，这可能会使项目历史变得复杂。因此，在使用 cherry-pick 之前，务必权衡其带来的便利性与潜在的历史混乱，并考虑 merge 或 rebase 是否是更合适的方案。

熟练掌握 git cherry-pick，特别是同时处理多个提交的技巧，将显著提升你在复杂 Git 工作流中的效率和精确性。记住，这是一个强大的工具，合理、负责任地使用它，才能最大化其价值。

发表评论

您的邮箱地址不会被公开。 必填项已用 * 标注

滚动至顶部