控制狂：提交被拒绝。 Bitbucket 中不允许 Foxtrot 合并

Question

Control Freak: Commit rejected. Foxtrot merges not allowed到底是什么原因

我们经常收到这个错误，这是由于用户在提交时pull、rebase 和amend 的组合造成的吗？

需要澄清才能永久摆脱这种情况。我知道并理解分支已经分道扬镳，它已经失去了踪迹，但究竟是什么导致这种情况发生在简单的语言中是非常明显的

每当我们看到这个错误时，我们都会重新设置基准，这对我们来说是一个时间杀手。我们正在手动挑选更改以摆脱这种情况。

如何识别已提交的类型，例如之后的正确提交 变基或拉动或修改，而这正是提交 谁？

我们希望教育开发人员摆脱类似的提交错误 今后。很想听听最佳做法。

另外，想了解像 git-bash/source-tree 这样的组合工具有什么理由吗？

我们可以关闭这个原因吗？

Answer 1

这和Foxtrot merges有关，BitBucket上特别禁止：

狐步舞合并是 git 提交的特定序列。一个特别邪恶的序列。在开阔地，在郁郁葱葱的开阔草原上，序列看起来像这样：

但狐步舞很少在户外看到。他们躲在树冠里，在树枝之间。我称它们为狐步舞，因为当它们被抓到中间时，它们看起来就像是同名的交际舞中的足部序列：

Foxtrot 合并是不好的，因为它们会改变 origin/master 的第一父级历史记录。

合并提交的父级是有序的。第一个父级是 HEAD。第二个父项是您使用 git merge 命令引用的提交。

你可以这样想：

git checkout 1st-parent
git merge 2nd-parent

如果推送：

如“GIT: How can I prevent foxtrot merges in my 'master' branch?”中所述，提交“D”是一个狐步舞合并，因为“origin/master”是它的第二个父级。
这是拉取（提取 + 合并）的结果
一旦那个 fox-trot 合并 D 被推送......'origin/master'的第一父历史不再包含提交'B'！

正如torek 在“how to avoid foxtrot merge in git”中所解释的那样，这是直接处理master（新提交C）并执行git pull（而不是pull --rebase、@987654328）的结果@)

这会将B 和C 合并为D（foxtrot 合并），一旦推送，这意味着origin/master 不再有B 作为直接祖先，而是C。
您的工作“C”现在成为主要发布的分支历史记录 (origin/master)，而不是 B，归入已合并的内容。

Answer 2

避免这个问题的最简单方法是始终运行“git pull --rebase”并且永远不要运行默认的“git pull”。这是一篇关于此的深入探讨的博客文章：Too much fun with "git pull --rebase"

您遇到此问题的原因是您的公司为 Bitbucket 安装了免费的Control Freak 插件，并且他们为所有分支机构启用了默认的Foxtrot Prevention 控件。

如果您使用的是 Bitbucket Server 5.5 或更高版本，则可以直接从拉取请求屏幕重新设置拉取请求的基础。单击拉取请求屏幕最右侧的“...”按钮，应该可以使用“Rebase”菜单项。

或者，您可以要求管理员禁用狐步舞预防。甚至 repo 管理员也可以做到这一点（不需要全局管理员）。但我不建议禁用此控件，因为它可以防止混乱的提交历史记录。

完全披露：我为 Bitbucket Server 编写并维护了免费的“Control Freak”插件。

注意：变基和修改永远不会导致狐步舞。通常只有默认的“git pull”会导致 Foxtrot 合并，而“git pull -r”是一个很好的补救措施。 “git merge”命令也可能导致它，但在需要“git merge”的典型场景中使用“git merge”时，人们很少会意外创建狐步合并。我怀疑 99% 的时间是“git pull”导致了问题。