使用 git 构建高效的项目架构

Question

首先介绍一下项目的总体架构。

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

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

让我们考虑一些情况。

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

1. 在主服务器上创建 git 分支
2. 为该服务器开发所需的功能 在
3. 本地服务器 x 上创建 git 分支（分支 y）
4. 将更改推送到主服务器
5. 上的分支 y
6. 交换机 本地服务器 x交换机 到主服务器上的 master 分支

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

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

希望听听您关于如何解决“案例 2”和“案例 3”的建议。

Answer 1

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

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

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

您想要做的是将产品的功能管理与版本管理结合起来。

这当然是可行的（仅通过 SCM），并且根据您的要求，它实际上可能适合您。

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

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

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

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

Answer 2

我基本上同意Chief先生的观点。

另外，我想提一下，git 分支最适合在以下三种情况之一中使用：

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

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

Answer 3

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

因此，分支是解决此问题的一种好方法，除非您需要管理从一个分支到多个其他分支的合并。
为此，请参阅“如何在 DVCS 中跨分支移动错误修复？ ”。