git cherry-pick冲突包括不需要的代码

Question

我的场景：我有分支B，它是从分支A创建的。我在分支B中进行了一些提交，我希望能够选择分支C（类似于A）。我不想将B合并到C中，因为我不希望A中的某些东西进入那里。

我的问题：当我做B提交的樱桃选择时，我会在分支C中有一些冲突。这不是解决问题的问题，除了在分支B＆＃中39;冲突中的变化块，来自A的一些东西就在那里。

那么，为什么我在C中看到A中的任何内容时都没有直接添加到B中，而且我在挑选提交的内容？我猜这与冲突有关，因为A的其他任何东西都没有过来，只是冲突线周围的东西。

在我的截图中，红色括号中的所有内容最初都在A中，但在C中并不存在。我唯一想要的就是最后一行。这也发生在另一个文件中。

Answer 1

如果要挑选的材料存在冲突，Git会做同样的事情：

• 查看合并基础版本;
• 查看HEAD版本;和
• 查看即将合并的版本。

如果您将merge.conflictStyle设置为diff3（我这样做），您将在冲突区域中看到所有三个版本，而不仅仅是这三个版本中的两个。我发现这有助于了解Git所看到的内容。

  

那么，为什么我在C中看到的任何内容都没有直接添加到B中，而我正在挑选提交内容？我猜这与冲突有关，因为A的其他任何东西都没有过来，只是冲突线周围的东西。

这是正确的：问题是Git必须找到 merge base 提交才能决定“你改变了什么” - 这是将合并基数与当前或{{1}进行比较的结果提交 - 和“他们改变了什么”，这是将合并基础与“他们的”提交进行比较的结果。

你在所有这些开头提到了“分支”：

  

我有分支B，它是从分支A创建的。我在分支B中进行了一些提交，我希望将其挑选到分支C（类似于A）。

但事实上，Git根本不关心分支。 Git只关心提交 -branches主要与Git有关，因为分支名称允许Git查找单独的提交。它有助于抽出实际的提交（如果你愿意，还可以包含让我们和Git找到这些提交的分支标签）：

HEAD

我已经从整个布料中创建了这个图形，它可能看起来很像你的图形，但它现在允许我们说明奇怪的方式 H--I--J <-- branch-B / ...--E--F--G <-- branch-A \ K--L <-- branch-C 识别Git中的合并基础提交。

如果我们在{branch} C上“git cherry-pick可能会说，我们的git status提交是提交HEAD，即分支C的提示。如果我们然后运行L，Git会进行这些分配：

• merge-base = commit H
• HEAD或git cherry-pick <hash-of-commit-I> =提交L
• --ours =提交我

Git然后将（如--theirs）提交git diff反对提交H以查看他们做了什么 - 这是我们想要选择的樱桃 - 但也< / em> diff commit I针对提交H，以查看我们已更改并查找冲突。

如果 冲突，Git向我们展示了双方对合并基础版本L所做的事情，而没有实际向我们展示合并基础版本H。这可能包括我们不想要的内容：我们通过从H向H“向后”“删除”的内容。如果Git也出现了合并基础版本L，我们可以看到我们“删除”了我们不想要的东西，所以我们应该在解决合并冲突时“保持删除”。