所以，我的项目中有一个维护分支和一个主分支。如果我在维护分支中进行提交并希望将其合并到主分支，那很容易：
git checkout master; git merge maintenance
但是，如果我想反过来，即将一个提交给master的提交应用到我的维护分支，我该怎么做？这被认为是挑选樱桃？如果我再次向前合并维护分支会导致问题或冲突吗？
答案 0 :(得分：33)
git checkout maintenance
git cherry-pick <commit from master>
答案 1 :(得分：15)
使用“ git cherry-pick ”（如其他回复中所建议的）的替代解决方案是为修复创建单独的[主题]分支维护分支，并将此分支首先合并到维护分支，然后合并到主分支（主干）。
这个工作流程（在某种程度上）由Junio C Hamano，git maintainer的Resolving conflicts/dependencies between topic branches early博客文章中描述。
挑选樱桃会导致重复提交，这可能会导致合并或重新定位时出现问题。基于主题分支的工作流只保留修复的一个副本。
答案 2 :(得分：0)
是的，它被认为是挑选而不是，通常它不应该引入问题。如果提交在向后移植时不能完全应用，那么当你将它挑回来时，你可能会遇到完全相同的冲突。
答案 3 :(得分：0)
作为一般规则，我使用merge来将更改“向上”移动到树（从维护到主控），并使用rebase将它们“向下”移动到树（从主服务器到维护服务器）。这样就可以保持主分支中的提交顺序。
Rebase基本上将当前分支上的所有更改回滚到fork（或最后一个rebase），复制更新的更改，然后重新应用更改。
如果您不想从主人那里获得所有更改，那么您可能需要选择您想要的更改。
答案 4 :(得分：0)
对于使用git cherry-pick无法应用的复杂提交，您可以尝试
git checkout -b merge-branch master
git rebase --onto=`git merge-base master maintenance` HEAD~1 && git rebase master
解释：http://blog.boombatower.com/automatically-backport-commits-using-git。
答案 5 :(得分：0)
正如其他人已经说过的那样，采摘樱桃可能是最好的选择。我只是想补充一点，在采摘过程中的冲突通常可以通过检查＆＃34;依赖关系来解决。您正在挑选的提交，以及我已经构建a tool called git-deps来检测和可视化这些依赖项。如果您访问主页，您将看到两个YouTube视频：第一个视频提供了该工具的一般介绍，第二个视频演示了如何在采摘时避免冲突。