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

针对多个项目和非开发人员的git工作流的建议,git,workflow,Git,Workflow,我有一个我认为很有趣的用例,我认为git可以提供帮助,但我不知道如何组织这样一个存储库。我们有一个小团队(4-6名程序员),他们负责编写脚本和小程序,这些脚本和程序从开发>登台>生产阶段开始。我们团队中没有人有任何使用VCS/DVCS的经验,目前,版本控制是通过本地机器上的文件名约定来管理的,生产代码位于中央服务器上 在接下来的6个月里,我们将从本地开发环境(每个程序员都有许多在本地机器上运行的开发工具)转向中央服务器模式。这种中央服务器模式还要求我们的程序员将他们的文件托管在服务器上,而不是本

我有一个我认为很有趣的用例,我认为git可以提供帮助,但我不知道如何组织这样一个存储库。我们有一个小团队(4-6名程序员),他们负责编写脚本和小程序,这些脚本和程序从开发>登台>生产阶段开始。我们团队中没有人有任何使用VCS/DVCS的经验,目前,版本控制是通过本地机器上的文件名约定来管理的,生产代码位于中央服务器上

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

因此,一些细节:

  • 生产代码可以是特定于项目的,也可以是更通用的,由多个程序员使用
  • 基于项目的代码可以是单个文件,也可以是少量文件(因此,从这个角度来看,使用单个git repo是低效的) *两个程序员不太可能同时处理同一个文件
  • 我们的工作流程应该包含开发、登台和生产代码
  • 我们的程序员可能偶尔需要访问开发代码,例如当有人去度假时(但我想这是可以解决的)
除了为我自己的项目进行非常简单的本地回购之外,我没有任何使用git的经验。从我所读到的内容来看,git重量轻、灵活,足以适应各种配置


有什么建议吗?

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

  • 回购协议1:
    生产
  • 回购2:
    分阶段
  • 回购协议3:
    工具
生产回购:应将
生产回购
用作主代码存储库,且仅允许维护人员访问。此回购协议的配置应如下所示:

git config --local remote.staged <path/to/staged/repo>
git config--local remote.staged 此配置将允许生产维护人员执行一个简单的
git pull staged master
,以将代码从
staged
存储库获取到
production
存储库

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

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


注意这些回购协议(主要是
分阶段的
生产
)基本上包含了您的业务,因此它们应该非常干净方便。因此,在
生产
回购中保留最低要求但足够的代码。尝试同样的方法(强度可能稍低一点)进行分期回购。

您可以保留两次回购。一份回购协议可以用作
生产版
版本,而另一份回购协议将具有
分阶段
代码。将
Production
repo的原点配置到
Staged
repo的位置,这样您就可以使用
git pull origin
Staged
代码移动到
Production
。此外,您还可以使用
Staged
repo中的非master
git
分支作为
Development
代码。谢谢@zeekshigh。将这些作为整体式回购(一个大型回购中的所有项目和通用代码)有意义吗?每个程序员是否需要在服务器上托管自己的私有repo?您所说的“通用代码”是什么意思?@zeekgeneral code是指不特定于项目的代码(助手函数等),这主要取决于个人喜好。我会维护一个不同的存储库,它仍然在开发人员之间共享,以便其他人也可以使用这些工具<代码>生产和阶段回购应仅包含业务逻辑代码。没有别的了。