Sign Up

Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.

Have an account? Sign In

Have an account? Sign In Now

Sign In

Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.

Sign Up Here

Forgot Password?

Don't have account, Sign Up Here

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Have an account? Sign In Now

You must login to ask a question.

Forgot Password?

Need An Account, Sign Up Here

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Sign InSign Up

The Archive Base

The Archive Base Logo The Archive Base Logo

The Archive Base Navigation

  • Home
  • SEARCH
  • About Us
  • Blog
  • Contact Us
Search
Ask A Question

Mobile menu

Close
Ask a Question
  • Home
  • Add group
  • Groups page
  • Feed
  • User Profile
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Buy Points
  • Users
  • Help
  • Buy Theme
  • SEARCH
Home/ Questions/Q 8844953
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: June 14, 20262026-06-14T11:37:03+00:00 2026-06-14T11:37:03+00:00

We have three main branches in our workflow. TEST (experimental), RELEASE (features going to

  • 0

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?

  • 1 1 Answer
  • 0 Views
  • 0 Followers
  • 0
Share
  • Facebook
  • Report

Leave an answer
Cancel reply

You must login to add an answer.

Forgot Password?

Need An Account, Sign Up Here

1 Answer

  • Voted
  • Oldest
  • Recent
  • Random
  1. Editorial Team
    Editorial Team
    2026-06-14T11:37:05+00:00Added an answer on June 14, 2026 at 11:37 am

    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
    
    • 0
    • Reply
    • Share
      Share
      • Share on Facebook
      • Share on Twitter
      • Share on LinkedIn
      • Share on WhatsApp
      • Report

Sidebar

Related Questions

I have a typical Subversion set-up: /trunk /branches/client-one /branches/client-two /branches/client-three Trunk holds main development
Environment TFS 2010. Three branches: Main , Development and Release . Question I would
The scope of this is that we have three main projects. Some of the
Ok, here's the condensed form. I have three main tables to draw data from:
In Unix, I have got three main files. One of them is a library
I have three subtabs under main tab, when I click main tab defauly I
I have three files, a main .cpp file: #include <stdio.h> #include myClass.h int main()
I have a main table called M1 which consists of Ids of three individual
I have a program that uses three JTextField fields as the main data entry
I've got main folder: c:\test And there I have 2 folders: Movies and Photos.

Explore

  • Home
  • Add group
  • Groups page
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Users
  • Help
  • SEARCH

Footer

© 2021 The Archive Base. All Rights Reserved
With Love by The Archive Base

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.