托管版本的项目组织
project organization for managed editions
我们开始重构支持大约 30 个客户端的中型 HMVC Web 应用程序。目前，代码由 SVN 存储库中的单个分支管理。有时，更改是特定于客户的，而其他时候，更改将适用于所有客户。我们是唯一处理来源的人。
每个客户端都需要大量定制，从业务逻辑到显示，但所有工作基本相同，事实证明所有客户端都共享数据库表，其中包含用 client_id 列区分的特定公司信息。
围绕新代码的组织有两种想法，我很难理解这两种方法之间的差异以及每种方法的优缺点。任何有助于更好地理解这一点的帮助将不胜感激。
1) 将每个单独的应用程序功能放在其自己的 git 存储库中。为应用程序功能的所有部分创建接口，以管理这些部分之间的依赖关系。使用 PHP 程序包管理器 Composer 管理这些应用程序组件，以便客户端将包含一个程序包清单，其中包含其所有组件和该组件的版本。如果单个应用程序需要更改模块，请通过分叉该模块来创建新的 package/repository。如果更改跨越多个模块，则创建多个新存储库，将它们发布为作曲家包，并将新包添加到客户端清单。
2) 为整个应用程序创建一个 git 存储库。为每个客户端创建一个分支（或分支）。对于特定于客户端的更改，请使用 fork。对于所有客户端的更改，请使用主存储库，对于每个客户端，根据需要将上游存储库合并到客户端存储库中。
哪种方法可以为开发团队提供长期的可管理性和灵活性？是否有其他方法可供考虑？就目前而言，由于等级制度和多年的滥用，很难同时进行特定于客户的更改和系统范围的更改。
第一种方法类似于组件方法I detailed here。
区别在于您使用的是 php Composer，这意味着您可能不需要依赖 git submodule as I usually suggest, since the Composer FAQ 建议：
Adding dependencies installed via git to a git repo will show them as submodules.
This is problematic because they are not real submodules, and you will run into issues.
Git 子模块可能仍然需要（以管理 none 父仓库中的一组更改），但由于 Composer 不支持它们，您可以在“How do I use a Git submodule with a Composer loaded library?".
就长期可管理性和灵活性而言，方法 1 仍然是更好的方法，但一开始可能需要大量的重新架构工作。
另一种方法是使用gitflow。
正如您在 #2 中指出的那样，它将允许您为每个客户拥有多个 "master" 和 "release" 分支，同时它足够灵活，可以将您的修复、功能等添加到所有分支您的 "customers" 实际上是此模型中的分支。
第二个选项是使用 submodule/subtree 但每个子模块都是一个完全不同的存储库（如您的 #1 建议中所述）
我们开始重构支持大约 30 个客户端的中型 HMVC Web 应用程序。目前，代码由 SVN 存储库中的单个分支管理。有时，更改是特定于客户的，而其他时候，更改将适用于所有客户。我们是唯一处理来源的人。
每个客户端都需要大量定制，从业务逻辑到显示，但所有工作基本相同，事实证明所有客户端都共享数据库表，其中包含用 client_id 列区分的特定公司信息。
围绕新代码的组织有两种想法，我很难理解这两种方法之间的差异以及每种方法的优缺点。任何有助于更好地理解这一点的帮助将不胜感激。
1) 将每个单独的应用程序功能放在其自己的 git 存储库中。为应用程序功能的所有部分创建接口，以管理这些部分之间的依赖关系。使用 PHP 程序包管理器 Composer 管理这些应用程序组件，以便客户端将包含一个程序包清单，其中包含其所有组件和该组件的版本。如果单个应用程序需要更改模块，请通过分叉该模块来创建新的 package/repository。如果更改跨越多个模块，则创建多个新存储库，将它们发布为作曲家包，并将新包添加到客户端清单。
2) 为整个应用程序创建一个 git 存储库。为每个客户端创建一个分支（或分支）。对于特定于客户端的更改，请使用 fork。对于所有客户端的更改，请使用主存储库，对于每个客户端，根据需要将上游存储库合并到客户端存储库中。
哪种方法可以为开发团队提供长期的可管理性和灵活性？是否有其他方法可供考虑？就目前而言，由于等级制度和多年的滥用，很难同时进行特定于客户的更改和系统范围的更改。
第一种方法类似于组件方法I detailed here。
区别在于您使用的是 php Composer，这意味着您可能不需要依赖 git submodule as I usually suggest, since the Composer FAQ 建议：
Adding dependencies installed via git to a git repo will show them as submodules.
This is problematic because they are not real submodules, and you will run into issues.
Git 子模块可能仍然需要（以管理 none 父仓库中的一组更改），但由于 Composer 不支持它们，您可以在“How do I use a Git submodule with a Composer loaded library?".
就长期可管理性和灵活性而言，方法 1 仍然是更好的方法，但一开始可能需要大量的重新架构工作。
另一种方法是使用gitflow。
正如您在 #2 中指出的那样，它将允许您为每个客户拥有多个 "master" 和 "release" 分支，同时它足够灵活，可以将您的修复、功能等添加到所有分支您的 "customers" 实际上是此模型中的分支。
第二个选项是使用 submodule/subtree 但每个子模块都是一个完全不同的存储库（如您的 #1 建议中所述）