Good practice to separate Git Repo from published Repo?

Question

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?

Answer 1

The CI tool needs its own repo anyway in order to maintain a working tree for the builds, right? May as well just publish that repo read-only for the UAT and production branches. Some people prefer the hook method because it is more centralized, but the separate repo method is easier to secure, because you can have them on completely separate computers controlled by separate people. You don't have to worry about who has permissions to change hooks on the developer repo.

Answer 2

No, not necessarily. Usually one repo is used of one project with proper branch management. This separates the code life cycle into 'stages' which helps to keep unwanted changes being deployed to the wrong places. You could have a look at something like git-flow to help your code move from development to deployed on production, using one Repo.

Git-flow can also be facilitated by tools such as Atlassian's Stash and Jenkins.

PS: Depending on the tools used (like Stash) you can lock branches down so that a Pull Request is required before code is merged back to master etc. This could allow code review to take place.