8

是否有 git hook 或其他方式来禁止从特定分支分支和合并。我们要确保不会将“脏”集成分支合并到干净的部署分支中。

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

git checkout integration
git checkout -b major_problem_branch

或者

git checkout deployment_or_hotfix_or_feature_branch
git merge integration
4

7 回答 7

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。他们有通过合并请求控制主分支的好方法。

于 2012-11-09T02:45:52.780 回答
3

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

这意味着你不能指望阻止人们分支，我不确定你为什么真的想要这样做。您可以做的是阻止人们将尚未以某种方式“批准”的工作推送到服务器的部署分支（我将称之为deploy）。

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

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

  1. 确保deploy完全合并到review中，以便以后deploy可以快进到review.
  2. 对 进行任何适当的验证review。
  3. 使用授权密钥git tag -s为review.
  4. 快进deploy到review( git checkout deploy, git merge --ff-only review) 并推动它。

相反，如果您希望任何人都能够部署，但您希望他们必须首先考虑它，您可以做同样的事情，但放宽签名要求。或者你可以祝福一个特定的分支（tested比如说），并要求所有工作在被推送到tested之前被合并并推送到deploy.

deploy服务器如何验证受保护分支是否已获得此批准？基本计划是根据您决定的接受标准使用update钩子接受或拒绝参考更新。refs/heads/deploy

如果您想要一个满足特定标准的标签，例如由批准的密钥签名，那么您可以找到所有指向建议部署的新对象的标签，使用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>equals <old>。

于 2012-11-04T20:56:08.680 回答
1

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

你甚至有一个非常酷的 gitolite Web 界面，称为GitLab，外观类似于 github。

于 2012-11-02T14:07:08.903 回答
1

如果您从不想从脏集成分支合并到干净部署分支，您可以克隆部署存储库，然后仅在克隆（非部署存储库）上执行脏集成工作。

于 2012-11-02T16:13:40.877 回答
1

我可以建议使用nvie 的git flow吗？它通过使用非常简单的命令将所有分支保持在应有的位置。这是一个备忘单模型

于 2012-11-08T23:07:37.873 回答
1

请注意，如果您愿意在中央仓库级别控制访问权限，Assembla是一种 git 托管服务，现在（2013 年 3 月）允许受保护的分支：

请参阅“放下你的叉子 - 引入受保护的分支”：

受保护分支是具有有限写访问权限的分支。
指定能够向分支提交代码的团队成员（或组）：

团体

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

受保护的主分支

于 2013-03-21T11:50:39.520 回答
0

使用每个功能的分支（如我的文章中所述：http: //dymitruk.com/blog/2012/02/05/branch-per-feature/），您就有了发布候选的想法。您可以在服务器上添加一个更新挂钩，以确保发布候选者的合并基础和开发（也称为集成分支）具有一个共同的基础，即迭代开始标记。这可确保您拥有的只是完整的功能本身。

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

于 2012-11-05T05:48:57.503 回答