我正在将我的源代码从 TFVC 土地移动到 Git 中，我认为是时候清理并正确完成它了 - 目前有很多复制/粘贴正在进行。
我的项目有一个"主要"解决方案 - 如果您愿意，它被视为黄金标准。然而，我的项目适应不同的业务，两者之间存在内容差异，有些包含彼此不同的深奥业务逻辑(我认为这是一种相对松散耦合的方式)。
我不知道维护"主"版本和不同版本的最佳策略。
我是为每个版本创建一个具有多个分支的存储库，还是将它们拆分为不同的存储库(但显然我将无法合并新代码，所以这并不理想)。
我过去遵循过"发布隔离"策略：
F1 ------
|--MASTER----------------
F2 ------ |---v1.4 |---v2.0
| |
|--HF1 |--E1
很抱歉视觉效果很糟糕，但 Master 是我的部署的来源，F1/2 是功能，v1.4/v2.0 是我们需要支持的版本，HF1 是支持该版本的修补程序，E1 是添加到该版本的增强功能。
任何修补程序都将合并回 Master，当 Master 充满了足够多的新功能和经过测试的功能来上线时，我们将创建一个新版本 (v3.0)。
问题是，我不知道这个模型如何适应我的白标。
F1 ------
|--MASTER(main client)----------------
F2 ------ |---client2 |---client3
| |
|----v1.0 |
| |--E1 |--v1.1
|----v2.0 |----HF1
我不知道这是否足够稳定。
如果我有一个跨所有构建的功能，我可以从 Master 的左侧开始，然后推送到每个版本的新版本，并协调当时和那里的任何合并问题。
如果我有一个错误(即 HF1)，那么我将不得不在很多分支中合并它(好吧，至少是受支持的版本和开发/主分支)
这是理想还是我走错了路？
我称之为分叉主策略。
(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
在这个假设的例子中，拥有一个出售给不同报纸的软件产品，《纽约时报》被认为是我们的核心平台，我们产生了轻微的变化(因此分叉了master)。
我们不需要"发布隔离"，因为我们仅支持网站的一个版本。在"masters"的左侧，我们有所有新的开发(即增强/错误修复/分叉，用于对代码库进行重大更改)。
在右侧，我们有一个"发布"分支，它始终与生产中的内容保持一致，因此我们可以轻松地将其分支出来以进行热修复。
最近几天用过它(我很感激这是一个可怜的时间)，到目前为止一切顺利！