强制分支在重新合并之前合并并推入

我想在我的Gitlab服务器上添加一个钩子以防止在主服务器上推送合并分支，前提是他们之前没有重新分配。强制分支在重新合并之前合并并推入

例如： A---B---C---D ← master \ E---F---G ← new-feature

我希望用户合并/推前衍合他的特点。 A---B---C---D-------------H ← master \ / E'---F'---G'

我不希望这种推 A---B---C---D---H ← master \ / E---F---G

这样行，是一个良好的开端，但我没有找到意味着只有拒绝不是空的合并提交： Force Feature Branch to be Rebased Before it is Merged or Pushed

来源

2017-06-12 Benito103e

强制重新分配的通常原因是合并承诺的病态仇恨，因为制定政策的人看不到他们的价值。目前还不清楚为什么你想采用rebase的缺点（很可能中间的commit不会被测试），但仍然会合并;这对我来说似乎是最有价值的合并提交可能。但如果你必须...

你意味着你想接受的合并将是“空”;这不完全正确。它将更改应用到其第一个父项（尽管不是它的第二个父项，因为如果允许，它将是快进）。

我认为你是真的说的是，如果第一个父代从第二个父代到达（通过父指针），你会接受合并。所以，你可以采取的

git rev-list --merges $oldrev..$newrev

输出并互相喂导致

git merge-base --is-ancestor commit-ID^ commit-ID^2

提交ID为提交-ID参数拒绝，如果merge-base命令永远返回非零值。

（技术上我猜你可能还需要确保承诺并未有3周或以上的父母。）

仍然允许这样的事情

 (origin/master) 
      | 
x -- x -- x -------------------- M <--(master) 
      \     /
      x -- x -------x -- x 
        \ /
        x -- x

如果避开这是一个规则，这是非常困难的;你基本上会希望通过头提交的第一个父指针可以达到每一个合并。（但你不能只是说，合并应该可以访问从头部提交的第一父，因为那时你还是会允许

 (origin/master) 
      | 
x -- x -- x -------------------- M -- x<--(master) 
      \     /
      x -- x -------x -- x 
        \ /
        x -- x

这是一样的。）所以你可以，也许，作为一个“第一步”你开始寻找合并之前，做一个

git rev-list --first-parent $oldrev..$newrev

，并挂到返回所有提交ID值的列表，从而你会发现每个合并可以确认它在该列表中。

如果这一切听起来都没有乐趣，我完全同意;这就是为什么我不会试图从这个建议中组装一个工作脚本的原因，为什么我建议你允许合并或不要试图采取这样不寻常的中间立场。

来源

2017-06-12 14:30:25

谢谢您的详细解答。重新分配功能分支会在主设备上次更改时进行测试。我接受快进合并，但有时保持分支的绘图有时很有趣。 – Benito103e

* rebase特性分支的*上次提交将被测试。中间提交，不太可能。除非您测试并修复现在重新设计的分支中的每个* before * commit，否则您最终可能会得到'x-x - O - x - O - x - x - x - O'，其中'x'可能无法正确构建或运行，如果您想要使用“bisect”来追踪缺陷，这特别麻烦。 –

这是一个很好的示范，事实上是的，你需要测试，最终在rebase之后修复所有之前的提交。 – Benito103e

这是绝对有可能，但你需要编写一些代码。您还必须决定精确定义“良好”提交图更新的内容。你举的例子说，一个请求从这个去：

o--o--o--* <-- master

这样：

o--o--o--*---o <-- master 
    \  /
    o--o--o

是被拒绝，而这样的：

o--o--o--*---------o <-- master 
      \  /
      o--o--o

将被接受。但是，这第三个替代方案呢：

o--o--o--*------o-----o <-- master 
      \ / /
      o--o--o--o

这增加了两个合并，而不是一个;但是没有新的提交的合并具有的任何父代是先前值为master的祖先。

而且，这个呢？

o--o--o <-- master

（这里推已去除这曾经是master尖端提交。）

如果第二个推动，这增加了两个合并，但他们没有达到回任何早期提交，是不是被接受，和最后一次推送也是不被接受的，你的任务的一部分很容易：你最多允许一个合并，也许只限于两个父母两个父母 - 也许这甚至必须是“第一父母” - 为的先前价值（提交标记为*）。只要建议的新master不是旧的master（没有提交将被删除）的祖先，你的其余任务可能允许没有合并。

如果第二个（两合并）推动是被接受，编码将更加棘手。请注意，如果它不被接受，某人仍然可以推动这样的合并，他们只需要分多步执行（每合并一次）。

来源

2017-06-12 14:06:56 torek

强制分支在重新合并之前合并并推入

回答

相关问题