所以，我的项目中有一个维护分支和一个主分支。如果我在维护分支中提交并希望将其合并到主分支，这很容易：
git checkout master; git merge maintenance
但是如果我想反其道而行之，即将对 master 所做的提交应用回我的维护分支，我该怎么做？这被认为是采摘樱桃吗？如果我再次向前合并维护分支会导致问题或冲突吗？
【问题讨论】：
git-deps 来检测和可视化这些依赖项。如果您访问主页，您将看到两个 YouTube 视频：第一个是对该工具的一般介绍，第二个演示如何使用它来避免在挑选时发生冲突。
标签： git
这正是git-cherry-pick 的用例
git checkout maintenance
git cherry-pick <commit from master>
【讨论】：
使用“git cherry-pick”（在其他回复中建议）的替代解决方案是为修复创建一个单独的 [topic] 分支关闭维护分支，并先将此分支合并到维护分支，然后合并到主分支（主干）。
这个工作流程（有点）在 Resolving conflicts/dependencies between topic branches early 博客文章中由 git 维护者 Junio C Hamano 描述。
Cherry-picking 会导致重复提交，这可能会导致合并或变基时出现问题。基于主题分支的工作流程只保留一份修复副本。
【讨论】：
3.6 合并回GitHub repository of CPython 中的分支main）。
对于无法使用 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。
【讨论】：
是的，它被认为是挑剔的，不，一般它不应该带来问题。如果在反向移植时提交不能干净地应用，那么在挑选回来时可能会遇到完全相同的冲突。
【讨论】：
作为一般规则，我使用合并将更改“向上”移动到树（从维护到主），并使用 rebase 将它们“向下”移动到树（从主到维护）。这样才能保持 master 分支中的提交顺序。
Rebase 实质上是将当前分支上的所有更改回滚到 fork（或最后一个 rebase），复制较新的更改，然后重新应用您的更改。
如果您不想从主服务器获得所有更改，那么您可能需要精心挑选您想要的。
【讨论】：