为什么 GitLab 自上次合并以来没有提交到目标分支时会说存在冲突？
Why does GitLab say there are conflicts when there have not been commits to the target branch since the last merge?
我们的项目使用 GitLab.com。我们正在将代码从我们的 QA 分支 (qa) 合并到我们的发布分支 (master) 中。自大约一个月前的最后一次发布以来，没有对 master 分支的提交。
对于几个项目，自动合并在 GitLab 的 UI 中失败，我必须通过命令行手动完成 通过 GitLab 解决冲突UI。我不明白这是怎么发生的，因为 master 上没有任何变化与之冲突。
qa --●--●--●--●--●--
\ \
master ----●-----------●--
当我合并冲突时，我最终只是从 qa 分支 (git merge -X theirs) 中获取所有更改。它也不是所有文件（谢天谢地！），只是 5 个文件的 5-10 次更改，50 个文件中的 300 次更改。
但我就是不明白是什么引发了这些冲突。
注意：当合并到 master 时，我会压缩来自 qa 的所有提交。现在我认为这可能是问题的一部分。仍然不确定如何。
我想我找到了问题所在。在一个简单的依赖项目中发生过，所以很好地作为一个例子。
在 UI 中根本无法工作的合并 （必须使用 CLI 在本地解决的合并）已合并，但没有出现问题描述。我已经更新了问题以反映这一点。
问题是 GitLab 正在按所需方向在合并前几秒从目标分支 到源分支 进行自动合并提交。我验证了 'conflicts' 的项目都发生了这些错误的合并。也是没有手动合并的项目。
$ git log --abbrev-commit --graph qa master
* commit 92xxx (tag: v1.3.1, tag: v1.3.0, origin/master, origin/HEAD, master)
|\ Merge: 83xxx 7fxxx
| | Author: Nick
| | Date: Fri Sep 7 00:52:37 2018 +0000
| |
| | Merge branch 'qa' into 'master'
| |
| | v1.3
| |
| | See merge request translations!17
| |
| * commit 7fxxx
|/ Author: Nick
| Date: Fri Sep 7 00:52:37 2018 +0000
|
| v1.3
|
| * commit c14xxx (HEAD -> qa, origin/qa)
| |\ Merge: 76xxx 83xxx
| |/ Author: Nick
|/| Date: Fri Sep 7 00:52:29 2018 +0000
| |
| | Merge branch 'master' into 'qa'
| |
| | # Conflicts:
| | # langs/en-US.json
| |
* | commit 83xxx (tag: v1.2.1, tag: v1.2.0)
|\ \ Merge: 08xxx 73xxx
| | | Author: Nick
| | | Date: Fri Aug 3 14:09:04 2018 +0000
| | |
| | | Merge branch 'qa' into 'master'
| | |
| | | Merge for v1.1.2
| | |
| | | See merge request translations!13
| | |
m qa
master 是左边那一行。 83xxx 上一版本的合并。 master 自上次发布以来没有提交，除了这个莫名其妙的错误合并。
所以这解释了冲突。这些冲突在 GitLab UI 中打开合并请求后立即出现，所以我猜测合并请求的创建是导致错误合并提交的原因。也许使用 'squash commits' 复选框开始发挥作用（它可用于 select 创建合并请求，也可用于已打开的合并请求的合并操作）。
仍然对GitLab为什么要这样做一头雾水，也许是一个bug。下次我创建具有这些奇怪冲突的合并请求时，我会让它们保持打开状态，以查看它是否确实在创建过程中创建了错误的合并请求。
2018 年 12 月更新
再次发布时间。我注意了。仍然不能 100% 确定发生了什么。开始对翻译项目的合并请求，自上次从 qa.
合并以来，对 master 的提交为零
冲突。看着他们。没有任何意义。在另一个选项卡中刷新回购时没有注意到任何提交。单击 UI 中的 'resolve conflicts'，完成冲突解决后，创建了来自 master->qa 的提交。这只是 Gitlab 实现的合并方式。您通过将 master 拉入 QA 来解决冲突，然后合并回来。它在 UI 的冲突解决页面
中确实是这么说的
或者什么的。快把我逼疯了，但没有时间在发布日磨磨蹭蹭。
我们的项目使用 GitLab.com。我们正在将代码从我们的 QA 分支 (qa) 合并到我们的发布分支 (master) 中。自大约一个月前的最后一次发布以来，没有对 master 分支的提交。
对于几个项目，自动合并在 GitLab 的 UI 中失败，我必须通过命令行手动完成 通过 GitLab 解决冲突UI。我不明白这是怎么发生的，因为 master 上没有任何变化与之冲突。
qa --●--●--●--●--●--
\ \
master ----●-----------●--
当我合并冲突时，我最终只是从 qa 分支 (git merge -X theirs) 中获取所有更改。它也不是所有文件（谢天谢地！），只是 5 个文件的 5-10 次更改，50 个文件中的 300 次更改。
但我就是不明白是什么引发了这些冲突。
注意：当合并到 master 时，我会压缩来自 qa 的所有提交。现在我认为这可能是问题的一部分。仍然不确定如何。
我想我找到了问题所在。在一个简单的依赖项目中发生过，所以很好地作为一个例子。
在 UI 中根本无法工作的合并 （必须使用 CLI 在本地解决的合并）已合并，但没有出现问题描述。我已经更新了问题以反映这一点。
问题是 GitLab 正在按所需方向在合并前几秒从目标分支 到源分支 进行自动合并提交。我验证了 'conflicts' 的项目都发生了这些错误的合并。也是没有手动合并的项目。
$ git log --abbrev-commit --graph qa master
* commit 92xxx (tag: v1.3.1, tag: v1.3.0, origin/master, origin/HEAD, master)
|\ Merge: 83xxx 7fxxx
| | Author: Nick
| | Date: Fri Sep 7 00:52:37 2018 +0000
| |
| | Merge branch 'qa' into 'master'
| |
| | v1.3
| |
| | See merge request translations!17
| |
| * commit 7fxxx
|/ Author: Nick
| Date: Fri Sep 7 00:52:37 2018 +0000
|
| v1.3
|
| * commit c14xxx (HEAD -> qa, origin/qa)
| |\ Merge: 76xxx 83xxx
| |/ Author: Nick
|/| Date: Fri Sep 7 00:52:29 2018 +0000
| |
| | Merge branch 'master' into 'qa'
| |
| | # Conflicts:
| | # langs/en-US.json
| |
* | commit 83xxx (tag: v1.2.1, tag: v1.2.0)
|\ \ Merge: 08xxx 73xxx
| | | Author: Nick
| | | Date: Fri Aug 3 14:09:04 2018 +0000
| | |
| | | Merge branch 'qa' into 'master'
| | |
| | | Merge for v1.1.2
| | |
| | | See merge request translations!13
| | |
m qa
master 是左边那一行。 83xxx 上一版本的合并。 master 自上次发布以来没有提交，除了这个莫名其妙的错误合并。
所以这解释了冲突。这些冲突在 GitLab UI 中打开合并请求后立即出现，所以我猜测合并请求的创建是导致错误合并提交的原因。也许使用 'squash commits' 复选框开始发挥作用（它可用于 select 创建合并请求，也可用于已打开的合并请求的合并操作）。
仍然对GitLab为什么要这样做一头雾水，也许是一个bug。下次我创建具有这些奇怪冲突的合并请求时，我会让它们保持打开状态，以查看它是否确实在创建过程中创建了错误的合并请求。
2018 年 12 月更新
再次发布时间。我注意了。仍然不能 100% 确定发生了什么。开始对翻译项目的合并请求，自上次从 qa.
master 的提交为零
冲突。看着他们。没有任何意义。在另一个选项卡中刷新回购时没有注意到任何提交。单击 UI 中的 'resolve conflicts'，完成冲突解决后，创建了来自 master->qa 的提交。这只是 Gitlab 实现的合并方式。您通过将 master 拉入 QA 来解决冲突，然后合并回来。它在 UI 的冲突解决页面
中确实是这么说的或者什么的。快把我逼疯了，但没有时间在发布日磨磨蹭蹭。