租户分支命名必须含租户标识，如tenant-beijing/feature/sso-integration；租户代码须与公共代码物理隔离，分层存放于src/tenants/与src/core/；公共修复须经main→develop→租户分支标准合并路径，禁用批量cherry-pick；租户分支需按服务周期归档，禁止长期存活。
多租户定制分支命名必须带租户标识
不加租户前缀的 feature/login 或 hotfix/2024-01 会导致不同租户的修改混在一起，后期根本无法区分哪段代码属于哪个客户。所有分支名必须显式包含租户 ID 或缩写，比如 tenant-beijing/feature/sso-integration、tenant-shenzhen/hotfix/pdf-export。
常见错误是把租户信息只写在 commit message 里——Git 分支名本身才是第一层过滤器，CI/CD 流水线、权限策略、自动化标签都依赖它。Gitee 和 GitHub 的 branch protection rule 都支持按 glob pattern 匹配，例如 tenant-*/** 可统一限制推送权限。
- 租户 ID 建议用小写字母+短横线（如
tenant-nanjing），避免下划线或大写，兼容所有 CI 工具解析 - 禁止使用模糊词如
customer-a、client-x，上线后运维查日志时无法对应真实客户 - 分支创建后立即推送到远程，本地分支不推 = 没有备份，且其他成员无法基于它协作
公共逻辑与租户逻辑必须物理隔离
把租户专属代码和公共代码揉进同一个文件，靠 if tenant == 'beijing' 切换，短期看似省事，长期必然失控。一旦某租户提出特殊字段校验、流程跳过、UI 隐藏等需求，就会催生大量条件分支，测试覆盖难、回归风险高、代码 review 成本飙升。
正确做法是分层：公共模块放 src/core/，租户扩展放 src/tenants/beijing/，通过依赖注入或插件机制加载。Git 本身不强制目录结构，但团队必须约定并 enforce —— 否则分支合并时，git merge tenant-beijing/develop 会把一堆 if-else 冲突塞进你编辑器。
- 租户专属代码不允许修改
src/core/下任何文件，违反即触发 pre-commit hook 拒绝提交 - 新增公共能力必须先合入
main，再 cherry-pick 到各租户分支；不能反向操作，否则租户分支污染主干 - CI 构建脚本需识别当前分支前缀，自动加载对应租户配置和扩展包，避免构建出错
cherry-pick 不是万能同步手段
看到公共 bug 修复后，直接 git cherry-pick abc1234 到十几个租户分支，表面快，实则埋雷。因为不同租户分支可能已对该 commit 修改过的函数做过重写、删除或大幅调整，cherry-pick 会触发冲突，而开发者往往只解决文本冲突，忽略语义冲突——比如该修复依赖一个刚被租户删掉的工具函数。
真正安全的做法是：所有公共修复必须走 main → develop → tenant-X/develop 的标准合并路径，并要求每个租户分支在合并后跑完整回归测试。cherry-pick 仅限 hotfix 场景（如线上紧急止血），且必须附带手动验证 checklist。
- 禁止对已 merge 进租户分支的 commit 再 cherry-pick，Git 会提示 “already applied”，但实际可能因 rebase 而漏判
- cherry-pick 后必须运行
git log --oneline tenant-beijing/develop ^main确认该 commit 确实不在主干历史中 - 自动化脚本批量 cherry-pick 是高危操作，应禁用；人工逐个处理才能把控上下文
租户分支生命周期必须明确终止条件
很多团队让租户分支长期存活，比如 tenant-hangzhou/develop 从 2022 年建到现在，中间经历 5 次 major 版本升级，没人敢删，也不敢合回主干。结果是每次发布都要手动 diff 几十个分支，确认哪些租户还没上新功能。
每个租户分支应绑定明确的服务周期：合同到期、系统下线、或迁移到统一 SaaS 版本后，该分支必须归档（archived）而非删除——归档保留历史可查，但禁止新提交。Gitee 和 GitHub 都支持仓库级归档标记，CI 也会自动跳过归档分支的构建任务。
- 归档前必须完成最后一次
main → tenant-X/develop合并，确保无遗漏公共更新 - 归档分支的 remote tracking ref 保留在服务器上，但本地工作树可清理，节省空间
- 归档不是终点：若该租户未来重启合作，应新建
tenant-hangzhou-v2/develop，而非解封旧分支
