发布版本有收费版/免费版/客户定制版，虽然说在代码中增加条件判断，使用环境变量切换逻辑，能适配多个版本，但实际操作中常常无法这样理想化，有些差异就是写死在代码上。
所以摸索了以下分支管理模式：
main：主分支，维护收费版代码，作为核心代码库
dev：开发分支，所有功能在此开发、测试后合并到 main
free：免费版分支，基于 main 创建，调整/删除或屏蔽某些模块
custom-{客户名}：客户定制分支，基于 main 创建，额外添加或调整某些模块
每做完一个新的迭代，通过merge(合并) 或 cherry-pick(挑拣) 合到发行版中。
merge（合并） | cherry-pick（挑拣提交） | |
| 适用场景 | - 更新的那部分代码完全兼容各个版本 | - 单独为某一版本做的特定功能、特定配置 |
| 引入内容 | 整个分支的全部改动 | 仅特定提交的改动 |
| 提交历史 | 保留原始历史和合并节点 | 仅复制选定的提交，不保留合并关系 |
| 冲突处理 | 多个提交一起处理冲突，可能复杂 | 只处理挑拣的提交，冲突范围小 |
| 溯源 | 清晰保留合并路径，方便审计 | 无法追溯原始分支来源 |
>>更新的那部分代码完全兼容：例如免费版和收费版差异不大，merge 可以一键同步所有功能。
>>代码有明显差异：例如收费版新增10 个新特性，免费版只要其中的 3 个-->这时用cherry-pick
流程
1、创建main分支 （可以初始化 README.md、.gitignore、初始代码、目录结构等）
2、在main分支完成一次基础提交
3、从main创建 dev 分支
4、从dev创建feature分支(可能创建多个feature分支)
5、在feature分支上进行开发
6、切换到dev分支，把feature分支合到dev分支。
7、切换到main分支，把dev分支合并到main分支。
8、从main分支创建release分支。
9、在realese分支上修改特定配置。
10、把release分支发布。
11、重复步骤4-7
12、切换到release分支，把main分支合并到release分支。（此前在release分支修改的特定配置不会被覆盖）
13、把release分支发布。
# 合并收费版
git checkout main
git merge dev# 挑拣免费版需要的功能
git checkout free
git cherry-pick <commit-id>
具体实施：
# 初始化项目
git init
echo "# 项目名称" > README.md
git add .
git commit -m "init: 初始化项目"# 创建 main 和 dev
git branch -M main
git checkout -b dev# 创建 free（免费版分支，长期维护）
git checkout -b free# 推送到远程仓库
git remote add origin <你的仓库地址>
git push -u origin main
git push -u origin dev
git push -u origin free##### 功能开发 ##########################3git checkout dev
git checkout -b feature/login
# 开发、提交代码
git add .
git commit -m "feat: 实现用户登录"git checkout dev
git merge --no-ff feature/login -m "merge: 合并登录功能"
git push origin dev
git branch -d feature/login#### 收费版发布 #######################33git checkout main
git merge --no-ff dev -m "release: 发布收费版 v1.0.0"# 创建 release 分支
git checkout -b release/v1.0.0
# 根据实际需要调整收费版配置
vim config/settings_pro.py# 提交发布
git add .
git commit -m "chore: 调整 v1.0.0 收费版配置"
git push origin release/v1.0.0# 打标签发布
git tag v1.0.0
git push origin v1.0.0
