1

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

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

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

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

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

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

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

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

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

4

2 回答 2

3

这是一个应该适用的更新挂钩。你可以通过给它们提供标签来指定不应该被允许进入你的 RELEASE 或 MASTER 分支的提交forbidden/junk或forbidden/debugging。如果发现禁止提交，则标签名称将包含在拒绝消息中。

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为最早的提交创建一个标签，而不仅仅是该系列中的最终提交。因此，如果像下面这样的历史记录 where B, C, andD都被禁止，只是标记D为禁止不会阻止E被合并并B随之而来。

A---B----C----D
     \
      ---E
于 2012-11-14T18:14:49.307 回答
0

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

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

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

于 2012-11-14T15:05:49.523 回答