所以，我的项目中有一个维护分支和一个主分支。如果我在维护分支上进行了提交并希望将其向前合并到主分支，那很容易：
git checkout master; git merge maintenance
如果我想反过来，即将应用于主分支的提交应用于我的维护分支，该怎么做？这被认为是挑拣吗？如果我再次合并维护分支，会引起问题或冲突吗？
5个回答
47
这正是使用git-cherry-pick的情况。
git checkout maintenance
git cherry-pick <commit from master>
- mwalling
2
1当在两个公共分支之间进行挑选时，使用 -x 开关很有用，它会在没有冲突的情况下将 "(cherry picked from commit …)" 行附加到挑选中。https://git-scm.com/docs/git-cherry-pick#git-cherry-pick--x - kszatan
24
和其他回答中建议使用 "git cherry-pick" 不同的备选方案是为修复问题创建一个独立的 [topic] 分支，从维护分支上创建，并将该分支先合并到维护分支，然后再合并到主分支(trunk)。
这个工作流程在 git 维护者 Junio C Hamano 的博客文章“早期解决主题分支之间的冲突/依赖关系”中有些描述。
使用cherry-pick会导致重复提交，在后续合并或变基时可能会导致问题。基于主题分支的工作流程只保留修复的一个副本。
- Jakub Narębski
2
我喜欢链接的帖子如何解释添加可能冲突的多个提交。在将它们合并到主分支或维护分支之前，将功能A与Bug修复B合并在一起。这样，您可以确保解决A和B之间的冲突，以便如果您首先拉取A或B，则可以轻松地拉入A + B的合并，并知道它已经为您预先合并。请参见[链接文档中的图3]（http://gitster.livejournal.com/27297.html）。 - 700 Software
有趣！您能否添加ASCII艺术风格的提交历史以澄清您的答案？此外，为什么主题分支的合并顺序很重要（首先合并到维护分支，然后再合并到主分支）？为什么主题分支合并到主分支不会产生冲突，因为主题分支是从维护分支分支出来的，而维护分支根据定义是长期存在的，即永远不应该合并回主分支（对我来说，这就像将分支
3.6合并回CPython的GitHub存储库中的main分支）。 - Géry Ogam1
对于无法使用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。
- boombatower
0
是的，这被认为是挑选最好的部分，但通常情况下不应该引入问题。如果在回溯时提交无法干净地应用，则在挑选它时可能会面临完全相同的冲突。
- Michael Krelin - hacker
0
作为一般规则，我使用合并（merge）将更改“向上”移动到树中（从维护到主分支），并使用变基（rebase）将它们“向下”移动到树中（从主分支到维护）。这样可以保持主分支中提交的顺序。
变基本质上是将当前分支上所有更改回滚到分叉点（或上次变基），复制更新的更改，然后重新应用您的更改。
如果您不想获取主分支中的所有更改，则可能需要挑选您想要的更改。
变基本质上是将当前分支上所有更改回滚到分叉点（或上次变基），复制更新的更改，然后重新应用您的更改。
如果您不想获取主分支中的所有更改，则可能需要挑选您想要的更改。
- Brenton Alker
1
3我也对rebase感到困惑。但是假设存在一个专门用于“不”包含所有当前更改的“维护”分支，那么这不是您想要的。对我来说，最好的方法是重新设置开发分支，但从主分支（或任何上游开发分支）摘取一个修复错误，并将其返回到维护分支。 - Alex Stoddard
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接
git-deps的工具来检测和可视化这些依赖项。如果您访问主页，您将看到两个YouTube视频：第一个是介绍该工具的概述，第二个演示了在挑选时如何使用它来避免冲突。 - Adam Spiers