长开放分支的Git工作流

我开始在一家小公司工作

我们的情况：

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

现在我们的问题是：

因为安装费用太高，我们的客户通常不会这样做（大约每三年一次）。在这三年里，他们不仅希望修复bug，而且希望获得全新的功能。（无需更改为许多其他应用程序或数据库。） 但与此同时，我们为其他客户等实施了新功能，这意味着我们无法安装最新的源代码（需要太多更改）。我们必须在3年前安装的源代码中实现客户要求的功能… 这最终形成了如下所示的“工作流”：

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

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

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

很抱歉发了这么长的帖子，但我不知道如何用更少的测试来描述我们的问题。

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

---

我们知道我们正在做的事情非常糟糕……但我们不知道其他方面如何做。

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

我得到的一个建议可能在这里有一席之地，尽管我起初并不想遵循它：“不要创建一个您不打算最终合并的分支”。否则，你将生活在一个维护噩梦中，很可能是这个噩梦让你写了这篇文章

这并不总是正确的。根据您的开发模型，您可能需要分支，例如

master

、

develope

、

release

，但最终所有提交都将被丢弃或合并到主干中

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

---

配置管理有很多选项，您可以使用带有标志的

make

，

cmake

带有

cmake gui

是一个很好的选项，我相信还有更多的选项，您可以轻松地在构建中包括或排除模块。

不，我不会尝试为每个客户提供不同的功能。每个特性都可以“合并”到master中，并交付给所有客户（只要用户完全安装了最新的源代码）。我们的问题是“安装分支”应该是标签，但我们必须将它们作为分支，因为我们的客户需要新功能（不改变其他应用程序等）。这些新功能，不是最终会被合并吗？将被合并到master中，但是，我们仍然必须为客户要求的下一个功能保留安装分支。