禁止从特定分支分支和合并

时间:2012-11-02 13:58:06

标签: git git-workflow

是否有git hook或其他方法来禁止分支和合并特定分支。我们希望确保不将“脏”集成分支合并到我们的清洁部署分支中。

主要目标是人们不能执行这样的事情:

git checkout integration
git checkout -b major_problem_branch

git checkout deployment_or_hotfix_or_feature_branch
git merge integration

7 个答案:

答案 0 :(得分:4)

您可以在服务器上使用分支权限,方法是将其添加到裸存储库中的配置文件中:

[hooks]
        allowedtomerge = user1,user2,user3
        protectedbranches = master

这将允许user1,user2和user3合并到master分支,但没有其他人。

或者你可以创建一个预提交钩子:

#!/bin/bash

if [[ `git symbolic-ref HEAD` == "refs/heads/master" ] -a ["$USER" != "user1"]] then
    echo "You cannot commit in master!"
    exit 1
fi

然后,您有人评估并允许更改继续进行。

理想情况下,我会使用您喜欢的系统,例如gerrit或assembla或github。他们有通过合并请求控制主分支的好方法。

答案 1 :(得分:3)

通常,您无法可靠地阻止任何人在其本地存储库中进行更改。除非你相信你的开发人员永远不会犯任何错误(在这种情况下你不需要这样做),你必须在你的服务器上挂钩检查。

这意味着你不能指望防止人们分支,我不知道为什么你真的想要。你可以做的是让人们不要把那些尚未被“批准”的工作推送到服务器的部署分支(我将称之为deploy)。


现在第一个问题是如何表达这种认可。

如果您想要一个授权人员在部署之前必须审核工作的工作流程,那么如果工作当前位于名为review的分支上,我会让审阅者执行这些步骤:

  1. 确保deploy完全合并到review,以便稍后deploy可以快速转发到review
  2. review进行适当的验证。
  3. 使用授权密钥为git tag -s的内容创建并推送已签名的代码(review)。
  4. 快进deployreviewgit checkout deploygit merge --ff-only review)并推送。
  5. 如果您希望任何人都能够部署,但您希望他们必须首先考虑它,您可以做同样的事情,但放宽签名要求。或者您可以祝福某个特定分支(例如tested)并要求将所有工作合并并推送到tested,然后再推送到deploy


    服务器如何验证是否已为受保护的deploy分支提供此批准?基本计划是根据您决定的验收标准,使用update挂钩接受或拒绝refs/heads/deploy的ref-updates。

    如果您想要一个满足特定条件的标记,例如被批准的密钥签名,那么您可以使用git for-each-ref refs/tags找到所有指向建议部署的新对象的标记。如果任何标记符合条件,请记住接受更新,否则迟早会有人推送阻止部署的错误标记。验证使用了正确的密钥是留给读者的练习,但gpg --no-default-keyring --keyring=approved.gpg可能会有所帮助。

    如果你有任何提交,只要有人标记了它,你就可以使用git describe --exact-match <object>。如果要限制具有特定名称模式的标记,请添加--match <pattern>。如果您接受未注释的标记,请添加--tags

    如果要在合并到部署之前将工作合并到祝福分支,则可以检查git rev-parse tested的输出是否等于建议的新对象。

    在所有情况下,您可能需要仔细检查推送是否是快进推送。您可以检查git merge-base <old> <new>是否等于<old>

答案 2 :(得分:1)

我不认为Git支持分支粒度权限,您应该考虑使用gitolite来满足此类要求。

你甚至有一个很酷的gitolite web界面,名为GitLab,外观类似于github。

答案 3 :(得分:1)

如果您从未希望从脏集成分支合并到干净部署分支,则可以克隆部署存储库,然后仅对克隆(非部署存储库)执行脏集成工作。

答案 4 :(得分:1)

我可以建议git flow使用nvieModel通过使用非常简单的命令,它可以保留所有分支。 Here's a cheatsheet

答案 5 :(得分:1)

请注意,如果您愿意在中央仓库级别控制访问权限,Assembla是一个git托管服务,现在(2013年3月)允许受保护的分支机构:

请参阅“Put Down Your Forks - Introducing Protected Branches”:

  

受保护的分支是具有有限写访问权限的分支   指定团队中可以向分支机构提交代码的成员(或组):

group

  

现在,只有这些人才能进入Master分支   其他人都必须通过合并请求贡献代码。他们将能够推送到仓库中的任何其他分支,但不能Master

protected master branch

答案 6 :(得分:0)

使用每个功能的分支(如我的文章http://dymitruk.com/blog/2012/02/05/branch-per-feature/中所述),您可以了解候选版本。您可以在服务器上添加更新挂钩,以确保候选版本和开发(也称为集成分支)的合并基础具有作为迭代开始标记的公共基础。这可以确保您拥有的只是完整的功能。

如果您想更加确定,可以查看功能是否已完成。您必须将钩子脚本与问题跟踪系统集成。如果正在集成的功能没有“完整”状态,那么您也可能在此时失败。例如,Jira提供了一种通过命令行与它进行交互的方法。