Can I enforce a merge-only branch in git?

Question

I\'m using git, and I\'m setting up the following branches to support my workflow:

• release, which only contains released software,
• testing, which cont

Answer 1

You might want to check out Git flow for some more ideas about this kind of workflow.

Answer 2

More recently, a framework made for authorization enforcement, gitolite, can help putting in place all kinds of policies, for instance to allow only the tester to merge in the "Testing" branch.

In addition, gitolite proposes with VREFs (explained in "Gitolite Update Hook exclude a repository") the possibility to define many "update hooks" which will control the commits being pushed to the repo managed by gitolite.

But all those controls are for a "central" repo, not for all the downstream repos cloned on the various developers' workstations.

Answer 3

Well, sort of. But I don't think you want to go there.

As Jason say, there are hooks that you can use to prevent certain behavior. In this case we could use the pre commit hook to prevent anyone from running "git commit". But this is problematic in several ways:

1. For various security reasons, git hooks are not distributed with the repository, so you cant force people to use your hooks in their repositories. Remember, their repositories are their own, not for you to decide what they do in their repositories.
2. What happens when you do a pull or merge and get conflicts? In order to solve these conflicts you must be able to use "git commit", which we just now disabled.

This just creates more problems than it solves.

However, you could solve this in other ways. You could create a workflow that enforces these principles. For example, imagine that you have person A in charge of doing the merge from the test branch into the release branch. If you let only this person be able to push the changes to the central repository (or that persons repository IS the "central" repository), he/she could pull in changes from the test branch of the test repository, or the test branch of tester B (use your imagination).

What's important here is to realize that you can enforce a policy by designing how you communicate changes with each other. Not everyone need to be able to push their changes to one repository. Heck, they don't even need to push their changes at all. The test people/person could pull in changes from the developers, as soon as they want something tested, and this way you could let test decide when they are ready to pull in new changes, not let the developers decide when the testers should get their stuff. Same principle.

Answer 4

You should be able to enforce this by using some of the git hooks.