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 contains software released to the testing group,
• develop, which is where development happens,
• some_topic_branch, where features, etc. get added.

Topic branches branch from and get merged into develop. When we’re ready for a testing release, testing merges in develop. When a testing release is approved for production, release merges in testing.

This is all easy enough to set up, but I’m wondering about the enforcement options in git. For example, is it possible to enforce a policy where the only commits on the release branch are merges from testing, preventing changes from happening directly on the release branch?

Answer 1

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.