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

Question

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

Answer 1

首先，有了 1k 自定义项，在我看来好像出了点问题。使用 1k 个不同版本的代码，您需要多少个开发团队才能真的支持他们及时时尚 ?

我会首先考虑这些“自定义”是否:

真的必须在代码中完成吗？

真的必须在同一个 repo 中吗？

真的必须由开发人员管理吗？

真的要由你管理吗？

对其中任何一个的任何“不”都会将您的问题改写为更简单的问题。此外，他们经常一起去。例如，对于“代码中”的“否”，似乎定制主要在配置或数据库中的数据中，并且几乎总是暗示对#3 不。

你的目标，作为开发的支持者/维护者/规划者是最后一点。如果自定义可以从代码中抛出到配置中，或者在不同的存储库中分离模块/插件，或者如果它们可以卸载到另一个团队(客户支持团队？)，那么您的基本问题就解决了。

现在，考虑到由于某种原因你不能这样做，那么..严格的 Git-Flow 的突变是你的 friend 。到处都有特色分支。大量使用集成和发布分支。非常严格的流程，而不是教程式的 Git-Flow，而是我想说的“扩展”流程。

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

在进一步阅读之前应该了解 Git-Flow 是如何工作的。如果没有，请继续阅读并仅在您觉得自己很了解时再阅读。

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

目标核心主分支名称:master

目标下一个版本集成分支的名称:develop

功能分支的命名方案:feature/*

发布分支的命名方案:release/*

..

对于“1K 客户”，此设置存在问题。您可以拥有大量功能分支，用于核心改进、新功能、各种自定义等。但是，一旦“完成”它们，它们就会转到 develop , 共同发展 ，然后你就完蛋了。其他人都会得到它们。客户#1 的“已完成”定制分支最终将流回 develop进入 release并最终进入 master ，下个月或下一年所有其他客户也会得到它。你不想要它。

这证明，不可能有单一的发展，没有单一的大师。

让我们采取另一种方法。

在“扩展”Git-Flow 中，(Git-Multi-Flow，听起来很吸引人，有人吗？)，每个 为客户 XYZ 工作的开发人员 配置，例如:

目标核心主分支名称:master-XYZ

目标下一个版本集成分支的名称:develop-XYZ

功能分支的命名方案:feature/*

发布分支的命名方案:release/*

..

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

它给了什么？任何处理功能(无论是补丁、定制还是其他)的开发人员都只使用 git flow。但是，如果他们在客户 XYZ 的上下文中工作，他们将“完成”该功能，并将其集成到专用 develop-XYZ 上。分支。发布后，它将 merge 到专用 master-XYZ分支。没有“泄漏”功能或自定义的可能性。

但是，“功能”分支仍然是正常的。如果在某个时间点您想要功能 #100(最初用于客户 ABC)和错误修复 #321(用于客户 DEF)，您仍然可以将它们 merge 到另一个客户，例如 XYZ，前提是它们的相关开发-?/master 存在差异-？并没有太大的不同，但那是另一个故事)

如果它听起来不错，那么，不错，但它不是那么好。拥有相当数量的客户并为他们单独开发/主管，您会很快注意到:

如果客户的定制很困难，他们会经常在开发/掌握方面发生分歧，不仅在定制领域，而且在核心代码上也是如此。这将阻碍他们之间 future 的功能共享

开发人员会因为必须不断更改 git-flow 配置(切换到 master-FOO，切换到 master-BAR、master-XYZ)，或者必须保留多个 repo 副本，为不同的客户配置而感到不满

拥有单独的开发/主控几乎就像拥有单独的存储库，但更改通知会向每个人发送垃圾邮件

(..)

这是初学者。其中一些可以减轻。第二点可以通过注意到 git-flow 设置在 .git/config 中只有几行来解决。文件，所以你 不需要重新配置 gitflow 或保留多个 repo 副本 .只需编辑文件。或者保留一份 git-config 的副本，然后翻转该文件。或者使用一些 $ENV var 来指示当前客户。解决它的其他方法的十分之一。

接下来，功能。我故意不考虑命名功能分支feature/XYZ/但很简单 feature/ .功能不必绑定(bind)到客户。您可以稍后共享/等。

接下来，发布。我故意不考虑命名发布分支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 /merge/公关？

Git-Multi-Flow 是 vanilla Git-Flow 的扩展，使用后一种命名方案(XYZ\master 等)，您最终会在单个存储库中获得多个逻辑存储库。一种 Multi-Tenancy Git-Flow ..

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

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