Question

我们的工作流程中有三个主要分支。

TEST（实验性），RELEASE（下一版本的功能）和MASTER（仅发布）

我们从RELEASE获取功能分支，首先将功能分支合并到TEST，如果可以，将这些已批准的功能分支合并到RELEASE。

我的问题是：由于TEST分支包含一些我们不会发布的提交/功能，我们不希望它被错误地（或有意地）合并到RELEASE或MASTER中。

我在某处读到了阻止本地存储库中的合并是不可能或不可行的，我认为这不会解决我的问题。

因此，当新的ref在其提交日志中包含TEST分支的特定提交ID时，最好防止对主存储库中的MASTER或RELEASE分支引用进行更新（通过推送到源）。

因此，我将仅对TEST分支进行特定提交，并记录其提交ID。

每当有人想要推送或释放分支时，我将检查该推送是否会将我的refs / heads / master或refs / heads / RELEASE更新为包含其历史记录中的错误提交ID并且中止的提交引用

由于我不是BASH或GIT大师，有没有人有这样的更新钩子我们可以应用到我们的主存储库？

Answer 1

这是一个应该适用的更新钩子。您可以通过为其提供forbidden/junk或forbidden/debugging等标记来指定不允许进入RELEASE或MASTER分支的提交。如果找到禁止提交，则标记名称将包含在拒绝消息中。

refname="$1"
oldrev="$2"
newrev="$3"
case "$refname" in
  refs/heads/RELEASE|refs/heads/MASTER)
    for forbidden in $(git tag -l 'forbidden/*'); do
      if [ $(git merge-base "$forbidden" $newrev) = $(git rev-parse "$forbidden") ]; then
        echo "Push to $refname contains commit $forbidden" >&2
        exit 1
      fi
    done
    ;;
esac
exit 0

请注意，如果您的分支包含多个问题提交，则必须为最早的分支创建forbidden标记，而不仅仅是系列中的最终提交。因此，如果以下B，C和D被禁止的历史记录仅将D标记为禁止，则不会阻止E合并随身携带B。

A---B----C----D
     \
      ---E

Answer 2

此问题需要作为管理问题解决，而不是自动化问题。问题是TEST可能包含来自其他两个分支的大多数提交。因此，您将无法有效识别来自TEST的提交。例如，在我们的环境中，我们会定期使用主分支中的较新提交来更新实验分支。

您需要有人充当发布经理，以确保如果某些不良内容被合并到主服务器中，那么在解决问题之前不会部署它。问题本身并不一定是糟糕的合并。问题是部署错误的合并。

您可能会觉得有用的一个工具是Bitbucket.org，他们对提交有一个基本的审批机制。它只是建议性的，但可以帮助您跟踪哪些提交已被批准，哪些可能已被错误合并。

GIT钩子阻止实验分支推送到发布版或master分支

2 个答案: