feature/分支必须基于develop创建，不可直接从main拉取，否则绕过集成测试且延迟暴露接口冲突；develop需强制pr与自动化测试；release/是跨模块版本对齐窗口，须验证依赖与api兼容性；hotfix/*须双向合并并cherry-pick限定模块范围。
feature/* 分支必须从 develop 拉，不能直接基于 main
很多团队在初期尝试模块化开发时，会误以为“功能分支只要最终合并到 main 就行”，于是直接 git checkout -b feature/auth main。这会导致两个严重问题：一是新功能代码绕过集成测试（develop 上的 CI 流水线通常不运行在 main 上），二是无法提前暴露模块间接口不兼容——比如 feature/order 和 feature/payment 同时修改了共享 DTO，若都基于 main 开发，直到合并时才冲突，修复成本陡增。
正确做法是统一以 develop 为基线：
- 所有
feature/*分支必须执行git checkout -b feature/user-auth develop -
develop分支需开启强制 PR + 自动化测试（单元/集成/契约测试） - 每日凌晨自动触发
git merge --no-ff合并当日通过测试的feature/*到develop，避免积压
release/* 分支不是“打包前快照”，而是模块版本协商窗口
在模块化系统中，release/v2.1.0 的意义远不止打 tag 或改 version.txt。它本质是一个跨模块的“版本对齐期”——各模块负责人必须在此分支上确认：
- 自己模块的
feature/*是否已全部合入develop并验证通过 - 依赖的其他模块是否已发布对应
git tag（例如auth-module@v1.3.0） - 各模块的 API 兼容性检查（可通过 OpenAPI diff 工具比对）
若跳过此步骤，直接从 develop 打包上线，极易出现“模块 A 用 v1.3 接口调用模块 B，但模块 B 实际部署的是 v1.2”的线上故障。建议在 release/* 分支上强制执行 git submodule update --init --recursive（若用子模块）或 npm ci（若用私有 registry），确保依赖锁定真实有效。
hotfix/* 分支必须双向合并，且要带模块粒度 cherry-pick
线上紧急修复常被简化为“从 main 拉 hotfix，修完再推回去”。但在多模块系统里，这种粗粒度操作风险极高：一个支付模块的 hotfix/payment-gateway 若直接 git merge hotfix/payment-gateway 到 develop，可能把尚未测试的用户中心模块变更也一并带入。
批量替换指定目录下所有 Git 仓库的远程地址（remote URL）。 当用户需要将 Git 仓库从一个服务器迁移到另一个服务器时使用。 触发词：git remote 替换、git url 批量修改、git 仓库迁移、更换 git 地址、批量修改 remote url。
安全做法是严格限定影响范围：
- 从
main拉分支：git checkout -b hotfix/payment-timeout main - 仅修改支付网关相关文件（
modules/payment-gateway/**），禁止碰其他目录 - 修复后，先
git cherry-pick对应 commit 到develop，再git merge回main - CI 系统需配置路径级构建策略：仅触发
payment-gateway模块的测试流水线
模块间依赖不能靠分支名隐含，必须显式声明版本
常见错误是把模块耦合写死在分支命名里，比如 feature/user-auth-with-payment-v2。这看似清晰，实则制造了人为依赖锁：一旦支付模块延期，整个认证功能就被卡住。真正解耦的方式是让每个模块独立演进，依赖关系由版本而非分支控制。
具体落地要点：
- 各模块仓库的
.gitmodules或package.json中，依赖项必须指定精确 commit hash 或语义化版本（如"auth-core": "1.4.2"） - 主项目 CI 在构建
release/*时，自动校验所有子模块是否满足peerDependencies要求 - 禁止在
feature/*分支中修改其他模块的代码——哪怕只是“顺手修个 bug”，必须提 PR 到对应模块仓库
模块化系统的分支复杂度不在 Git 命令本身，而在于如何让每个模块的生命周期、发布节奏、依赖边界在分支结构中可追溯、可审计、可自动化。一旦把版本声明和分支策略混为一谈，后续的灰度发布、回滚、模块热替换都会失去基础支撑。
