GIT 挂钩以防止将实验分支推送到发布或主分支

Question

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

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

我们从 RELEASE 中获取特性分支，首先将特性分支合并到 TEST，如果没问题，将那些批准的特性分支合并到 RELEASE。

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

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

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

所以我将只对 TEST 分支进行特定的提交，并记录其提交 ID。

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

由于我不是 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 的提交。例如，在我们的环境中，我们会定期使用来自主分支的新提交来更新实验分支。

您需要有人担任发布经理，以确保如果确实有不好的东西被合并到 master 中，那么在问题解决之前它不会被部署。问题本身不一定是糟糕的合并。问题是部署错误的合并。

Bitbucket.org 是您可能会发现有用的一个工具，他们在那里有一个基本的提交批准机制。这只是建议性的，但可能有助于您跟踪哪些提交已被批准，哪些可能已被错误地合并。