0

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

我们创建了 50 个不同的系统——每个系统基本上都在做同样的事情，但针对客户的业务规则、评级版本（我们创建保险单跟踪系统）等进行了定制。开发人员被分配到一个团队（总共5 个开发人员）可以访问其中大约 15 个系统——他们可以在任何给定的一周内轻松地对这 15 个系统中的每一个系统进行更改。我们有支持和较小的开发工作，每周“根据需要”集成到实时系统中 - 换句话说，“下一个版本”中没有概述任何内容 - 下一个版本是我们所做的任何事情下周去直播。此外，我们还有已指定截止日期的重大开发项目。除了“

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

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

4

2 回答 2

1

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

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

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

于 2013-06-03T16:04:30.830 回答
0

分离改变的事物

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

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

根据经验，解决此类问题的最简单方法是将发生变化的事物（例如您的业务规则）分离到单独管理的资源中。如何管理该资源取决于您，但Git 子模块或Puppet 节点定义是两个合理的选择。

资源文件和模块

您还可以考虑：

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

同样，做这些事情的目的是提取变化的东西，将其与为每个人加载的应用程序逻辑分开。很大程度上取决于您的应用程序的语言及其架构；这里没有单一的“正确答案”。

于 2013-06-03T16:26:21.033 回答