强制特征分支在合并或推出之前进行重组 [英] Force Feature Branch to be Rebased Before it is Merged or Pushed

查看:203
本文介绍了强制特征分支在合并或推出之前进行重组的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在我们的项目中,我们有一个开发分支。我们有六位开发人员可以自由发展,但我们已经要求他们在合并之前在开发之上重新设计他们的功能分支。有时候,人们会忘记这么做,它会为开发创造一个更丑陋的合并历史。

git中是否有配置设置,或者gitlab中的设置可用于防止不是快速合并的合并?理想情况下,我们希望GitLab中的一个策略可以在远程服务器上打开/关闭,所以我们可以在全局范围内关闭它。 解决方案

首先,通常的配置是服务器只接受快进合并(除非被-f覆盖)。但我假设你的情况是人们有自己的功能分支,然后将开发合并到推动开发,所以现在历史有合并提交。



在服务器上,您可以设置 git更新挂钩。更新钩子将在每个分支运行一次,并接收分支名称的参数,被推送的新提交的提示以及添加新提交(即origin / branchName)的分支的尖端。脚本的返回值指示是拒绝还是接受提交。您可以简单地检查这两个提交之间是否存在任何合并提交。

 #!/ bin / sh 
#.git / hooks / update

refname =$ 1
oldrev =$ 2
newrev =$ 3
$ b $ numMergeCommits = $( git rev-list --count --merges $ oldrev .. $ newrev)

if [$ numMergeCommits -gt 0];然后
echo拒绝 - 推送的分支不能包含任何合并
出口1
fi

出口0

请注意,这也不能用-f标志覆盖。此外,回声中的文本Rejected ...被回显给远程推送者,所以你可以在那里写一个更具描述性的信息,希望通过指向wiki页面的链接向他们展示如何使用分支返工重新绑定以获得适当的表单。


In our project, we have a develop branch. We have half a dozen developers who are free to push to develop, but we've asked them to rebase their feature branches on top of the develop before they do the merge. Occasionally, people forget to do this and it creates an uglier merge history on develop.

Is there a config setting in git, or a setting in gitlab that we can use to prevent merges that are not fast forward merges? Ideally, we'd like a policy in GitLab that can turn on/off on the remote server, so we can turn this off globally.

解决方案

First of all, the usual configuration is for the server to only accept fast forward merges (unless overridden by -f). But I'm assuming your case is where people have their own feature branch, then merge develop into that and then push develop, so now the history has that merge commit.

On the server, you can set up a git update hook. The update hook will be run once per branch and receive arguments of the branch name, the tip of the new commit being pushed and the tip of the branch onto which to add the new commits (i.e., the origin/branchName). The return value of the script indicates whether to reject or accept the commit. You can simply check if there are any merge commits in between these two commits.

#!/bin/sh
# .git/hooks/update

refname="$1"
oldrev="$2"
newrev="$3"

numMergeCommits=$(git rev-list --count --merges $oldrev..$newrev)

if [ $numMergeCommits -gt 0 ]; then
   echo "Rejected - pushed branch must not contain any merges"
   exit 1
fi

exit 0

Note that this can't be overridden with the -f flag as well. Also, the text that is in that echo "Rejected..." statement is echoed back to the remote pusher, so you can put a more descriptive message there, hopefully with a link to a wiki page showing them how to rework their branch using rebase to get the commit into the proper form.

这篇关于强制特征分支在合并或推出之前进行重组的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