不要让分支合并到另一个分支 [英] Don't allow branch to merge to another branch

问题描述

我有一个分支，我想允许从另一个分支合并。但我不允许它合并到另一个分支（例如Dev，master）。

感谢您的帮助

解决方案

你会发现没有简单的方法来做到这一点。我可以粗略地告诉你，你需要做什么;但是你必须克服一些重大的障碍，对于那些你自己的人来说，因为我没有足够的时间来充分发展我认为是一个可怕的想法。

唯一可能的解决方案是设置git钩子。您可以在原始回购站上放置预接收钩，以便如果任何人尝试包含您不喜欢的合并的推送，推送可能会被拒绝。 （挑战是找出你不喜欢的合并，我会回来的。）

当然，当有人推，他们可能有一个大量的工作，他们不得不重做。因此，您的开发人员知道他们无法推送违反规则的引用，可能需要将相同的脚本安装为预提交钩子以避免错误。 （假设他们并不认为不值得在这种约束条件下进行项目工作，那就是）。

棘手的部分是你如何去检测您之后的合并类型。您的脚本将不得不分析任何新的合并，以查看第一个和第二个父代是什么。因此，您可以先说，如果合并的第二个（或后续）父级等于 master ，则拒绝推送。那么如果你有

  x  -  x  -  A < - （master）
 \ 
x  -  x  -  B < - （dev）
  

某人不能简单比如说：

$ g $ g $ check $ g $ git merge master $ b $ git push
$ / $ c $因为你的脚本认为新的合并提交的第二个孩子是 A ，是 master 。所以他们无法推送

$ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ x $ x $ A $ - （master）

x - x - B - M < - （dev）

但在这种情况下，您可能也不希望他们推送

  x ----- （主）
 \ 
x  -  x  -  B  -  M < - （dev）
  

如果钩子只查看 master ，他们可以得到这个通过说：



  git checkout master 
＃进行一些更改，或者使用allow-empty标志进行以下提交
 git commit 
 git push 
 git checkout dev 
 git merge master ^ 
 git push 
  

开发人员必须竭尽全力将主从合并到一起，但仍然可以这样做。而且，由于您显然希望制定这个规则，这意味着您的开发人员可以看到这些合并的价值，即使您没有这样做，您也可以期望您需要更严格地执行该规则。因此，您的脚本实际上需要查找其第二个（或后续）父级可从 master 访问的任何合并。 / p>



因此，您可以使用类似于 git rev-list 的内容来构建无法合并的修订列表从，并检查每个新的合并，寻找第二（或后续）父母在该列表中。

但这可能会带来一些意想不到的后果。如果您有

  x  -  x  -  x  -  M  -  x < - （master）
 
 $ b $ x --- A < - （修补程序）
 \ 
x  -  x  -  B < - （dev）
  

您应该允许将此修补程序合并到开发中，但在此图片中，它可从主。 （您可能需要将修补程序合并到 dev first和，然后合并到 master ，但是在最好这是与人们可能做的相反的另一个任意约束。）

因此，也许当你使用 rev-list 构建禁止合并目标的列表，你可以给它一个第一个父元素参数。这开始变得难以推论，所以目前还不清楚这是否现在是防弹的，但我认为它越来越接近。

除了接下来的事情是，如果有人使用 reset 来移动 master ref，这样在推送的时候你就无法知道他们合并的内容实际上来自 master 分支？你是否会禁止所有的强制推送操作？ （公平地说，应该小心使用强制推送，这种限制可能会促使开发人员考虑一个常规使用它的工作流程，这是另一个迹象，这是一个糟糕的主意，但完全消除强制推送可能无法奏效。 ）

哦，并且回购得越多（以及 master 的历史越深）密集的你的钩子将变成（减缓 push 操作）。我想你可以在 master 中设置最大数量的提交来查看，假设没有人会回过头来寻找允许的从 master 合并历史片段。但是这对你的脚本来说更复杂一些，这可能会导致它变得非常聪明。

