我正在将我的源代码从 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),那么我将不得不将它合并到许多分支中(嗯,至少支持的版本和开发/主分支)
这是理想的还是我完全走错了路?