为单个项目提供多个存储库是一种好习惯

Question

对于单个项目来说，拥有单独的存储库（即开发，质量保证和生产各一个）是否被视为一种良好的做法？

光明的一面：
- 开发人员只能签入Dev但不能签入QA或PROD存储库，因此当您剪切版本时，只有集成商可以拉/合并/集成到QA / Prod存储库。开发人员可以继续在同一个Dev存储库中处理未来版本 - Dev的工作流程与QA和Prod存储库工作流程无关。开发人员不必担心如何完成QA和Prod构建（尽管欢迎他们理解但不需要） - 当代码被冻结以进行剪切时，Devs不会无意中签入发布分支，因此Dev存储库始终处于活动状态，无论哪个版本都在QA或PROD下，都可以进行检查。 - 整个流程可以通过脚本轻松自动化，开发人员可以签入并根据版本号标记提交，脚本可以创建给定版本的所有更改的更改列表，并将更改列表批量集成到QA / Prod存储库
- 如果需要，可以在分离头上进行修补，集成商可以选择或使用拉取请求功能进行合并/修补

这是一个相对安全的模型，因此开发人员无法在发布QA时无意中签入，或潜在用户正在评估Prod构建。它可以很好地控制QA和Prod版本的集成商。

有没有人在企业中遵循这样的模式？

Answer 1

您的方法似乎不必要地复杂。虽然Git从根本上是分散的，但是拥有相同项目的多个分支会导致显着的同步开销。拥有规范的中央存储库，恕我直言，是最简单的解决方案。

另外，我不明白避免分支的动机是什么 - 分支相当便宜是git。如果您主要关注的是强制执行每个用户限制，您可能需要探索几乎所有git托管服务提供的分支限制功能，例如。 Gitlab，BitBucket和Github。

对于代码审核，与pull-request广泛adopted Github community的Gerrit相关的集成管理相关问题非常有效。这对于自动化工具也很有用 - 有一个很好的工具生态系统，例如。 CI服务器，短信等基于此想法并自动分析和验证拉取请求。或者，您也可以浏览Git Flow。

关于功能隔离，发布管理，修补程序部署等方面的问题，我发现的最佳系统分支方法是

{{3}}