长开放分支的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

您正在使用分支机构作为配置管理器。我知道这很诱人，但分支用于并行开发，特征分离等。

我得到的建议可能在这里占有一席之地，尽管我最初并不想遵循它：＆＃34;不要创建一个你不打算最终合并的分支＆＃34;。否则你将陷入维护噩梦，可能就是让你写这篇文章的噩梦。

这并非总是如此。根据您的开发模型，您可能需要master，develop，release等分支，但最终所有提交都要丢弃或合并到主干。

您似乎希望为不同的客户提供不同的功能集。而不是为每个客户版本保留单独的功能分支并合并它们的集合（或者手动执行此操作，因为您在编写时有太多的合并差异），请尝试使用单个代码库和可配置的构建系统。

配置管理有很多选项，你可以使用make标记，cmake和cmake-gui是一个不错的选择，我相信你还有更多的地方可以轻松地在构建中包含或排除模块。