git pull request 总是显示在提交问题后面

Posted 2023-02-19

【中文标题】git pull request 总是显示在提交问题后面

【英文标题】：git pull request always showing behind commits issue

【发布时间】：2021-03-21 02:31:45

【问题描述】：

我正在使用 gitlab。我的查询是关于拉取请求。我创建了一个“功能”分支。最后，我们向某个“开发”分支创建拉取请求。现在的问题是：对于同一个“开发”分支，将会有“n”个拉取请求。所以，现在如果有人将其他人的合并请求合并到“开发”分支中，那么我必须再次获取最新的拉取，修复冲突，然后必须再次提交和推送，以便我的最新内容被添加到我的拉取请求中。

这似乎有点阻碍，特别是如果开发人员请假几天并且他的合并请求永远不会被合并，因为他的拉取请求总是显示为“你提交了一些提交”。

另一个问题是：被分配合并该拉取请求的人不能这样做，因为他依赖于开发人员，直到他再次与最新提交合并。

那么，有什么解决办法吗？还是每个人都在做与上述相同的事情？

简而言之：我正面临这个问题：gitlab Request to merge branch-A into develop (3 commits behind) should I worry?

【问题讨论】：

这会给您带来实际问题吗？如果一个分支稍微落后于主分支，它仍然可以被合并，除非你启用了一个禁止它的选项。在大多数存储库中，冲突不应该那么普遍。

@bk2204 是的，这对审批者和开发人员来说都是一个问题。由于审批者由于“隐藏提交”而无法合并它，并且每次将任何新提交添加到开发分支时，开发人员都必须始终更新该 MR。正如您所说，我们仍然可以合并，但这真的允许吗？禁止什么选项？和incase如果合并，如果合并MR后发生冲突怎么办？

如果你能够合并，那么就这样做。它落后于一些提交并不是什么大问题，因为这实际上一直在重大项目中发生。如果存在冲突，则无法合并。

@bk2204 如果发生冲突，你会怎么做？ （假设您是批准人）

@bk2204 我对你的回答有疑问..你能检查一下吗..

【参考方案1】：

一般来说，如果后面有几个提交，合并一个分支是可以的。这在任何规模合理的项目中都很常见，并且合并通常与重新定位然后合并时相同。 Git 旨在简单而稳健地处理这种情况。

在合并之前，有些项目可能要求所有分支都是最新的，但如果您的项目不需要这样做，那么没有理由担心。此输出存在的原因是让您了解分支的分歧程度。如果它们的分歧很大，那么可能需要进行 rebase，因为您更有可能遇到不是文本冲突的逻辑冲突。但如果只是一些提交，我不会有压力。

如果有冲突，将无法合并。在这种情况下，通常您会要求原始提交者重新设置基准，因为他们编写了代码并且最熟悉解决冲突。完成后，您可以合并。

【讨论】：

如果我们通过忽略“behind commits”警告直接合并，然后假设发生冲突，所有冲突更改都合并到 dev 分支中，然后无论从 dev 获取最新的，他们都会得到所有冲突的文件，对吧?

没有。如果有冲突，将无法合并。 GitLab 不应该让你这么做。

好吧好吧。还有一件事：在合并请求中，是否有任何批准者直接合并（即使它显示为后面的 2 个提交，例如：miro.medium.com/max/1642/1*cgLb6Th7ZCha01oupEG4JA.png）还是他们要求开发人员将开发合并到功能中并推动解决上述问题问题？

如果有冲突，开发者应该rebase到主分支并强制推送到同一个分支，这将更新MR。如果没有冲突，那么任何人都应该能够在拥有适当权限的情况下进行合并。