长期开放分支的 Git 工作流程

Question

我开始在一家小型（4 名开发人员）公司工作。

我们的情况：

在我开始在这里工作之前，他们使用过颠覆。没有人对源代码控制有深入的了解。因此，从来没有真正的关于如何使用源代码控制的概念。 他们在颠覆方面有很多问题，所以我把我们的源代码移到了 Git。现在我们正在使用 Git。 我们正在开发的产品包含大量的应用程序（Windows 服务、Web 服务、Web 应用程序、桌面应用程序、数据库、脚本……）。 （其中大多数是使用 Microsoft .Net 技术或 C++ 创建的。）几乎每个应用程序都与其他应用程序通信或使用相同的数据库（因此，对其中一个应用程序进行更改通常意味着我们必须将其他应用程序更改为）。我们正在尝试使依赖项尽可能少，但其中大部分是无法避免的。 我们正在为不同的客户开发这些应用程序。 安装我们的软件非常简单快捷……但是我们的客户（以及在那里运行服务器的公司）有很多政策（因为他们必须自己测试每个新的或更改的应用程序，这可能需要长达 1 个月的时间），这使得一个安装一个很长的过程。 可悲的是，我们无法改变它。

现在我们的问题：

由于安装费用非常昂贵，我们的客户并不经常这样做（大约每三年一次）。在这三年中，他们不仅希望获得错误修复，还希望获得全新的功能。 （无需更改为许多其他应用程序或数据库。） 但与此同时，我们已经为其他客户等实现了新功能。这意味着我们无法安装最新的源代码（需要进行太多更改）。我们必须在 3 年前安装的源中实现客户要求的功能…… 这最终形成了一个看起来像这样的“工作流程”：

      master
        |
        |
        \
        |\
        | installationCustomer1
        |        |
        |        | (implementing new features)
        |        | (delete branch after about 3 years) 
        |
        \
        |\
        | installationCustomer2
        |        |
        |        | (implementing new features)

我们在我们的集合分支上实施了所有新的东西。 每当我们为客户安装应用程序时，我们都会创建一个新分支。 当客户请求新功能时，我们会在安装后创建的分支中实现它们。其中许多功能也对其他客户有用。如果是这种情况，我们必须在所有其他分支（安装分支和主分支）中实现相同的东西。 通常这是通过将更改复制到其他分支来完成的（合并是不可能的，因为分支有太多差异）。 当没有客户再安装此源时（通常在 3 年后），安装分支将被删除。

现在我们正在寻找一个 Git 工作流程，它允许我们只实现一次这些功能，并将它们合并到其他分支中。 您对我们有什么建议吗？

抱歉，这篇文章太长了，但我不知道如何用更少的测试来描述我们的问题。

编辑： 我们不会让这些“安装分支”为每个客户提供不同的功能。 （不同的特征由参数控制）。所有客户都获得相同的来源。 “安装分支”理论上应该作为标签......但我们必须将它们作为分支，因为我们的客户希望我们在安装时交付的代码中实现新功能。 我们知道我们正在做的事情很糟糕……但我们不知道该怎么做。

Answer 1

您正在使用分支作为配置管理器。我知道这很诱人，但分支适用于并行开发、功能分离等。

我得到的一个建议可能在这里有它的位置，虽然我一开始并不想遵循它：“不要创建你不打算最终合并的分支”。否则你将生活在维护噩梦中，可能是让你写这篇文章的噩梦。

这并不总是正确的。根据您的开发模型，您可能需要诸如master、develop、release 之类的分支，但最终所有提交都将被丢弃或合并到主干。

您似乎想为不同的客户添加不同的功能集。不要为每个客户版本保留单独的功能分支并合并它们的集合（或者手动执行此操作，因为您编写了太多的合并差异），而是尝试拥有一个单一的代码库和一个可配置的构建系统。

配置管理有很多选项，您可以将make 与标志一起使用，cmake 与cmake-gui 是一个不错的选择，我相信还有更多您可以轻松包含或排除模块的地方来自构建。