We have a central Git repo from which developers fetch and push changes. They make changes on the default master branch. Our Continuous Integration (CI) tool builds artifacts off this default master branch and is the entity responsible for promoting something we want to be tested to a "UAT" branch (this is in reality done by a build-master person clicking a button on the CI tools web page that will do the promotion). The CI tool is also responsible for promoting code from UAT to the "Production" branch. The purpose of the UAT and Production branches is to capture what was promoted to UAT and to Production. No development occurs on the UAT branch and Production will only contain "development" in the form of infrequent "hot-fixes" as our development/release iterations are very fast (1 week iterations).
If we can do it easily, we'd like to put in a control that will prevent someone mistakenly making development changes to UAT and Production branches directly. One thought is to have a hook on the central server that makes sure that only the CI tool user can make changes to UAT and Production. We also thought we could have a central repo that developers use that only contains the master branch and have a second repo that contains the UAT and Production branches. The CI tool will communicate with both repos-- it will look at the development to repo to see when there are changes and use the second repo to do its promotion to the UAT and Production branches.
Is this what folks typically do (separate repos for purposes of development versus promotion?) Would it be better than the server hook approach?