如何以编程方式检测 master 中不正确（未重新设置）的合并气泡？答案

【问题标题】：How to programmatically detect incorrect (not rebased) merge bubbles in master?如何以编程方式检测 master 中不正确（未重新设置）的合并气泡？
【发布时间】：2020-10-26 17:43:16
【问题描述】：

我们的开发流程规定，每个开发人员都应该先将他/她的主题分支变基为 master，然后将其与 --no-ff 标志合并，以创建合并气泡。这会产生一个漂亮且易于遵循的历史图表。但是，有时开发人员会不小心通过 GitHub 用户界面而不是通过 Git CLI 合并他们的拉取请求，因为 Git CLI 在实际合并之前不会变基，从而导致以下“混乱”的历史图表：

*   G
|\
| * F
|/
*   E Merge pull request #123 from feature-three
|\
| * D
* |   C
|\ \
| |/
|/|
| * B
|/
*   A
|\
| * ...
|/
*   ...
...

如果遵循这个过程，我们会看到这个历史图表：

*   G
|\
| * F
|/
*   E' Merge branch 'feature-three'
|\
| * D
|/
*   C'
|\
| * B
|/
*   A
|\
| * ...
|/
*   ...
...

（我将提交 E 和 C 更改为 ' prime，因为它们会有不同的哈希值）

我们需要以编程方式获取此类损坏的合并提交的列表，例如 E。

git rev-list --merges --format='%h %p' A..G | grep -v '^commit' 产生以下输出：

G E F
E C D
C A B

第一列代表合并提交，第二列是第一个父级（也是合并提交），第三列是第二个父级 - 来自主题分支的提交。但是，损坏的合并的父关系似乎没问题 - 该命令在固定的 Git 历史记录（第二张图）上运行时给出相同的输出，因此我们无法识别它。

必须有另一种方法来检测项目中损坏的合并提交。请注意，需要在历史记录中的每个提交上执行 git 的解决方案不是首选，因为某些项目有 50k+ 提交，并且单个 git 执行需要超过 2 秒。

【问题讨论】：

那时，为什么要合并？改用the rebase option（或仅基于主干的开发），然后您可以关闭回购设置中的其他选项。
你的合并气泡是一个崇高的目标，但在我看来你应该放弃它。在分支上工作时，我总是定期进行 rebase，尤其是在合并之前。但即使我在合并之前变基，也存在竞争条件，因为其他人可以同时合并，在我背后推进主要历史。在我看来，“铁路侧线”历史建筑没有任何问题。我认为如果您只是按照预期的方式使用拉取请求并在 github 上合并，那么您将拥有一个简单的工作流程，并且不会损失任何优点。
@jonrsharpe 好吧，出于分析目的，我想看看我们的工作方式在项目历史上被违反了多少次。
顺便说一句，您可以使用 GitHub 上的 repo 设置中的一些分支保护规则来防止这种不需要的行为

标签： git merge git-merge git-rev-list

【解决方案1】：

您的问题简化为一个简单的图形规则：

master 中的每个第一父级都应该是一个合并提交。（即使对于“坏”图也是如此，但它可能值得检查——如果您允许修补程序在没有合并气泡的情况下进入 master，则应识别任何此类提交，然后不受其他规则的约束。请注意，根提交可能不会遵循此规则，并且可能存在一些截止点，早期提交不遵循任何规则，您应该停止查找。）
每个这样的提交都会有一个 second-parent。该提交及其所有父级应该是简单的（单父级）提交，直到它们也可以从导致该第二父级提交的合并的第一个父级访问——这将通过合并气泡本身进行追踪——并且（这是至关重要的测试）与master 重新加入的提交应该是合并的另一个父级，它使您进入合并气泡的这一侧。

第二条规则为您识别提交 D：D 的第一个也是唯一的父级是 A，而它的父级应该是 C。

所以，只需阅读图表。您可以直接执行此操作（例如，使用 GitPython 或其他方式），或使用 git rev-list --topo-order --parents master 将图形读入文本，然后使用程序读取。

作为Nitsan Avni suggested in a comment，如果你能从一开始就防止意外合并，那是最好的方法，因为事后修复这些是历史重写的一种形式，需要所有用户适应重写的历史.

【讨论】：