使用git的高效项目体系结构

首先，让我介绍一个项目的总体架构

它是分层的。我们为客户开发服务器应用程序。它存储在主服务器上

例如，本地服务器1、本地服务器2、…、本地服务器n是不同公司的服务器（主要应用程序实例）。每个公司都有一台本地服务器。大多数情况下，所有本地服务器都具有相同的功能（例如，核心模块），但是每个公司都可以拥有自己的。作为一个想法，决定通过git分支来解决这个问题

我们考虑一些情况。

案例1
一家公司（本地服务器x）想要一些只有该公司才需要的特定功能。按照分支理念的逻辑，我们执行以下步骤：

在主服务器上创建git分支

开发该服务器所需的功能

在本地服务器x上创建git分支（分支y）

将更改推送到主服务器

在本地服务器x上切换分支y

切换到主服务器上的主分支

案例2
我们开发了一些所有公司通用的功能（核心模块的更改）

案例3
我们开发了一些只对某些公司通用的功能

---

想听听您对如何解决“案例2”和“案例3”的建议吗？

事实上，我们讨论的是一个针对客户的具有变体的核心模块，这意味着git子模块在这里不是一个有效的解决方案：
正在修改同一组文件（对于公共功能，案例2，或者对于某些客户端的功能，案例3）

因此，分支是处理这一问题的好方法，除非您需要管理从一个分支到多个其他分支的合并。

---

关于这一点，请参见“.

从技术上讲，@VonC说分支是正确的

不过有一个警告。你在这里混合了两种不同的范例。SCM（git是一种工具）意味着管理源代码及其不同版本

启用/禁用产品功能是产品管理的一部分。本质上，它归结为应用程序的开发和部署

您试图做的是将产品的功能管理与版本管理结合起来

这当然是可行的（仅通过SCM），并且取决于您的需求，它实际上可能适合您

然而，在一段时间内，您将最终陷入一个分支/合并的困境。它不仅会增加维护和维护每个分支的时间和精力（并保持“主”分支和其他“分支”同步），而且会适得其反，因为每次出现更改或新功能时，您都会花费更多的时间来规划如何使分支保持最新，而不是实际的功能。随着时间的推移，如果新员工事先不了解您的分支机构管理技术，并且您最终拥有分布式团队，他们可能出于各种原因想要创建自己的分支机构，这一点会变得更加复杂

如果我可以建议的话，请保留一个应用程序版本，并实现启用/禁用“功能”的机制。这将使您的SCM更易于理解，更易于实施和维护

中间地带是核心模块的核心分支，然后每个子模块或特征是其单独的分支。任何人都可以安装核心模块，并且根据需要/许可，他们可以从各自的分支安装单独的“功能”

---

希望这能提供一些清晰的信息。如果您有任何问题，我很乐意详细说明。

我大体上同意主任先生的意见

此外，我想指出，git分支最好用于以下三种情况之一：

• 在单独的分支上开发一个功能，完成后将其合并到主线中
• 使用错误修复程序或安全修复程序维护旧版本
• 将当前版本的功能向后移植到旧版本

从长远来看，您应该计划将分支合并回主分支，或者停止它们。让许多分支长时间并排运行并不是一个特别好的主意，因为它们迟早会从主分支（以及彼此）分离，并且很难确保在所有分支上应用错误修复或安全修复