我对Git有疑问。我们一直在推动我们的功能，以掌握最近的提交是c2。在c1和c2之间有近10次提交。今天由于一些问题，我们不得不从master中的c1 commit创建一个分支，我做了如下操作：
git branch bugfix c1
在这个bugfix分支中，我作为提交c2的一部分所做的更改必须存在。所以我要做以下事情：
git checkout bugfix
git cherry-pick -x c2
安全吗？我的意思是从git的角度来看，从c1 + 1到c2-1的提交中的任何变化都可能来到bugfix分支，因为我们不希望来自master的c1和c2之间的任何变化都来到bugfix分支。 / p>
答案 0 :(得分：0)
这是安全的，因为cherry-pick只接受标识为c2的提交的更改。但是，如评论中所述，如果c2更改取决于c2和c1之间的先前更改，则可能会出现问题。此外，如果c2更改与c1中的状态不匹配，则cherry-pick将失败（即，因为它需要先前的更改是c1之间提交的一部分， c2）。
通常，只创建一个提交是安全的。通常，您只会通过将有问题的提交推送到外部（构建）服务器而造成伤害。在您的情况下，选择樱桃后检查更改可能会有所帮助。
答案 1 :(得分：0)
从根本上说，git cherry-pick做的是将每个“cherry”（每个提交被提取）转换为变更集 - 一组差异 - 然后尝试将该变更集应用于当前（或{{1}提交 1 并从结果中进行新的提交。
通过在该提交与其父提交之间运行HEAD来获取任何一个特定提交的差异。这个差异很容易获得：git diff为任何非合并提交做到了。 （挑选合并需要指定哪个父项，因此更复杂。）因此，您可以使用git show <hash>查看git show将要选择的更改。
请注意，如果git cherry-pick显示git show中不存在的文件或HEAD中存在的文件中不存在的代码区域的更改，Git将无法完成樱桃选择。在这种情况下，Git会将cherry-pick操作视为合并更改的请求，使用完全3向合并，合并基础是提交的父级，两个分支提示为HEAD（HEAD），提交被挑选出来（--ours）。这将使合并冲突留在工作树中，正在进行的合并存储在索引中;您可以像解决任何其他合并冲突一样解决此问题，然后运行--theirs以完成操作，或git cherry-pick --continue停止并返回到开始之前的状态。
1 或者，git cherry-pick --abort，仅限于索引和工作树。