Gitcherry-pick：将提交复制到另一个分支并修复冲突

Gitcherry-pick 将提交引入的更改应用到当前分支，通常会记录新的提交。切换到应接收修复的分支，检查源提交，然后运行 ​​git cherry-pick <commit>。源分支保持不变。如果补丁冲突，请解决文件并继续，或中止操作。

想象一下在 feature/checkout 上修复了一个支付错误，而发布分支只需要该修复。合并整个功能可能会带来未完成的工作。本指南展示了如何使用 Git 以及我们为 macOS、Windows 和 Linux 构建的客户端 GitTree 复制修复程序。可视化路由的额外价值是在应用更改之前检查目标分支和源差异。

Cherry-pick vs merge vs rebase：选择操作

Cherry-pick 对于向后移植或提交到错误分支的小修复非常有用。对于重复合并两个应该共享所有工作的分支来说，它是一个糟糕的替代品：复制的更改可能会变得难以跟踪。有关整个分支工作流程，请参阅交互式变基 和提交图指南。

如何挑选一个提交到另一个分支

从干净的工作树开始。提交或隐藏未完成的编辑； stash 指南 涵盖了暂停和恢复工作流程。如果修复是远程的，则获取，然后检查源历史记录。下面的分支名称和哈希是示例：将它们替换为现有的目标分支、源分支和实际的修复哈希。

git status
git fetch origin
git log --oneline origin/feature/checkout
git show abc1234
git switch release/2.x
git status
git cherry-pick -x abc1234
git show --stat HEAD
git status

-x 将源提交引用添加到消息中以进行干净的挑选，这有助于跟踪公共向后移植。获取更新远程跟踪参考；它不会自动更新您签出的发布分支。确认目标是您的团队期望的修订版。在推送之前检查新的提交并运行发布分支的测试。

所选提交通常具有不同的哈希值，因为其父提交元数据和其他提交元数据不同。它的原始版本保留在源分支上。复制修复不会将其从错误的分支中删除；决定如何清理该分支是一个单独的历史决策，特别是如果其他人已经使用它的话。

下载 GitTree 以使用可视化图表和冲突编辑器来遵循此工作流程。 Cherry-pick 包含在免费计划中，包括私人存储库。登录当前的官方应用程序，打开现有存储库并使用您已有的相同 Git 历史记录。

精挑细选多个提交和范围

git cherry-pick abc1234 def5678
# A linear range, including the first commit:
git cherry-pick "abc1234^..def5678"

这些是替代示例。显式列表按提供的顺序选择提交；将先决条件更改放在首位。范围遵循修订集规则，而不是选择您在图表中碰巧看到的行。 A..B 排除 A；当 A 有父级时，A^..B 包含 A 作为简​​单线性序列。对于初学者向后移植，更喜欢明确的、经过审查的列表，而不是交叉合并的范围。

解决选择冲突并继续

当 Git 无法应用补丁时，它会暂停。运行 git status 以识别操作和冲突路径，然后编辑预期结果。使用冲突解决指南 获取标记示例和 GitTree 三向编辑器。语法上干净的解决方案仍然需要测试：目标可能使用不同的 API。

git status
git diff --name-only --diff-filter=U
# Resolve the file, then check and stage it:
git diff --check
git add -- src/payment.ts
git diff --cached
git cherry-pick --continue

一个序列可以暂停多次，每次有问题的提交都会暂停一次。如果 Git 说该选择为空，请检查更改是否已存在或您的解决方案将其删除。仅当您故意想要省略该提交时才使用 git cherry-pick --skip；这不是一般性的冲突修复。

Git 择优选择中止、退出、跳过

合并提交、缺少依赖项并撤消选择

合并提交需要一个主线父级，因为它表示相对于多个父级的更改。在考虑 git cherry-pick -m 1 <merge> 之前先用 git show --no-patch --pretty=raw <merge> 检查它。父项 1 并不普遍正确。 GitTree 要求您选择父级；根据你想要比较的历史来选择，而不是根据习惯。选择原始的普通修复提交通常更容易推理。

如果复制的修复程序构建不正确，请检查其先决条件：帮助程序、架构更改或配置可能存在于较早的提交中。成功的 Git 操作仅证明补丁已应用。测试接收分支。要撤消对共享历史记录的已完成选择，请恢复在目标分支上创建的新提交，而不是原始源哈希。对于未发布的工作，请在移动分支历史记录之前查看撤消 Git 错误 中的重置和恢复选择。