git - Control Freak : Commit rejected. Bitbucket 中不允许 Foxtrot merge

Question

Control Freak: Commit rejected 的确切原因是什么。不允许 Foxtrot merge

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

需要清楚地永久摆脱它。我知道并理解该分支已经发生分歧并且它已经失去了踪迹但是究竟是什么导致了这种情况发生在简单的语言中是非常值得赞赏的

每次看到此错误时，我们都需要重新设置基线，这对我们来说是一个时间 killer 。我们正在手动挑选更改以摆脱这种情况。

如何识别提交的类型，就像之后的正确提交一样rebase 或 pull 或 amended 以及这到底是提交和由谁？

我们想教育开发人员从类似的提交错误中走出来今后。很想听听最佳做法。

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

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

Answer 1

与Foxtrot merges相关，在 BitBucket 上特别禁止:

A foxtrot merge is a specific sequence of git commits. A particularly nefarious sequence. Out in the open, in lush open grasslands, the sequence looks like this:

But foxtrots are rarely seen in the open. They hide up in the canopy, in-between the branches. I call them foxtrots because, when caught mid-pounce, they look like the foot sequence for the eponymous ballroom dance:

Foxtrot merges are bad because they change origin/master’s first-parent history.

The parents of a merge commit are ordered. The first parent is HEAD. The second parent is the commit you reference with the git merge command.

You can think of it like this:

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

如果推送:

如“GIT: How can I prevent foxtrot merges in my 'master' branch?”中所述，提交“D”是一次狐步 merge ，因为“origin/master”是它的第二个父级。
这是一次 pull (fetch + merge)的结果
一旦狐步 merge D 被推送...“origin/master”的第一个父历史不再包含提交“B”!

正如 torek 所解释的那样在“how to avoid foxtrot merge in git”中，这是直接在 master(新提交 C)上工作并执行 git pull(而不是 pull - - rebase , as I always advice )

这会将 B 和 C merge 到 D(狐步舞 merge )，一旦推送，就意味着 origin/master 不再有 B 作为直接祖先，而是 C。
您的工作“C”现在成为主要的已发布分支历史记录 (origin/master)，而不是 B，降级为已 merge 的内容。