Is it a good practice to have multiple repositories for a single proejct

Question

Is it considered a good practice to have separate repository i.e. one each for Dev, QA and Production for a single project?

On the bright side:
- Developers can only checkin to Dev but not into QA or PROD repository, thus when you cut a release, only integrators can pull/merge/integrate in to QA/Prod repository. Devs can continue to work on future releases within the same Dev repository
- Dev's workflow is agnostic of what goes into QA and Prod repository workflow. Devs need not be bothered how QA and Prod builds are done (though they are welcome to understand but not required)
- Devs cannot inadvertently checkin to a release branch when code is frozen for a cut, thus Dev repository is always live and can be checked in irrespective which release is under QA or PROD.
- The entire flow can be easily automated via scripts, devs can checkin and mark commits against a version number, scripts can create changelist of all the changes for the given version, and integrate changelist in bulk to QA/Prod repository
- Patching can be done on detached head if and when required, integrators can cherry pick or use pull request feature to merge/patch

This is a relatively safe model so developers cannot inadvertently checkin whilst the release is under QA, or Prod build is being evaluated by potential users. It gives fine control to the integrators of what goes into QA and Prod release.

Does any one follow such a model in enterprise?

Answer 1

Your approach seems to be unnecessarily complex. While Git is decentralized fundamentally, having multiple forks of same project results in significant synchronization overhead. Having a canonical central repository, IMHO, is the simplest solution.

Plus, I don't understand what is the motive behind avoiding branching - branching is fairly cheap is git. If your primary concern is regarding enforcing per user restrictions you may want to explore into branch-restriction feature offered by pretty much all git hosting services eg. Gitlab, BitBucket and Github.

For code-reviews, integration management related concerns the pull-request based model widely adopted by Github community works very well. This works great for automated tools as well - there is a good ecosystem of tools eg. CI servers, linters etc. that are based around this idea and do automated analysis and verification of pull-requests. Alternatively, you could also explore Gerrit.

Regarding the concerns around feature isolation, release management, hotfix deployment etc., The best systematic branching approach I have found is the Git Flow