我有以下存储库布局：
主分支（生产）集成工作
我想实现的是从工作分支中挑选一系列提交，并将其合并到集成分支中。我对git很陌生，我无法弄清楚如何在不破坏存储库的情况下准确地做到这一点（在一次操作中挑选提交范围，而不是合并）。对此有什么建议或想法吗？谢谢
当前回答
如果你只有两次提交，并且想挑选，你可以
git cherry-pick <commit> -n
然后将它们转换为新的提交。
-n不会自动创建提交，而只是阶段性地进行更改，因此您可以继续对提交中的文件进行cherry pick或更改。
其他回答
如果你只有两次提交，并且想挑选，你可以
git cherry-pick <commit> -n
然后将它们转换为新的提交。
-n不会自动创建提交，而只是阶段性地进行更改，因此您可以继续对提交中的文件进行cherry pick或更改。
合并有时会很困难，只需创建一个补丁并手动应用更改即可。
创建从start_commit到end_commit的修补程序文件。git diff<start_commit><end_commit>>patch.diff签出分支并手动应用修补程序中的更改。
当涉及到一系列的提交时，挑选樱桃是不实际的。
正如Keith Kim在下面提到的，Git 1.7.2+引入了樱桃选择一系列提交的能力（但您仍需要意识到樱桃选择对未来合并的影响）
gitcherry-pick“学会了选择一系列提交（例如“cherry-pick A..B”和“cherry pick-stdin”），“git-restore”也是如此；然而，这些并不支持“rebase[-i]”所具有的更好的测序控制。
达米安评论并警告我们：
在“cherry-pick A..B”形式中，A应该早于B。如果顺序错误，命令将自动失败。
如果要选择范围B到D（包括B），则该范围为B^。。D（而不是B..D）。请参阅“Git从以前的提交范围创建分支？”作为示例。
正如Jubobs在评论中提到的：
这假设B不是根提交；否则会出现“未知修订”错误。
注意：从Git 2.9.x/2.10（2016年第3季度）开始，您可以直接在孤立分支（空头）上选择一系列提交：请参阅“如何在Git中使现有分支成为孤立分支”。
原答覆（2010年1月）
如Charles Bailey在这里所描述的那样，在集成分支的顶部回放给定范围的提交会更好。（此外，请在gitrebase手册页中查找“这是如何将基于一个分支的主题分支移植到另一个分支”，以查看gitrebase的一个实际示例——到）
如果您当前的分支机构是集成的：
# Checkout a new temporary branch at the current location
git checkout -b tmp
# Move the integration branch to the head of the new patchset
git branch -f integration last_SHA-1_of_working_branch_range
# Rebase the patchset onto tmp, the old location of integration
git rebase --onto tmp first_SHA-1_of_working_branch_range~1 integration
这将在以下时间段重播所有内容：
在first_SHAR_of_working_branch_range的父级之后（因此为~1）：要重播的第一次提交直到“集成”（它指向您要从工作分支重播的最后一次提交）
到“tmp”（指向集成之前指向的位置）
如果在重播其中一个提交时发生冲突：
要么解决它，然后运行“git-rebase--continue”。或跳过此修补程序，改为运行“git-rebase--skip”或使用“gitrebase--abort”取消所有操作（并将集成分支放回tmp分支）
在重新基址之后，集成将返回到集成分支的最后一次提交（即“tmp”分支+所有重放的提交）
对于cherry-pick或rebase-ton，不要忘记它会对后续合并产生影响，如本文所述。
这里讨论的是一个纯粹的“樱桃采摘”解决方案，它将涉及以下内容：
如果您想使用补丁方法，那么可以选择“git format patch | git am”和“git cherry”。目前，gitcherry-pick只接受一次提交，但如果您想选择范围B到D，则应该是B^。。D在git lingo中，所以
git rev-list --reverse --topo-order B^..D | while read rev
do
git cherry-pick $rev || break
done
但无论如何，当您需要“重放”一系列提交时，“重放”这个词应该会促使您使用Git的“rebase”特性。
从git v1.7.2起，cherry-pick可以接受一系列提交：
git cherry-pick学会了选择一系列提交（例如cherry-pick a..B和cherry--pick-stdin），git revert也学会了选择；然而，这些并不支持rebase[-i]所具有的更好的测序控制。
正如Gabe Moothart所指出的，cherry pick A..B不会得到commit A（你需要A~1..B），如果有任何冲突，git不会像rebase那样自动继续（至少在1.7.3.1）。
假设您有2个分支，
“branchA”：包括要复制的提交（从“commitA”到“commitB”
“branchB”：要从“branchA”转移提交的分支
1)
git checkout <branchA>
2） 获取“commitA”和“commitB”的ID
3)
git checkout <branchB>
4)
git cherry-pick <commitA>^..<commitB>
5） 如果您有冲突，请解决并键入
git cherry-pick --continue
继续樱桃采摘过程。
