TFS PR 搞砸了 Git 历史答案

【问题标题】：Git history messed up by TFS PRTFS PR 搞砸了 Git 历史
【发布时间】：2020-02-15 16:22:25
【问题描述】：

我一直在从我们的主分支 dev 到一个子分支 dev_group1 进行 PR，我们用于并行开发并且我们通常合并到 dev 以及我从哪里合并 dev。

Dev 在 TFS 中有一个 No-Fast Forward 合并策略（强制），而 dev_group1 有一个 Squash 合并策略（强制）。

我们每隔几周做一次：

dev -> dev-group1
dev_group1 -> dev

这几个月来一直运行良好，但在最后一次合并中，我们首先做了一个

dev -> dev-group1

merge，其中有大约 20 个文件冲突。我们解决了它们并合并了 PR。

当我们尝试进行合并时

dev_group1 -> dev

我们看到几乎相同的文件再次发生冲突（大约有 18 个冲突）。这已经很奇怪了，我们决定重做合并

dev -> dev-group1

，它给出了相同的冲突。我们采用了 dev_group1 版本，因为它解决了冲突。

当我们去 TFS 时，我们看到 PR 影响了大约 180 个 tfs 项目，但没有任何文件更改。

我们关闭了 PR。

然后我们尝试重做合并

dev_group1 -> dev

但我们还是有同样的冲突！

这很令人费解，我无法对此作出解释。出了什么问题？

【问题讨论】：

你是否也使用了 squash-merge 合并 dev 到 dev_group1 ？
是的，这是我们的政策允许的唯一一种合并
嗨，MaPi，关于这个问题的任何更新，你有没有机会按照 max630 的最新评论来测试这个建议？

标签： git tfs continuous-integration

【解决方案1】：

Squash 合并丢弃与源分支的祖先连接。因此，下次执行仪表时，将尝试再次合并合并的更改。如果双方的变化完全相同，它就可以成功而不会发生冲突。如果 dev_group1 和 dev 中的更改不相关，则可能会发生这种情况。这就是为什么您以前没有冲突的原因。但是一旦发生冲突，就会一次又一次地发生。

如果您打算在合并后使用源分支，则不应使用 squash 合并。由于您的 dev 分支显然要在以后使用，所以您不应该从中压缩合并。

【讨论】：

如果是这样的话，过去所有其他合并都会发生这种情况，对吧？我们已经进行了大约 100 次这样的合并，但从未发生过
我只能从你的话中说出你所拥有的。你以前有过冲突吗？你确定你以前做过壁球合并吗？如果你责怪dev_group1 中的更改不是来自 group1，那么你会发现来自dev 的壁球合并或其他什么？

【解决方案2】：

问题与拥有一个分支 dev_group1 和另一个 dev_GROUP1 有关。

所以，第二个分支是在开发机器上错误创建的，git 将它们视为单独的分支，在 TFS 网络界面中它们显示为两个单独的分支。

但可能 TFS api 无法区分两者。我们删除了 dev_GROUP1 分支，然后一切正常。

【讨论】：