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:
- 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.
- 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.
