我正在从TFVC的土地上将我的源代码移动到Git中，我认为是时候清理并正确地进行 - 目前正在进行大量的复制/粘贴。
我的项目有一个'主要'解决方案 - 如果你愿意，它被视为黄金标准。然而，我的项目适用于不同的业务，两者之间存在内容差异，有些包含彼此不同的深奥业务逻辑（我相信这是一种相对松散耦合的方式）。
我不知道维护“主”构建和不同版本的最佳策略。
我是否为每个版本创建了一个包含多个分支的存储库，或者我将它们拆分为不同的存储库（但显然我无法合并新代码，因此这并不理想）。
我过去遵循了“释放隔离”策略：
F1 ------
|--MASTER----------------
F2 ------ |---v1.4 |---v2.0
| |
|--HF1 |--E1
很抱歉可怕的视觉效果，但Master是我的部署来源，F1 / 2是功能，v1.4 / v2.0是我们需要支持的版本，HF1是来自支持的修补程序发布，E1是该版本中增加的增强功能。
任何修补程序都将合并回Master，当Master拥有足够的新功能和测试功能时，我们会创建一个新版本（v3.0）。
问题是，我不知道这个模型如何适应我的WhiteLabel
F1 ------
|--MASTER(main client)----------------
F2 ------ |---client2 |---client3
| |
|----v1.0 |
| |--E1 |--v1.1
|----v2.0 |----HF1
我不知道这是否足够稳定。
如果我有一个跨所有版本的功能，我可以从Master的左侧开始，然后推送到每个版本的新版本，然后协调任何合并问题。
如果我有一个错误（即HF1），那么我必须将它合并到很多分支（好吧，至少是支持的版本和dev / master分支）
这是理想的还是我走错了路？
答案 0 :(得分：1)
我称之为 - 分叉主策略。
(The Times)
----MASTER---
WSJ-MASTER---| | | |---FT-MASTER
| | | | | |
| | | | | |
| WSJ-RELEASE | | | FT-RELEASE
|--- | | | | |
| WSJ-HF1 | | FT-FR1 |---FT-HF1
WSJ-FR1--| | | |
| TIMES-BF1--| |--TIMES-RELEASE |---FT-HF2
WSJ-BF1--| | |
TIMES-FR1--| |--TIMES-HF1
在这个拥有销售给不同报纸的软件产品的假设示例中，“泰晤士报”被认为是我们的核心平台，我们产生了轻微的变化（因此分叉主人）。
我们不需要释放隔离＆＃39;因为我们只支持一个版本的网站。在主人的左侧，我们进行了所有新的开发（即对代码库进行大量更改的增强功能/错误修复/分叉）。
在右侧，我们有一个＆＃39;发布＆＃39;分支始终与生产中的内容一致，因此我们可以轻松地将其分支以进行热修复。
过去几天使用它（我很欣赏这是一段可悲的时间），到目前为止一直都很好！