我有 3 个 git 分支 - 开发、质量检查和大师。开发人员使用 Develop 分支进行所有开发。一旦开发人员完成任务并将代码提交到 Develop 分支，该提交将合并到 QA 分支进行测试。测试完成后，将代码合并到主分支，然后部署。我们刚刚在 QA 分支中发现了一个必须在部署之前修复的错误。已在 Develop 分支中进行了修复，但还包括我们目前不想部署的更改。那么，我们如何修复 QA 中的错误呢？我的第一个想法是直接对 QA 分支进行更改以解决问题，然后将这些更改合并回 Develop 分支。但我不确定可能会给开发分支带来什么问题（即丢失代码等......）
【问题讨论】：
标签： git github version-control git-branch
使用 Git，您可以使用 cherry-pick 将一些提交从一个分支移动到另一个分支。
这里提到了文档： https://git-scm.com/docs/git-cherry-pick
但是cherry-pick 应该是一个例外而不是规则，主要是因为它可以解决更多问题。
理想情况下，我会建议您重新考虑您的分支策略。您可以使用从基线派生的功能分支。即，如果在 QA 上发现错误，则从 QA 创建一个分支，修复它，然后将其合并到 QA，然后合并到 dev。以下链接可以帮助您入门：http://nvie.com/posts/a-successful-git-branching-model/
我的第一个想法是直接对 QA 分支进行更改以解决问题，然后将这些更改合并回 Develop 分支
这个想法是正确的。我们在一个非常活跃的项目中跟踪它没有很多问题，主要是如果您的更改是原子的，git 足够智能，可以为您自动合并它。如果发生冲突，大多数 IDE 现在都支持良好的 3 路合并。
【讨论】：
如果 Develop 分支中有一个提交修复了问题，您可以检查 QA 分支并运行
git cherry-pick <commit-id>
cherry-pick 操作采用任意提交所做的更改集，并将它们作为新提交应用到当前分支。如果您稍后将 Develop 合并到 QA 中，git 足够聪明，可以避免重复应用这些更改。
当然，请注意，挑选提交不一定会干净利落。准备好在出现冲突时手动合并冲突，并在应用精心挑选的提交后对 QA 分支代码进行广泛测试！
如果解决问题的提交还包含您不想应用于 QA 的其他更改，那么您需要在挑选之前拆分该提交。这个网站上还有其他关于如何做到这一点的问题。
【讨论】：