针对多个项目和非开发人员的git工作流建议

时间:2017-09-29 13:33:41

标签: git workflow

我认为这是一个有趣的用例,我认为git可以提供帮助,但我对如何组织这样的存储库感到茫然。我们有一个小团队(4-6名程序员)负责编写脚本和小程序,这些程序从开发>分期>生产阶段。我们团队中没有人有VCS / DVCS的经验,现在,版本控制由本地机器上的文件名约定管理,生产代码位于中央服务器上。

在接下来的6个月中,我们将从本地开发环境(每个程序员在其本地计算机上运行许多开发工具)转移到中央服务器模型。这个中央服务器模型还要求我们的程序员将他们的文件托管在服务器上,而不是本地托管。我们希望在迁移的同时转向(任何类型的)VCS。

所以有些细节:

  • 生产代码可以是项目特定的,也可以是更一般的,并由多个程序员使用
  • 基于项目的代码可以是单个文件,也可以是少量文件(因此从这个角度看,单个git repos看起来效率低下) *两个程序员不太可能需要同时处理同一个文件
  • 我们的工作流程应包含开发,分段和生产代码
  • 我们的程序员偶尔可能需要访问开发代码,例如有人去度假时(但我想这可以解决)

除了我自己项目的非常简单的本地回购之外,我没有任何git经验。从我所阅读的内容来看,git重量轻,灵活性足以适应各种配置。

有什么建议吗?

1 个答案:

答案 0 :(得分:1)

一个简单而安全的解决方案是使用3种不同的git回购。

  • 回购1:Production
  • 回购2:Staged
  • 回购3:Tools

生产仓库Production仓库应该用作主代码库,只允许维护者访问它。这个repo应该配置如下:

git config --local remote.staged <path/to/staged/repo>

此配置将允许生产维护者执行简单的git pull staged master以从Staged存储库到Production存储库获取代码。

分阶段回购master存储库的Staged分支可用作“分阶段代码”,其他分支可用作“开发代码”。

工具仓库:此外,Tools仓库应该用作开发人员使用的常规工具的存储库。理想情况下,Tools repo中的每个工具本身都应该是一个git-repo子模块,但这会让repo有点复杂。

注意这些回购(主要是StagedProduction)基本上包含您的业务,因此它们应该非常干净和方便。因此,请在Production repo中保留最低要求但仅足够的代码。并为Staged repo尝试相同(强度可能稍低)。