1

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?

BestPractices
  • 12,738
  • 29
  • 96
  • 140

2 Answers2

2

For the purpose you subscribe I would say preventing unauthorized commits and merges via hooks is the way to go. You don't have to specifically take care about which remote you are tracking. You also could end up easily in merging back and forth all the time.

iltempo
  • 15,718
  • 8
  • 61
  • 72
  • +1, this can be easily done via tools such as [gitolite](https://github.com/sitaramc/gitolite/) – che Aug 05 '12 at 19:12
0

I'd say cloning a git repo is cheap and easy to setup. If the CI user/build master is capable of promoting something to UAT/production why don't you push the changes to separate repository? Probably something like a linux kernel development model. Every change has been checked in by a developer, tested by the CI user and then authorized and pushed (probably signed) into the release repository.

Even if it's possible to restrict commits in certain areas to certain people I don't feel thats the way to do it with distributed tools. I really like to have open repos and probably use other specialized repositories for certain uses. Git preserves everything and you don't loose information by pushing into other repos. So an author always stays an author - only the committer changes.

Here is a very good article around it with lots of information: What git branching models actually work

Community
  • 1
  • 1