我对Git有疑问。我们一直在推动我们的功能，掌握最近的提交是c2的地方。在c1和c2之间几乎有10个提交。今天，由于一些问题，我们必须创建一个分支从C1犯主人，我有一个像下面做：误解git cherry pick
git branch bugfix c1
而在这个bug修正分支我已经为犯C2的部分做了修改，必须是当下。所以我打算做以下事情：
git checkout bugfix
git cherry-pick -x c2
安全吗？我的意思是，从git的角度来看，从c1 + 1到c2-1的提交更改可能来自bugfix分支，因为我们不希望主从c1和c2之间的任何更改来到bugfix分支。
这是安全的，因为樱桃挑选只需要确认c2承诺的变化。但是，如评论所述，如果c2更改取决于之前在c2和c1之间的更改，则可能会导致问题。此外，如果c2更改与您在c1中的状态不匹配（即，因为它需要先前的更改，这些更改是c1和c2之间的提交的一部分），则选择将会失败。
通常，创建一个提交是安全的。通常情况下，您只会通过将有问题的提交推送到外部（构建）服务器来造成伤害。在你的情况下，它可能有助于检查樱桃采摘后的变化。
从根本上说，是什么git cherry-pick所做的是每个“樱花”（每次提交被拾起）转换成变更集一集的差异列表，然后尝试在变更应用到当前（或HEAD）提交并从结果中做出新的承诺。
通过在该提交与其父提交之间运行git diff来获取任何一个特定提交的差异。这个差异很容易获得：git show <hash>可以用于任何非合并提交。 （樱桃挑选合并需要指定哪个父级，因此有点复杂。）因此，您可以使用git show来查看git cherry-pick将选择哪些更改。
注意，如果git show显示更改的文件不HEAD存在，或者对不以文件中存在代码的区域，它在HEAD存在，Git会无法完成摘樱桃在其自己的。在这种情况下，Git会将cherry-pick操作视为对合并合并请求的更改，使用完整的3路合并，合并基础是提交的父项，并且两个分支提示是HEAD（--ours）和提交樱桃采摘（--theirs）。这会在工作树中留下合并冲突，而正在进行的合并存储在索引中;您可以像解决任何其他合并冲突一样解决此问题，然后运行git cherry-pick --continue完成操作，或者git cherry-pick --abort停止并返回到开始前的状态。
或者与-n，只索引和工作树。
如果'c2'中的代码依赖'c1'和'c2'之间的任何变化，那么它将无法正常工作或者可能无法编译，但樱桃只会从* 1 *承诺。 – crashmstr
我认为正确性取决于c2是什么样的变化。如果它取决于之前的10次提交，那么您的樱桃采摘将无法正常工作（不包括所有必要的更改）。 – vahancho
我会考虑正确性。但是从git的角度告诉我，这些提交之间会有什么变化来修正bugfix吗？ – Joy