所有这一切的关键在于，你可以花费大量的试图控制你的开发者的努力，或者你可以设定人们遵循的商定团队实践，因为他们是好开发者。

I have branch, which I want to allow go get merged, from another branch. BUT I don't allow it to merge to another branch(e.g Dev, master).

Thanks for help

解决方案

You'll find no easy way to do this. I can tell you, roughly, what you'd need to do; but there are some significant hurdles you'll have to overcome, and for those you're on your own because I'm not dumping enough time to fully develop what I believe is a terrible idea.

The only potential solution is to set up git hooks. You can put a pre-receive hook on the origin repo, so that if anyone tries a push that includes a merge you don't like, the push can be rejected. (The challenge is to identify the merges you don't like; I'll come back to that.)

Of course by the time someone pushes, they might have a considerable amount of work they'd have to redo. So your developers, knowing that they can't push refs that break your rule, might want to install the same script as a pre-commit hook to avoid mistakes. (Assuming they don't just decide it's not worth working on a project with this sort of constraint, that is.)

The tricky part is how you're going to detect the type of merge you're after. Your script will have to analyze any new merges, to see what the 1st and 2nd parent are. So you might start by saying, if the 2nd (or subsequent) parent of a merge is equal to master, reject the push. So then if you have

x -- x -- A <--(master)
 \
  x -- x -- B <--(dev)

someone can't simply say

git checkout dev
git merge master
git push

because your script sees that the 2nd child of the new merge commit is A, which is master. So they can't push

x ----- x ---- A <--(master)
 \              \
  x -- x -- B -- M <--(dev)

But in that case you probably also don't want them to push

x ----- x ---- A -- C <--(master)
 \              \
  x -- x -- B -- M <--(dev)

And if the hook only looks at master, they could get to this by saying

git checkout master
# stage some changes, or make the following commit with the allow-empty flag
git commit
git push
git checkout dev
git merge master^
git push

The developer has to go out of his way to merge master to dev, but can still do it. And since you apparently want to make this a rule, meaning your developers see the value of these merges even though you don't, you can expect that you'll need to enforce the rule more stringently. So your script actually needs to look for any merge whose second (or subsequent) parent is reachable from master.

So you'd use something like git rev-list to build a list of revisions that can't be merged from, and check each new merge looking for the 2nd (or subsequent) parent to be in that list.

But that could have some unintended consequences. What if you have

x -- x -- x -- M -- x <--(master)
 \    \       /
  \    x --- A <--(hotfix)
   \
    x -- x -- B <--(dev)

You should probably allow that hotfix to be merged to dev, but in this picture it's reachable from master. (You could require merging the hotfix to dev first and then to master, but at best that's another arbitrary constraint contrary to what people are likely to do.)

So maybe when you use rev-list to build the list of forbidden merge targets, you'd give it the first-parent argument. This starts to get tough to reason about, so it's unclear whether this is now bullet-proof, but it's getting closer I suppose.

Except the next thing is, what if someone uses reset to move the master ref around, so that at the time of the push you can't tell that what they're merging is actually from the master branch? Are you going to forbid all force-push operations? (To be fair, force-push should be used carefully. The fact that this restriction might push developers to consider a workflow that uses it routinely is another sign that it's a bad idea. But completely eliminating force pushes may not work out so well.)

Oh, and the bigger your repo gets (and the deeper the history of master) the more resource-intensive your hook will become (slowing down push operations). I guess you could set a maximum number of commits in master to look at, on the assumption that nobody will go back too far looking for an allowable segment of history to merge from master. But that's one more complexity for your script, that could potentially lead to it being out-smarted.

The point of all of this is, you can spend a huge amount of effort trying to control your devs, or you can set agreed-upon team practices that people follow because they're good devs.

这篇关于不要让分支合并到另一个分支的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！