At work we're currently using CA SCM (the client is called Workbench, formerly Harvest) for version control of Oracle PL-SQL code. It's pretty bad at the latter, but makes it possible for auditing purposes to keep track of who (and when) approved a particular code change to be promoted to our test and production environments.
We've also started using Git the last year or so as version control for our various other projects (many different languages, but web apps are primarily now written in Grails). A few coworkers have also been investigating whether we should use the gitflow workflow or not. We currently tag all of our software when we believe it is ready for review and approval.
With the background out of the way, it occurs to me that one might create both a "test" and "prod" remote branch, and since Gitolite and Stash both allow for per-branch permissions we could restrict those branches to only those allowed to approve code promotion/deployment. But I'm still very much a Git newbie, and I can't quite put all the pieces together myself.
Is there a way to set all of this up so that Git can function as an approval system in addition to everything else it does? Specifically, both the test and prod branches would need to retain only those commit messages relevant to when code changes were merged/rebased/whatever with them. I think that we could have a hook script create these branches automatically with --orphan, but it's not clear to me how a manager would push a tagged release to test or prod.
Can someone get me pointed in the right direction?