GIT hook to prevent an experimental branch pushed to a release, or master branch

Question

We have three main branches in our workflow.

TEST (experimental), RELEASE (features going to next release), and MASTER (released only)

We take feature branches from RELEASE, merge feature branches first to TEST and if they are ok, merge those approved feature branches to RELEASE.

My problem is: as TEST branch contains some commits/features that we will not be releasing ever, we don't want it to merged into RELEASE or MASTER by mistake (or intentionally).

I read somewhere that it is not possible or feasible to prevent merges in local repositories, and i don't think it would solve my problem.

So, probably it is better to prevent updates to MASTER or RELEASE branch refs in main repository (by pushing to origin) when the new ref contains a specific commit ID of TEST branch in its commit log.

So i'll make a specific commit only to TEST branch, and record its Commit ID.

Whenever someone wants to push to master or release branch, i'll check if that push will update my refs/heads/master or refs/heads/RELEASE to a commit ref which contains that bad Commit ID in its history and abort.

As i'm no BASH or GIT master, does anybody have such an update hook that we can apply to our main repository?

Answer 1

Here's an update hook that should work for that. You can specify commits that shouldn't be allowed into your RELEASE or MASTER branch by giving them tags like forbidden/junk or forbidden/debugging. If a forbidden commit is found, the tag name will be included in the rejection message.

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

Note that if you have a branch that contains several problem commits you must create a forbidden tag for the earliest one, not just the final commit in the series. So if history like the following where B,C, and D are all forbidden just tagging D as forbidden would not prevent E from being merged in and bringing B along with it.

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

Answer 2

This issue needs to be solved as a management issue, not an automation issue. The problem is that TEST likely contains the majority of commits from the other two branches as well. So you won't be able to effectively identify commits that come from TEST. In our environment, for example, we regularly update experimental branches with newer commits from the master branch.

You need someone to act as a release manager, to ensure that if something bad does gets merged into master, then it doesn't get deployed before the issue is resolved. The problem isn't necessarily a bad merge, per se. The problem is deploying a bad merge.

One tool you might find useful is at Bitbucket.org, where they have a rudimentary approval mechanism for commits. It's only advisory, but could be helpful for you to track which commits have been approved and which might have gotten merged in by mistake.