如何在 git 中向后移植提交？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1440181/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How do I backport a commit in git?
提问by Christian Oudard
So, I have a maintenance branch and a master branch in my project. If I make a commit in the maintenance branch and want to merge it forward to the master branch, that's easy:
所以，我的项目中有一个维护分支和一个主分支。如果我在维护分支中进行提交并希望将其合并到主分支，那很容易：
git checkout master; git merge maintenance
But if I want to go the other way around, i.e. apply a commit made to master back to my maintenance branch, how do I do that? Is this considered cherry-picking? Will it cause problems or conflicts if I merge the maintenance branch forward again?
但是，如果我想反过来，即将对 master 的提交应用回我的维护分支，我该怎么做？这被认为是采摘樱桃吗？再向前合并维护分支会不会出现问题或者冲突？
采纳答案by mwalling
This is exactly the use case for git-cherry-pick
这正是git-cherry-pick的用例
git checkout maintenance
git cherry-pick <commit from master>
回答by Jakub Nar?bski
Alternate solution to using "git cherry-pick" (as recommended in other responses) would be to create a separate [topic] branch for the fixoff maintenance branch, and merge this branch first into maintenance branch, then into master branch (trunk).
使用“ git cherry-pick”（如其他回复中推荐的）的替代解决方案是为维护分支的修复创建一个单独的 [topic]分支，并首先将此分支合并到维护分支，然后合并到主分支（主干）。
This workflow is (somewhat) described in Resolving conflicts/dependencies between topic branches earlyblog post by Junio C Hamano, git maintainer.
git 维护者 Junio C Hamano在早期博客文章中解决了主题分支之间的冲突/依赖关系（有些）描述了此工作流程。
Cherry-picking results in duplicated commit, which down the line may cause problems when merging or rebasing. Topic-branch based workflow keeps only one copy of the fix.
Cherry-picking 导致重复提交，这在合并或变基时可能会导致问题。基于主题分支的工作流仅保留一份修复副本。
回答by Adam Spiers
As others have already stated, cherry-picking is probably the best option. I just wanted to add that conflicts during cherry-picking can often be resolved by examining the "dependencies" of the commit you are cherry-picking, and that I have built a tool called git-depsto detect and visualize those dependencies. If you visit the home page you will see two YouTube videos: the first gives a general introduction to the tool, and the second demonstrates how it can be used to avoid conflicts when cherry-picking.
正如其他人已经指出的那样，采摘樱桃可能是最好的选择。我只是想补充一点，挑选过程中的冲突通常可以通过检查您挑选的提交的“依赖关系”来解决，并且我已经构建了一个名为git-deps检测和可视化这些依赖关系的工具。如果您访问主页，您将看到两个 YouTube 视频：第一个对该工具进行了总体介绍，第二个演示了如何在挑选时使用它来避免冲突。
回答by boombatower
For complex commits that cannot be applied using git cherry-pick you can try
对于无法使用 git cherry-pick 应用的复杂提交，您可以尝试
git checkout -b merge-branch master
git rebase --onto=`git merge-base master maintenance` HEAD~1 && git rebase master
Explained: http://blog.boombatower.com/automatically-backport-commits-using-git.
解释：http: //blog.boombatower.com/automatically-backport-commits-using-git。
回答by Michael Krelin - hacker
Yes, it is considered cherry-picking and no, generallyit should not introduce problems. If commit doesn't apply cleanly when backporting you may face exactly same conflict when cherry-picking it back.
是的，它被认为是挑剔的，不，通常它不会带来问题。如果在向后移植时提交没有完全适用，您在挑选回来时可能会面临完全相同的冲突。
回答by Brenton Alker
As a general rule, I use merge to move changes "up" the tree (from maintenance to master) and rebase to move them "down" the tree (from master to maintenance). This is so the order of commits in the master branch is maintained.
作为一般规则，我使用合并将更改“向上”移动到树（从维护到主）并使用变基将它们“向下”移动到树（从主到维护）。这是为了维护主分支中的提交顺序。
Rebase essentially rolls back all your changes on the current branch to the fork (or last rebase), copies over newer changes and then re-applies your changes.
Rebase 本质上是将当前分支上的所有更改回滚到 fork（或最后一个 rebase），复制较新的更改，然后重新应用您的更改。
If you don't want to get allchanges from the master, then you will probably need to cherry pick the ones you want.
如果您不想从 master获得所有更改，那么您可能需要精心挑选您想要的更改。
