GitLab声称存在合并冲突，但实际上并不存在。

Question

我从主分支创建了一个分支。在该分支上进行了四次提交。在第三次提交后，我创建了一个合并请求。在前三次提交期间，Gitlab从未抱怨过合并冲突。在第四次提交时，它突然抱怨了合并冲突。主分支没有发生任何更改。

$ git branch
  master
* mylocalbranch

$ git rebase master
  Current branch mylocalbranch is up to date.
    
$ git merge master
  Already up to date.

$ git mergetool
  No files need merging

我的合并请求已经完全获得批准。我可以编写访问存储库。合并按钮变灰了。我不确定如何解决Gitlab抱怨的冲突。也不确定如何将我的代码合并到主分支。

- ontherocks

---

如果你的本地master分支没有从上游拉取，那么git rebase master命令将不会告诉你任何信息。 - hobbs

Answer 1

你当前所在的分支是mylocalbranch，想对其进行基于主分支(master)的rebase操作。但实际上你的分支已经在主分支(master)之前，由于主分支(master)没有新提交，因此不需要进行rebase操作。接下来你试图将主分支(master)合并到你的本地分支，但你已经拥有了最新更改。

你必须先在本地pull主分支(master)并检查是否有更新。拉取主分支(master)后，你需要进行rebase操作，然后就可以看到GitLab提出的冲突。解决冲突后再次将你的本地分支推送(push)到远程。

- mnestorov

---

你是在建议执行 git checkout master 然后再执行 git pull --rebase origin master 吗？ - ontherocks

这是获取远程 master 分支更改的一种方法，是的。另外，您可以进行的检查是查看 GitLab UI 并查看 GitLab 上的 master 分支是否有一个或多个提交，而您在本地却没有。这样，您就可以证明需要从远程拉取 master 更改。 - mnestorov

自从我在远程创建分支或者在本地克隆分支以来，主分支没有任何更改。 - ontherocks

你执行了 pull 操作后的结果是什么？ - mnestorov

个人而言，我更喜欢先运行 git fetch origin，然后再运行 git rebase origin/master。没有必要运行 git checkout master、git pull 和 git checkout mybranch。实际上，如果你愿意的话，可以直接删除 master 分支；因为当 origin/master 存在时（并且会自动更新），你不需要它。通常情况下我不会删除 master 分支，但在开发过程中也不会经常引用它。 - torek

Answer 2

主分支没有发生任何更改。

不，有更改。

请注意，Git不会自动同步到远程。远程已经有更改了。但是在你执行fetch命令之前，你的本地机器上是看不到这些更改的。

- matt

Answer 3

在GitLab中出现合并冲突的情况下，实际上并没有冲突，我在本地合并了该分支，并推送了它。之后，GitLab中的MR被标记为已合并。

$ git checkout master
$ git merge --no-ff 10-mybranch
$ git push

我遵循了GitLab的提交信息结构，假设该分支解决了问题编号为10的问题，并且MR的编号是8。

Merge branch '10-mybranch' into 'master'

My extraordinary code is stuffed with bugs.

Closes #10
    
See merge request !8

- dpeng