Git 解决一些后的冲突

Question

我有问题

我很难将长期存在的分支的拉取请求合并到主分支中，因为即使我尝试解决它们也无法解决冲突。

所以我看到 GitHub 告诉我有冲突，所以我无法将我的功能分支my-feature-branch合并到主分支中。 我从my-freature-branch创建了一个新的分支solve-conflicts-branch -branch 。 我将 master 合并到 solve-conflicts-branch 中。 现在，我在solve-conflicts-branch中遇到了冲突，我使用“他们的”来解决这些冲突，使用“我的”来解决一些冲突。 我提交更改并创建 PR 以将这些更改合并到my-feature-branch 。 所以 PR 通过了，我合并了。

我希望看到的是第一个 PR 得到更新并且冲突得到解决，但事实并非如此。 我在solve-conflicts-branch中解决的相同冲突仍然存在。

Answer 1

当你压扁时，你在欺骗 git（以一种对你来说非常讨厌的方式）认为合并没有发生。 让我解释一下，这样您就可以在压扁时看到问题所在。 假设你有这个：

*   Something on a branch (some-branch)
| * first tip of master (master)
|/
* second commit
* first commit

假设您运行第一次合并。 当您合并时，git 将粗略地考虑两个分支自其最后一个共同祖先以来引入的差异....因此，如果您将master合并到some-branch以从其他开发人员那里获取最新版本，git 将不得不考虑这一点树，对吧？

*   Something on a branch (some-branch)
| * first tip of master (master)
|/
* second commit

当你完成合并时，你可能会得到这样的东西（假设我们解决了合并中的一些冲突）：

* Merging changes from master (some-branch)
|\
* | Something on a branch
| * first tip of master (master)
|/
* second commit
* first commit

这一切对我来说都很美……现在，时间流逝了一点，现在我们有了这个：

* A new commit in feature branch (some-branch)
| * A new commit in master (master)
* | Merging changes from master
|\|
* | Something on a branch
| * first tip of master
|/
* second commit
* first commit

如果你这次尝试合并，git 将不得不寻找最新的共同祖先并查看每个分支上发生了什么变化，因此，它必须考虑这一点（查看最后一个共同祖先）：

* A new commit in feature branch (some-branch)
| * A new commit in master (master)
* | Merging changes from master
 \|
  * First tip of master

现在，如果在每个分支的最后一次提交中没有弄乱在第一次合并中已经发生冲突的代码，您将不会收到来自 git 的涉及该代码段的投诉，因为它不会涉及来自的更改过去first tip of master的两个分支中的任何一个。

现在，考虑一下如果压缩，第一次合并后第一次合并会是什么样子：

* Merging changes from master (some-branch)
*   Something on a branch
| * first tip of master (master)
|/
* second commit
* first commit

现在，让我们在每个分支的顶端添加 2 个提交，就像我们之前所做的那样：

* a new commit in feature branch (some-branch)
* Merging changes from master
*   Something on a branch
| * A new commit in master (master)
| * first tip of master
|/
* second commit
* first commit

如果你现在尝试合并，git 必须考虑合并什么树？ 它将不得不再次考虑自second commit以来发生的变化，就像上次和一样，鉴于之前存在冲突，这两个分支很可能仍然会在相同的代码部分发生冲突，因为对于 git，你有不同的自second commit以来来自 2 个分支的更改。 所以，是的，你之前解决了冲突，但考虑到你并没有真正合并，git 在你这次尝试合并时并不知道。

我希望这有助于解释为什么会这样。