维护金字塔项目的自定义版本（git 分支、代码内变体或其他方法？）
Maintaining customized versions of pyramid project (git branches, in-code variation, or other method?)
简介
我有一个用于库存管理的简单金字塔项目，并使用 git 作为我的 VCS。离开 git 并不难，但是离开金字塔就难了。该项目的范围非常小，仅供单个组织使用，一次最多登录 5-20 次。该项目是为A开发的。
问题陈述
B 也想要一个库存管理软件，我希望重新使用我已经为 A 开发的软件。存在某些根本差异（最重要的是，项目模型会有所不同，因为 A 和 B 都感兴趣在不同的属性中）以及视图差异（至少页面上的徽标会有所不同，并且 B 可能需要基于其使用模式的不同页面，更侧重于跟踪项目贷款，而 A 更侧重于确保在将采购订单发送给外部供应商时及时交付物品）。
基本差异示例
A 和 B 都有名为 Item 和 Group（父子关系）的模型。但是 A 会跟踪项目的 5 个属性（例如品牌、零件号、目标交货日期、实际接收日期、描述），而 B 会跟踪项目的 4 个属性（例如标识号、描述、项目类型（消耗品或可回收-可用）和购买日期）。
考虑的备选方案
从单个基础（或具有公共代码的单个子模块）中分离出多个分支似乎很难保持 synchronized/merged，主要是因为我似乎没有多少 'common code'固定的目录或文件在版本之间根本不会改变。
基于这次谈话 - always ship trunk taken from the accepted answer to Workflow for maintaining different versions of a webapp using git? 建议改为维护单个分支（trunk/master，显然功能开发是一个单独的分支）但代码内版本 if/else检查标志。然而，它似乎更适合同一个网络应用程序的多个版本，而不是像我这样的两个（略有不同的）网络应用程序。
假设 A 和 B 的要求没有明显偏离彼此（例如，A 要求包括财务会计，此时我实际上只会分叉一个单独的项目）？
我不知道 Pyramid，但您可能想要的不是使用 VCS-oriented 方法（即分支），而是模块化方法。像这样：
siteA/
templates/
config/
assets/
tests/
siteB/
templates/
config/
assets/
tests/
modules/
inventory/
financial/
image_gallery/
每个站点的详细信息彼此分开。他们有自己的模板、配置和资产（图像等）来描述他们的行为方式和外观。
一些功能被开发为可配置模块。这是你的库存系统，你的财务系统，图片库......随便什么。
然后 siteA 和 siteB 可以单独选择它们要使用的模块，配置它们的行为方式和外观。
主要优点是站点的细节彼此分离，因此您可以在不改变其他客户行为方式的情况下迎合个人客户的突发奇想。有人可以在 siteA 上工作而不用担心破坏 siteB。通用功能被放入模块中，这些模块具有更正式的文档化界面。
主要缺点是，如果 A 和 B 有很多共同点，则可能会变得多余。有多种方法可以缓解这种情况：将更多通用功能推送到模块中、创建共享模板、通用模板和资产的符号链接、改进模块甚至分支的默认配置。
简介
我有一个用于库存管理的简单金字塔项目，并使用 git 作为我的 VCS。离开 git 并不难，但是离开金字塔就难了。该项目的范围非常小，仅供单个组织使用，一次最多登录 5-20 次。该项目是为A开发的。
问题陈述
B 也想要一个库存管理软件，我希望重新使用我已经为 A 开发的软件。存在某些根本差异（最重要的是，项目模型会有所不同，因为 A 和 B 都感兴趣在不同的属性中）以及视图差异（至少页面上的徽标会有所不同，并且 B 可能需要基于其使用模式的不同页面，更侧重于跟踪项目贷款，而 A 更侧重于确保在将采购订单发送给外部供应商时及时交付物品）。
基本差异示例
A 和 B 都有名为 Item 和 Group（父子关系）的模型。但是 A 会跟踪项目的 5 个属性（例如品牌、零件号、目标交货日期、实际接收日期、描述），而 B 会跟踪项目的 4 个属性（例如标识号、描述、项目类型（消耗品或可回收-可用）和购买日期）。
考虑的备选方案
从单个基础（或具有公共代码的单个子模块）中分离出多个分支似乎很难保持 synchronized/merged，主要是因为我似乎没有多少 'common code'固定的目录或文件在版本之间根本不会改变。
基于这次谈话 - always ship trunk taken from the accepted answer to Workflow for maintaining different versions of a webapp using git? 建议改为维护单个分支（trunk/master，显然功能开发是一个单独的分支）但代码内版本 if/else检查标志。然而，它似乎更适合同一个网络应用程序的多个版本，而不是像我这样的两个（略有不同的）网络应用程序。
假设 A 和 B 的要求没有明显偏离彼此（例如，A 要求包括财务会计，此时我实际上只会分叉一个单独的项目）？
我不知道 Pyramid，但您可能想要的不是使用 VCS-oriented 方法（即分支），而是模块化方法。像这样：
siteA/
templates/
config/
assets/
tests/
siteB/
templates/
config/
assets/
tests/
modules/
inventory/
financial/
image_gallery/
每个站点的详细信息彼此分开。他们有自己的模板、配置和资产（图像等）来描述他们的行为方式和外观。
一些功能被开发为可配置模块。这是你的库存系统，你的财务系统，图片库......随便什么。
然后 siteA 和 siteB 可以单独选择它们要使用的模块，配置它们的行为方式和外观。
主要优点是站点的细节彼此分离，因此您可以在不改变其他客户行为方式的情况下迎合个人客户的突发奇想。有人可以在 siteA 上工作而不用担心破坏 siteB。通用功能被放入模块中，这些模块具有更正式的文档化界面。
主要缺点是，如果 A 和 B 有很多共同点，则可能会变得多余。有多种方法可以缓解这种情况：将更多通用功能推送到模块中、创建共享模板、通用模板和资产的符号链接、改进模块甚至分支的默认配置。