git多定制版本管理

git多定制版本管理

1，背景描述

  在项目开发过程中，最初只有一个版本进行开发。后续随着我们的产品给不同的客户使用，我们需要针对各个客户开发定制需求，由此我们会逐步拥有很多定制版本进行代码的开发与维护，如果我们不能好好进行多定制管理的管理，那我们的开发会变的越来越麻烦。

2，解决方案

  主要有多分支、多仓库、多判断等解决方案

2.1 多分支方案

图1 单仓库多分支

单个仓库，使用多个分支来进行多定制版本的维护
优点：仓库维护简单；公共修改同步简单
缺点：分支众多

2.2 多仓库方案

图2 多仓库单分支

多个仓库，每个仓库中只有一个定制版本的代码
优点：进行定制版本开发的时候，清晰明了，不会与其他版本混淆
缺点：公共缺陷修改、公共需求开发时合并代码较为复杂；多仓库维护繁琐

2.3 多判断方案

单仓库、单分支，直接将多个定制版本整合进一套代码中并且通过版本参数来决定处理策略
优点：无需繁琐的多分支、多仓库管理，bug修复自动同步所有定制版本
缺点：代码繁杂

2.4 其他方案

传统软件构建策略、基于配置的软件构建策略、加入工具支持、加入动态语言
https://blog.csdn.net/oZuoYu123/article/details/77947161

3，流程详解

  以操作相对简单的单仓库多分支方案为例，进行详细介绍

图3 多分支示意图

3.1 定制分支初始化与规范

  以创建北京市政府项目的定制版本为例，直接从origin的master和develop中分别切出beijing/master和beijing/develop分支，然后推送到远程仓库。
  其他的定制版本分支以此类推，可以获得如下结构

图4 定制版本初始化

3.2 定制分支修改

  定制版本的特殊需求只用在该定制版本的分支上进行编码、修改、推送、提测、合并即可

3.3 通用修改

  有一些公共缺陷、公共需求等需要在主分支进行修改，待提测通过后使用cherry-pick命令推送这个修改到所有的定制版本（develop）分支上

3.4 提测

  定制版本的特殊修改需要独自提测，公共缺陷、公共需求等修改需要自己进行提测并且建议各个定制版本也要进行独立的提测（因为公共修改与各个定制版本有一定的耦合性，可能会产生不同结果）

4，注意事项

①公共修改推送到各个定制版本后，建议都进行一次提测
②公共修改建议在origin主分支上修改后使用cherry-pick推送修改到定制版本分支
③定制版本出现的缺陷，需要在origin主分支上进行认真检查，查看该缺陷是否是公共缺陷

5，参考链接

1，对于一个项目多版本的 git 版本控制解决方案 https://blog.csdn.net/oZuoYu123/article/details/77663912
2，git程序多版本维护方案 https://blog.csdn.net/weixin_30367873/article/details/96127853
3，多版本产品git规划 https://www.jianshu.com/p/262ca660310e
4，基础版本 + 多定制版本 的git 解决方案 https://blog.csdn.net/zeraw/article/details/106137869