必须先将release分支合并到main，再合并到develop；hotfix也须先合main后合develop；release分支需带团队标识前缀；hotfix与release冲突时以hotfix优先。
release分支合并到main和develop的顺序不能颠倒
主分支main必须先接收release分支的合并，再由develop同步该次变更。如果反向操作（比如先合入develop），会导致main缺少该版本的完整提交历史，后续打tag时无法准确锚定生产代码，CI/CD流水线可能误判可发布状态。
典型错误现象：git tag v2.4.0打在develop上，但main还没合并，导致部署系统拉取的不是真实生产版本。
- 正确顺序：从
develop切出release/v2.4.0→ 测试通过后git checkout main && git merge --no-ff release/v2.4.0→ 再git checkout develop && git merge --no-ff release/v2.4.0 -
--no-ff必须加：保留合并提交，方便审计谁在何时发布了什么 - 合并后立即执行
git tag -a v2.4.0 -m "Release v2.4.0"，且只在main上打
hotfix分支必须同时合入main和develop，但有先后依赖
紧急修复必须双线同步，否则会出现“main已修、develop仍带bug”的情况，下次发布又把问题带进去。但顺序不能乱：先合入main，再合入develop，否则develop会把未验证的修复提前引入，干扰其他功能开发。
常见踩坑点：有人为图快，在develop上直接cherry-pick hotfix提交，绕过合并流程——这会破坏提交拓扑，导致后续git log --graph无法追踪修复来源。
使用四维度框架评估任意 GitLab MR 或 GitHub PR 的复杂度：规模（20%），认知负荷（30%），审查工作量（30%），风险/影响（20%）...
- 标准操作：
git checkout main && git merge --no-ff hotfix/PROD-123→ 验证上线 →git checkout develop && git merge --no-ff hotfix/PROD-123 - 如果
hotfix基于旧版main（比如v2.3.0），而develop已包含v2.4.0的大量改动，合并时大概率冲突——此时应手动解决，不要rebase到develop，否则会重写hotfix原始提交哈希，破坏审计链
多团队并行发布时，release分支命名必须带团队标识
当A团队发v2.4.0、B团队也发v2.4.0，共用release/v2.4.0会导致覆盖或混淆。Git不校验分支内容一致性，只认名字，一旦推错，轻则测试环境错乱，重则发布脚本拉取错误代码。
真实协作中，这个细节最容易被忽略，直到某次发布后发现线上行为和测试不一致才排查出来。
- 命名规范强制为：
release/team-a-v2.4.0、release/team-b-v2.4.0，而非简单release/v2.4.0 - CI配置需绑定分支名前缀，例如
release/team-a-*触发A团队的打包流水线 - 删除策略也要区分：A团队的
release/team-a-v2.4.0发布完成后删除，不影响B团队同名但不同前缀的分支
合并冲突发生在release与hotfix交汇点时，以hotfix优先
当release/v2.4.0正在测试，同时hotfix/PROD-123被创建并合入main，此时若release分支需要从main拉取最新修复（比如补丁验证），就可能遇到三方合并冲突。这类冲突不能按普通逻辑解决——因为hotfix是生产救火，必须无条件优先。
关键判断依据不是代码行数或修改范围，而是分支语义：hotfix代表已确认的线上问题，release代表待验证的新版本，前者具有更高业务优先级。
- 解决方式：在
release分支上执行git merge main，出现冲突后，直接接受main侧（即hotfix）的变更，放弃release本地的对应修改 - 禁止用
git reset --hard回退release来规避冲突——这会让已测功能丢失，延误发布 - 冲突解决后，必须重新跑全量回归测试，不能只测hotfix相关模块
git log --oneline main ^release/v2.4.0确认哪些hotfix尚未同步进release，再逐个评估是否必须拉入。 
