Git简化分支管理（main+develop）

简化分支管理，只使用 main（主分支，存放上线代码）和 develop（开发分支，存放v2开发代码）两个分支来同时处理v1 bug修复和v2开发

一、核心分支定位（仅main+develop）

分支	核心作用	操作原则
main	存放v1稳定上线代码，v1 bug修复直接在此分支处理	仅做bug修复，不开发v2新功能，修改后立即上线
develop	存放v2开发中代码，同步main的v1 bug修复	专注v2新功能开发，定期同步main的修复

二、基础操作：新建develop分支

如果你的仓库目前只有 main 分支，需要先创建 develop 分支（基于main的v1版本代码），命令如下：

# 1. 确保本地main分支是最新的（拉取远程main的所有代码）
git checkout main
git pull origin main

# 2. 创建并切换到develop分支（基于当前main分支的代码）
git checkout -b develop

# 3. 将新建的develop分支推送到远程仓库（让团队成员可见并协作）
git push -u origin develop
# 说明：-u 参数会建立本地develop和远程develop的关联，后续直接git push即可

---

三、完整操作流程（分场景）

场景1：修复v1线上bug（不影响v2开发）

# 1. 切换到main分支，拉取最新v1代码（确保和线上一致）
git checkout main
git pull origin main

# 2. 直接在main分支修改v1的bug（仅改bug，不碰任何v2代码）
# （修改代码后）提交修复
git add .
git commit -m "fix(v1): 修复登录验证码失效的bug"

# 3. 推送修复到远程main分支，发布v1修复版本
git push origin main
# （可选）打标签标记修复版本，方便追溯
git tag -a v1.1 -m "v1修复：登录验证码bug"
git push origin v1.1

# 4. 将main的bug修复同步到develop（v2分支），避免v2重复出问题
git checkout develop
git pull origin develop  # 确保develop是最新的

# 方式1：用merge同步（推荐，保留完整历史）
git merge main  # 合并main的最新提交（包含bug修复）到develop
# 方式2：用cherry-pick精准同步（只挑bug修复的提交，适合main有多个无关提交时）
# git cherry-pick <main分支中bug修复的commit-id>

# 5. 解决冲突（如有），提交并推送develop
git add .
git commit -m "sync: 将main的v1 bug修复同步到develop"
git push origin develop

场景2：v2开发完成，合并到main发布

当v2开发完毕、测试通过后，直接将develop合并到main即可：

# 1. 切换到main分支，拉取最新代码（确保包含最新的v1修复）
git checkout main
git pull origin main

# 2. 合并develop分支（v2全部代码）到main
git merge develop -m "release: 发布v2.0正式版"
# （关键）合并前务必完成充分测试，避免v2代码带bug上线

# 3. 打v2版本标签，推送上线
git tag -a v2.0 -m "v2正式版：新增支付功能+优化登录"
git push origin main
git push origin v2.0

# 4. （可选）同步main到develop（确保develop和main一致，后续v2.1开发基于最新代码）
git checkout develop
git merge main
git push origin develop

场景3：日常v2开发（不影响v1）

日常开发v2新功能时，全程在develop分支操作，和main完全隔离：

# 1. 切换到develop分支
git checkout develop
git pull origin develop

# 2. 开发v2新功能，提交代码
git add .
git commit -m "feat(v2): 开发支付功能核心逻辑"

# 3. 推送develop到远程，和团队同步代码
git push origin develop

四、关键注意事项（仅main+develop的避坑点）

1. 严格区分分支修改范围 ：
   • main分支只做v1 bug修复，绝对不能在main上写v2的新功能代码；
   • develop分支只做v2开发，如需修复v1 bug，必须先在main改完再同步过来，而非直接在develop改。
2. 冲突处理要谨慎 ：
   • 同步main到develop时，若出现代码冲突（比如v1修复的代码和v2开发的代码重叠），一定要逐行核对，确保v1的修复逻辑被保留，同时不破坏v2的新功能；
   • 建议同步前先拉取最新代码，减少冲突概率。
3. 提交信息规范 ：
   • 给提交加前缀（如fix(v1):、feat(v2):、sync:），方便快速识别提交用途，比如：
     • fix(v1): 修复订单显示异常
     • feat(v2): 新增会员中心页面
     • sync: 同步main的v1 bug修复到develop
4. 测试环节不能省 ：
   • main分支修改后，先本地/测试环境验证v1 bug修复生效，再推送上线；
   • develop合并到main前，必须完成v2全量测试（包括回归v1的功能），避免上线翻车。

总结

1. 初始准备 ：基于最新的main分支创建develop（git checkout -b develop + git push -u origin develop），这是双分支管理的第一步。
2. 核心逻辑 ：main专管v1稳定/修复，develop专管v2开发，v1修复后立即同步到develop，v2完成后合并到main发布。
3. 关键动作 ：v1 bug修复先在main改，再通过merge/cherry-pick同步到develop；v2发布直接merge develop到main。