Git cherry pick的问题：以前提交的更改也被应用

在我的项目中，我在几个月前发布了一个版本。在发布之后，我对主分支做了很多更改

如果我在上一个版本中遇到一些bug，我会在主分支上修复它们，然后将它们挑选到我在上一个版本中创建的分支上。然后，我可以提供一个新版本，其中只包含bug修复，而不发布主分支上未完成的工作

当我试图为发布分支挑选某个bug修复时，我遇到了一个合并冲突

据我所知，cherry picking某个提交会向目标分支引入一个新的提交，并在cherry picking提交中进行更改

但是，当我试图修复合并冲突时，似乎git已经在主分支上应用了更改，而这些更改不是由提交到我的发布分支所引入的。提交只在冲突文件中引入了几行。但是，当我试图解决冲突时，我看到文件中还引入了其他几行，它们是通过不同的提交添加到主分支的

有人能解释一下为什么在我的发布分支中引入了除了cherry picked commit之外的来自提交的更改吗

我看到文件中还引入了其他几行，它们是通过不同的提交添加到主分支的

确保在提交时没有不需要的更改

$ git show <commit-sha>

---

备选方案：如果您希望从目标提交到发布分支进行少量文件更改，此解决方案将非常有效

提交只在冲突文件中引入了几行

$git签出
$git结帐更改提交的版本
$git add。
$git commit-m“修复错误”
$git推送原点磁头

据我所知，cherry picking某个提交会向目标分支引入一个新的提交，并在cherry picking提交中进行更改

这是正确的。但是，这些更改可能不会完全适用，在这种情况下：

。。。我遇到了合并冲突

此时，

git cherry pick

正在进行三方合并，这需要选择一个合并基

我记得，哪些文件或提交被用作合并基础部分取决于您的Git版本。如果运行

Git cherry pick

，则现代Git使用cherry pick提交，但至少有一个表单（使用

Git am

或

Git apply

和

--3way

选项，而

Git rebase

仍然可以）可以使用

git diff

输出的

index

行选择文件的早期版本。归根结底，这可能不太重要

在任何情况下，合并实际上都将从基本提交运行到两个“提示”中的每一个（樱桃选择的提交和您尝试应用樱桃选择的头部提交）。为了直观地看到发生了什么，您应该像往常一样从绘制提交图开始。（我没有你的存储库，所以我会画一个不同的图，希望它足够近。但你应该画自己的，或者让Git做，或者使用

gitk

或类似的东西。）

---

o--@我完全按照你说的做了。我选择的提交本身没有任何不需要的更改，但是由该提交更改的文件确实有一些不需要的更改（由主分支上以前的其他提交引入）。所以，我不明白为什么在发布分支上引入这些更改。另外，您的替代方案不适合我，因为从master branch获取整个文件对我来说不起作用，因为上面提到了不希望的更改。”（由master branch上的其他提交介绍）“它不符合git的性质！而您只能选择提交的更改替代解决方案不接受主控的更改<代码>git签出

=提交的文件更改！=主文件的头文件更改。它应该与cherry pick to

文件

的结果相同。实际上，我也很惊讶地看到这种行为，因为我已经做了很多次cherry pick，但从未见过类似的事情。我尝试了您的替代解决方案，它所做的是在给定的提交散列中签出文件。它不仅仅签出给定提交引入的更改，而是签出给定提交散列中的完整文件。由于主分支上以前的其他提交对文件进行了不希望的更改，这不是我想要的。我也看到了这一点，这是在Windows上使用git多年后的第一次。尝试了适用于Windows 64位2.13.0.Windows.1的最新git和旧版本2.10.x

git cherry pick

没有给我一个合并冲突，但是修改后的文件有它不应该有的更改，我使用补丁和

git apply

得到了相同的更改。我创建了一个repo，这可能有助于澄清：我看到了相同类型的冲突。你的解释很有教育意义，所以谢谢你。然而，它并没有提供解决方案。为应用于@的P-C构建的git修补程序失败。因此，接下来的问题是：我们如何让git只应用P-C更改而不应用o-I-P更改？@Suncat2000:无法保证任何更改都可以自动化。但是，如果您

git show

commit

C

，那么git将P-vs-C表示为一个diff，然后使用

git apply

将该diff应用于提交

@

，在某些情况下，这可能比

git cherry pick C

更好。您可以选择使用

--reject

或

--3way

来应用修补程序，如果修补程序一开始没有干净地应用，尽管

--3way

使其更像樱桃采摘：您很可能会遇到相同的冲突（不包括对重命名文件的任何识别）。如果您使用这些方法中的任何一种，检查和/或测试非常重要

$ git checkout <release-branch>
$ git cherry-pick <commit-sha>

$ git checkout --theirs -- .
Or,
$ git checkout --ours -- .

$ git status                     # see the changes
$ git add .
$ git commit -m 'Fix conflicts'
$ git push origin HEAD

$ git checkout <release-branch>
$ git checkout <commit-sha> <file> .      # change the <file> to commit's version

$ git add .
$ git commit -m 'Fix the bug'
$ git push origin HEAD

          o--@         <-- branch (HEAD)
         /
...--o--o
         \
          I--P--C--o   <-- otherbranch