在协作软件开发环境中使用分支是必不可少的，可以隔离功能、bug修复或实验。然而，有时您需要从一个分支中获取特定更改并将其应用到另一个分支，而无需合并整个分支。这就是git cherry-pick发挥作用的地方。
本教程的目标是全面介绍如何有效使用git cherry-pick。您将学习该命令的语法，了解如何处理冲突，探讨最佳实践和常见陷阱以避免。让我们开始吧！
Git Cherry-Pick是什么？
git cherry-pick命令是一个基本的Git命令，让开发人员可以精细控制他们的源代码。
与其他Git操作不同，如合并或变基，这些操作涉及整个分支，cherry-pick允许您从一个分支中获取特定提交并将其应用到另一个分支。这提供了精确性，特别是在您只需要集成特定更改而不是分支中的所有修改的情况下。
git cherry-pick命令通过复制所选提交的内容并在目标分支中创建新提交来工作，从而保持提交历史的完整性。
何时使用git cherry-pick
使用git cherry-pick的情况包括：
- 回溯错误修复：您已经解决了开发分支中的一个错误，并需要在稳定或发布分支中进行相同的修复。挑选（cherry-picking）使您能够移动错误修复，而不会带入不相关的更改。
- 应用热修复：当生产环境需要进行关键修复，而开发分支仍在不断发展时，挑选（cherry-picking）允许您提取并将修复应用到生产分支。
- 功能隔离进行测试：在测试期间可能只需要测试与某个功能相关的特定提交。通过挑选（cherry-picking）所需的提交，保持测试分支的清洁和高效，而不是合并整个功能分支。
- 修正错误的提交：如果一个提交被错误地推送到了错误的分支，您可以使用 cherry-pick 将该提交复制到适当的分支，而不会破坏项目历史。
- 在多个分支之间重用更改：在需要在多个分支中应用相同更新的情况下，cherry-pick 允许您在不同分支中复制更改，而不必重新工作或引入分支复杂性。
Git Cherry-Pick的语法
了解 git cherry-pick 的语法对于有效使用这个命令非常关键。这不仅仅是选择提交，而是精确地应用它们以实现期望的结果。
单独挑选一个提交的基本语法是：
git cherry-pick <commit-hash>
git cherry-pick：启动操作的命令。<commit-hash>：您想要挑选的提交的唯一标识符（SHA-1哈希）。您可以通过运行git log来查找此哈希值。
执行上述命令时，Git会将指定提交的更改应用到当前分支，创建一个具有相同更改但不同哈希值的新提交。
重要提示：该命令仅传输提交本身，而不包括原始分支的上下文或父级历史记录。
对Git和GitHub还不熟悉吗？从这个初学者友好的GitHub和Git教程开始入门。如何使用Git Cherry-Pick：逐步示例
现在您已经了解了git cherry-pick的基本语法，是时候看看这个命令的实际操作了。
本节提供了一些实际示例，让您了解常见的基本和更复杂的情况下cherry-picking是如何有用的。每个示例都说明了如何将一个或多个提交的更改应用到另一个分支。
示例1：Cherry-picking单个提交
假设您在一个功能分支上进行了修复，并希望将其应用到主分支，而无需合并整个功能分支。
- 首先，通过运行以下命令找到您想要选择的提交的哈希值：
git log
- 找到提交的哈希值。
- 切换到主分支：
git checkout main
- 运行 cherry-pick 命令（假设哈希值为
abc1234）：
git cherry-pick abc1234
当您运行此命令时，Git 将把由 abc1234 标识的提交中的更改应用到您当前的分支（在这种情况下是 main）。Git 在主分支上创建一个新提交，该提交包含与原始提交相同的更改，但具有新的提交哈希。
示例 2：选择多个提交
在某些情况下，您可能需要将一个分支中的几个不同提交应用到另一个分支。假设您在功能分支中有三个独立的提交，需要将它们引入主分支。
- 使用
git log查找您想要选择的每个提交的哈希：
git log
- 切换到主分支：
git checkout main
- 运行 cherry-pick 命令，列出提交：
git cherry-pick abc1234 def5678 ghi7890
示例 3：选择一系列提交
假设您在功能分支上做了一系列提交，并希望一次性将它们应用到主分支，而不必逐个指定每个提交。您该怎么做？
- 使用
git log确定您想要 cherry-pick 的起始和结束提交（例如，从abc1234到ghi7890）。 - 切换到主分支：
git checkout main
- 使用提交范围运行 cherry-pick 命令：
git cherry-pick abc1234...ghi7890
示例 4：从远程分支选择提交
有时候，远程分支中存在一个关键修复，你想将其应用到本地分支，而不是合并整个分支。以下是操作步骤：
- 从远程仓库获取最新的更改
git fetch origin
- 列出远程分支中的提交，以找到你需要的哈希值：
git log origin/feature_branch --oneline
- 假设你需要的提交哈希是
abc1234。 - 切换到你的本地主分支：
git checkout main
- 从远程分支中选择性应用该提交：
git cherry-pick abc1234
这让你可以从远程分支应用一个提交，而无需合并整个分支。
需要检出远程分支吗？按照这个逐步指南进行 Git 检出远程分支。
示例 5：拣选一个提交并修改它
如果你拣选了一个提交，但需要在提交之前做一些小修改，可以使用 Git 的交互模式。方法如下：
- 切换到目标分支：
git checkout main
- 拣选提交，但在提交之前停止：
git cherry-pick -n abc1234
-n（或--no-commit）标志会应用更改但不创建提交。
- 根据需要修改文件。
- 手动暂存并提交更改：
git add . git commit -m "Modified cherry-picked commit from feature_branch"
当你需要在最终化之前调整一个挑选的提交时，这很有用。
在Git Cherry-Pick中处理冲突
在分支之间挑选提交时，冲突是不可避免的，尤其是当代码库发生显著分歧时。
虽然 cherry-pick 旨在干净地应用更改，但它并不总是能够自动解决差异。在这些情况下，必须手动解决冲突。理解冲突是如何产生的以及如何处理它们对于完成 cherry-pick 操作至关重要。
冲突如何发生
冲突通常发生在从 cherry-picked 提交中提取的更改与目标分支中已经存在的更改重叠或相互矛盾的情况下。例如：
- 两个分支中相同的行被修改： 如果源分支和目标分支中相同的代码行被修改，Git 将不知道应用哪个版本。
- 在一个分支中删除文件但在另一个分支中修改:如果一个文件在一个分支中被删除，但在被挑选的提交中被修改，Git 将不知道是保留还是应用这些更改。
- 不相关的更改但是同一个文件:即使更改看起来不相关，如果它们发生在同一个文件中，Git 可能会将其标记为潜在冲突。
当发生冲突时，Git 将停止 cherry-pick 操作，使您的工作目录处于冲突状态，必须在继续之前解决冲突。
解决冲突
一旦出现冲突，Git 将会提供有冲突文件的指示，您需要手动解决这些差异。以下是解决冲突的方法：
1. 检查有冲突的文件： 运行以下命令以查看哪些文件发生了冲突：
git status
该命令将显示有冲突的文件列表。
2. 解决冲突： 您可以手动编辑有冲突的文件以解决问题。删除冲突标记（<<<<<<<, =======, >>>>>>>），并确定保留哪些更改或如何将它们合并。
3. 使用Git Mergetool（可选）： 如果手动解决冲突太麻烦，您可以使用合并工具来帮助可视化和解决冲突：
git mergetool
根据您的配置，上述工具将打开一个可视化合并工具，这样更容易审查和解决冲突。
4. 将冲突标记为已解决： 解决冲突后，使用以下命令将文件标记为已解决：
git add <conflicted-file>
5. 完成挑选樱桃：一旦所有冲突都解决并文件已暂存，运行以下命令完成挑选樱桃：
git cherry-pick --continue
许多现代IDE和工具，如Visual Studio Code和GitHub，提供内置的合并冲突解决功能。GitHub的Web界面允许您直接在拉取请求中解决冲突，使得在共享存储库上进行协作而无需切换到本地环境更加容易。
在冲突后跳过提交
有时，解决冲突可能过于复杂，或者您可能意识到该提交实际上并不必要。在这种情况下，您可以完全跳过该提交。
1. 中止当前的 cherry-pick 过程：如果冲突太复杂，且你不想应用该提交，可以通过运行以下命令跳过它：
git cherry-pick --skip
这将放弃冲突的提交并继续下一个（如果你正在 cherry-pick 多个提交）。
2. 中止整个 cherry-pick：如果你想完全中止 cherry-pick 操作，可以运行：
git cherry-pick --abort
此命令将恢复你的工作目录到你开始 cherry-pick 之前的状态。
想要清理提交历史记录吗？通过这个Git squash 教程学习如何将多个提交合并为一个。
使用 Git Cherry-Pick 的最佳实践
滥用 cherry-pick 可能导致项目版本控制中的复杂历史和混乱。为避免这些问题，遵循最佳实践确保您有效地使用 cherry-pick，而不会给代码库引入不必要的复杂性。
保持小而具体
当处理小而具体的提交时，例如修复错误或进行轻微功能增强时，使用 Cherry-picking 是最有效的。
避免挑选大型、复杂的提交，这些提交捆绑了多个更改，可能会引入冲突，并且使得代码库更难管理。提交越有针对性，就越容易应用而不会产生意外的副作用。
记录您的挑选
为了保持清晰的历史记录，在进行挑选时始终提供适当的上下文。可以通过详细的提交消息或文档中的注释来实现。
主要要点是必须解释为什么需要进行挑选。这在跨长期分支或协作环境中进行挑选时尤为重要，因为它有助于未来的贡献者理解为什么选择性地应用了更改。
审查提交历史
在进行选择性合并之前，请查看源分支和目标分支的提交历史。这一步有助于识别您即将选择合并的提交是否依赖于其他更改。缺失的依赖可能导致功能不完整或出现错误，因此请确保选择合并不会引入不成熟的功能或更新。
避免过度使用选择性合并
虽然选择性合并方便用于应用特定的更改，但过度使用可能导致历史记录碎片化，出现跨分支的重复提交。这可能使得追踪某些更改的来源或理解更广泛的开发背景变得困难。
在选择性合并之前，总是评估合并或变基是否是更合适的策略。务必谨慎和有目的地使用cherry-pick，以避免使提交历史杂乱。
在Git中遇到不必要的文件？学习如何有效使用.gitignore，请查看this Git忽略教程。
使用Git Cherry-Pick时的常见问题排除
当使用cherry-pick时遇到问题，需要对Git的基本机制有清晰的了解。在本节中，我将介绍您在执行cherry-pick时可能遇到的一些常见问题以及如何解决。
Cherry-pick一个不存在的提交
有时，您可能尝试cherry-pick一个当前分支无法访问或已经合并的提交。这通常会导致错误消息，指出找不到或无法应用该提交。
1. 未找到提交记录: 当您尝试挑选的提交哈希在当前代码库或分支上不存在时会出现此问题。请通过在包含该提交的分支上使用 git log 来确认您正在引用正确的提交。解决方法:
- 再次检查提交哈希以确保其正确性。
- 验证提交是否存在于您可以访问的分支上。
- 如果提交存在于远程分支中，请确保使用
git fetch拉取了该分支。
2. 提交已应用：如果提交已经被合并或挑选到目标分支，Git 将阻止您重复它。这个保护措施保持了历史的整洁，避免了冗余的更改。解决方案：
- 使用
git log检查提交是否已经在目标分支中。 - 如果需要，跳过
cherry-pick操作，因为更改已经应用。
在变基或合并后进行挑选
在变基或合并后进行挑选可能会引入复杂性，因为分支的历史发生了变化。变基重写提交历史，而合并则合并分支，这两者都可能影响挑选的适用性。
1. 由于重新定位提交而引起的冲突:重新定位后，提交历史将被重写，如果您尝试挑选在重新定位过程中已被更改的提交，可能会出现问题。您可能会遇到冲突，因为cherry-pick尝试应用与重写历史不符的更改。解决方法:
- 使用
git log仔细审查重新定位后的提交历史，以确保您要挑选的提交尚未被修改。 - 像在标准
cherry-pick过程中一样解决冲突，使用git status和手动编辑。
2. 在合并后出现重复提交：合并分支可能会导致一种情况，即您想要挑选的提交已经包含在合并历史中。再次挑选它可能会导致重复提交，这会混乱您的历史记录，使跟踪更改变得困难。解决方案：
- 在挑选之前，检查两个分支上的提交历史，确认提交是否已经合并。
- 如果目标分支中已经包含相同的提交，请避免再次挑选它。
需要在Git中撤消更改吗？了解何时使用git reset和git revert： Git reset 和 revert 教程。
Conclusion
git cherry-pick 是一种强大的方法，可以将一个分支中的特定提交应用到另一个分支，而无需合并整个分支。无论是移动错误修复、功能更新，还是仅选择性地应用更改，它都有助于保持您的 Git 历史记录清晰而专注。
在本指南中，我介绍了如何单独和批量选择提交、解决冲突，以及遵循最佳实践以避免常见陷阱。通过明智地使用 cherry-pick，您可以改善工作流程，同时保持您的代码库井然有序。
如果您想深化您的 Git 技能，可以查看 Git 基础知识，这是一个很好的起点。您还可以探索 GitHub 概念介绍，或通过 GitHub 基础技能路径采取结构化的方法。
现在您知道如何像专业人士一样进行 cherry-pick，快去在您的下一个项目中尝试吧！