Git流程与陷入困境的开发方法一起工作

Question

我很难想出一个适用于我的公司开发方法的GIT流程。我从未与其他软件公司合作过，所以我不确定我们的方法与其他公司相比有多么不同。

我们创建了50个不同的系统 - 每个系统基本上都做同样的事情，但是根据客户的业务规则，评级版本（我们创建保险政策跟踪系统）等进行了定制。开发人员被分配到一个团队（共有5个开发人员可以访问这些系统中的大约15个 - 并且他们可以在任何给定的一周内轻松地对这15个系统中的每个系统进行更改。我们有一个支持和较小的开发工作，每周在“按需”的基础上集成到实时系统中 - 换句话说，“下一个版本”中没有列出任何概述 - 下一个版本是我们完成的任何工作下周上线。此外，我们还有指定截止日期的重大发展。这些截止日期由州政府批准和第三方供应商发布，以及“我们刚刚没有及时完成”的情况，这似乎困扰着我们。

从本质上讲，在任何给定的一周内，我们都可以将次要的支持/开发票和主要开发票发布到生产中 - 这些票在最初创建票时都不具有可靠的发布日期。

我们一直在使用首页扩展，但我们确实需要转移到现在。是否有适合这种开发方法的git流程？不同的版本控制系统会更好地工作吗？

Answer 1

如果计划版和每周版本共享公共代码库（即您拥有单个开发主线和每个系统支持一个版本），则可以使用“按任务分支”构思和Git Flow作为构思的实现。

  

不同的版本控制系统会更好用吗？

（主要）是个人品味和偏好的问题

Answer 2

分开改变的事情

  

我们创建了50个不同的系统 - 每个系统基本上都做同样的事情，但是根据客户的业务规则，评级版本（我们创建保险单跟踪系统）等进行了定制。

问题既不是Git也不是你的工作流程。据我所知，问题在于您的代码的子部分是高度变化的，并且您正在更改核心应用程序而不是子模块或外部资源。

根据经验，解决此类问题的最简单方法是将更改的内容（例如您的业务规则）分离到单独管理的资源中。您如何管理该资源取决于您，但Git submodules或Puppet node definitions是两个合理的选择。

资源文件和模块

您可能还会考虑：

1. 将变体代码重构为YAML，JSON，INI或在运行时读入的其他资源文件。
2. 适用于您的应用程序的一组代码文件（例如Ruby模块），可以在编译时或运行时有条件地包含这些代码文件。

同样，做这些事情的关键是提取更改的内容，将其与为每个人加载的应用程序逻辑分开。很大程度上取决于您的应用程序的语言和架构;这里没有单一的“正确答案”。