当多个客户需要多次定制时的Git管理技术

Question

我正在开发一个将被许多客户使用的应用程序项目，他们可能需要单独进行定制。也就是说，假设我们将应用程序出售给1000个客户，则单个程序可能需要1000个自定义项（例如，处理连接，请求等方面的差异）。我认为我们可以按客户分别为客户创建一个git分支，但是在一个程序上有1000个分支？我认为我们无法正确处理。那不只是我想要的。我想要一个“可持续”的解决方案。我应该如何管理该源代码？我知道有一个'git flow'问题，但是我不知道它是否适合这种情况。

Answer 1

首先，通过1k的自定义设置，对我来说听起来好像出了点问题。使用1k个不同版本的代码，您需要多少个开发团队真正真正地及时支持他们？

我首先考虑一下这些“自定义”：

• 真的必须用代码完成吗？
• 真的必须在同一个仓库中吗？
• 真的必须由开发人员管理吗？
• 真的必须由您来管理？

任何一个“否”都会将您的问题重新表达为一个简单的问题。此外，他们经常在一起。例如，对于从“否”到“代码内”的自定义似乎主要是在配置中或在数据库中的数据中，并且几乎总是对＃3表示不。

您的目标是，开发的支持者/维护者/计​​划者是最后一点。如果可以将自定义从代码中扔出到配置中，或者将模块/插件放在不同的存储库中，或者可以将它们卸载到另一个团队（客户支持团队？），那么您的基本问题就可以解决。

现在，考虑到由于某种原因您不能这样做，那么..一个严格的Git-Flow的变异就是您的朋友。功能分支随处可见。大量使用集成和发布分支。我说的是真正严格的流程，而不是讲习性的Git-Flow，而是“扩展的”流程。

Git-Flow的核心在很大程度上基于功能分支，但在此之后，它是一个单集成，单发布的工作流程。

在进一步阅读之前，应充分了解Git-Flow的工作原理。如果不是，请继续阅读并仅在感觉良好时进一步阅读。

在“教程式” Git-Flow中，每个开发人员都配置：

• 目标核心master分支的名称：master
• 目标下一发行版集成分支的名称：develop
• 特征分支的命名方案：feature / *
• 发布分支的命名方案：release / *
• ..

对于“ 1K客户”，此设置存在问题。您可以拥有大量的功能分支，以进行核心改进，获得新功能，进行各种自定义设置等。但是，一旦“完成”它们，它们就会进入develop，共同发展，而您却被淘汰了。其他人都会得到他们。客户＃1“完成”定制分支最终会流回通过develop到release最终成master，下个月或者一年所有其他客户将得到的太多。你不要

这证明，不可能有一个单一的发展，一个单一的主人。

让我们采取另一种方法。

在“扩展的” Git-Flow（Git-Multi-Flow，听起来很吸引人吗？）中，每个为客户XYZ工作的开发人员都进行了配置，例如：

• 目标核心主分支的名称：master-XYZ
• 目标下一发行版集成分支的名称：develop-XYZ
• 特征分支的命名方案：feature / *
• 发布分支的命名方案：release / *
• ..

我计划他们为master / develop分支使用不同的名称。这意味着对于每个客户，我都有单独的下一版本集成分支，以及当前版本分支的不同版本。

它有什么作用？任何从事某项功能（包括补丁，自定义等）的开发人员都只会使用git flow。但是，如果他们在客户XYZ的背景下工作，他们将“完成”功能并将其集成在专门的develop-XYZ分支机构中。发布后，它将合并到专用master-XYZ分支中。不可能“泄漏”功能或自定义。

但是，“功能”分支仍然很正常。如果在某个时间点您需要功能＃100（最初用于客户ABC）和错误修正＃321（用于客户DEF的原始版本），您仍可以将它们合并到另一个客户（例如XYZ），前提是它们相关的develop-？/ master -？并没有太大的不同，但这是另一个故事）

如果这听起来不错，不错，不错，但它不是说好的。如果客户数量可观，并为他们提供独立的开发/主管，您将很快注意到：

• 如果客户的定制工作很困难，那么他们不仅会在定制领域而且也在核心代码中经常分散他们的开发/母版。这将阻碍他们之间未来的功能共享
• 开发人员会因必须不断更改git-flow配置（将Swithc更改为master-FOO，切换到master-BAR，master-XYZ）而变得脾气暴躁，或者必须保留多个回购副本以配置给不同的客户
• 具有单独的开发人员/母版几乎就像具有单独的存储库，但是更改通知将向所有人发送垃圾邮件
• （..）

那是给初学者的。其中一些可以缓解。第二点可以通过注意git-flow设置.git/config文件中的几行来解决，因此您无需重新配置gitflow或保留repo的多个副本。只需编辑文件。或者保留git-config的副本，然后翻转该文件。或使用$ ENV变量表示当前客户。其他十分之一的解决方法。

接下来，功能。我故意不考虑命名要素分支，feature/XYZ/而是保持简单feature/。功能不必绑定到客户。您可以稍后共享/等它们。

接下来，发布。我故意不考虑命名发行分支release/XYZ/。您永远不会共享它们。你可以。但是，我想您已经为发布分支命名了一个更好的名称，而不仅仅是像给客户名称加上前缀一样releases/XYZ。您还需要在此处输入版本号或日期。也许还有一些功能集的代号。我不知道。在这里发明一些东西。

接下来，核心掌握并发展。对于客户，开发人员正在开发XYZ，master-XYZ。但是您仍然可以拥有核心，master并可以develop进行共享核心代码的改进。那里没有变化。

接下来，我说master-XYZ，develop-XYZ。但这不必是那样的。你知道的feature/...。那么为什么不masters/XYZ＆develops/XYZ？当然可以。你甚至可以XYZ\master和XYZ\develop和XYZ\feature\，但随后，为什么不把单独的回购像在GitHub上，在那里你可以fork /合并/ PR一关别人呢？

Git-Multi-Flow是香草Git-Flow的扩展，使用后一种命名方案（XYZ\master等），最终会在单个存储库中产生多个逻辑存储库。一种多租户Git-Flow ..

所以..有可能。设置起来并不难。但是仍然有1000多个分支的master / develop / etc集，由同一组团队处理，将是一件痛苦的事情。会有错误。开发人员会不时地把事情混在一起，它们只是人。根据我的经验，当“大量的自定义”发生时，它几乎只是URL，端口，密码，图像，样式，文本，有时可能是有限的布局更改。也许在这里或那里一个额外的模块。您应该能够在核心代码中处理所有这些，并通过配置打开/关闭/配置。这样，将大大减少长期存在的“定制分支”（也称为master-XYZ）的数量，但需要为每个客户部署进行更详细的配置。

该配置也应该被跟踪和版本化（即再次在Git中）。我希望你已经做到了。但是它应该与代码位于不同的存储中。这是另一回事。由支持或部署团队管理。提前计划。