定制化分支合并时冲突频发于 config/ 和 constants.js，因其高修改频次与低语义隔离性：git 仅按行号比对文本，无法识别“租户 a 的超时阈值”与“租户 b 的支付白名单”逻辑归属，导致同文件同位置修改即触发冲突；正确做法是按租户拆分配置文件或加注释标记，并在 ci 中校验租户标识。
定制化分支合并时，为什么冲突总在 config/ 和 constants.js 里爆发
因为这两类文件天然具备「高修改频次 + 低语义隔离性」：不同租户的配置开关、常量值往往写在同一份文件里，且 Git 只认行号和文本块，不认“这是租户 A 的超时阈值，那是租户 B 的支付渠道白名单”。一旦两个定制分支同时改 config/index.ts 第 42 行，git merge 就会直接放弃——它没法判断 timeout: 5000 和 timeout: 8000 哪个该保留，更没法知道它们是否服务于同一租户。
常见错误现象：CONFLICT (content): Merge conflict in config/index.ts 出现后，开发者习惯性删掉 >>>>>> 之间的全部内容，只留自己改的那行，结果上线后租户 B 的支付回调全 500。
- 真正要做的不是“选一行”，而是确认这行配置是否跨租户共享；如果不是，就该拆到
config/tenant-a.ts和config/tenant-b.ts里 - 如果必须共用一个文件，就在每段配置前加注释标记租户来源，例如
// tenant: a — timeout for login flow - CI 流水线里加校验脚本：
grep -r "tenant:" config/ | grep -v "tenant-a\|tenant-b"，防止漏标
git merge 时如何跳过某几个定制化分支的冲突文件
不能真“跳过”，但可以提前规避。Git 不支持 selective merge（选择性合并），但你可以用 git checkout --ours 或 git checkout --theirs 快速覆盖冲突区块，前提是明确知道哪边逻辑更权威。
使用场景：你正在把 feature/payment-tenant-c 合入 develop，但 constants.js 里租户 C 的枚举值不该影响其他租户，而 develop 上的版本是主干基准。
- 执行
git checkout --ours constants.js保留当前分支（develop）的内容，丢弃租户 C 的新增枚举 - 再执行
git add constants.js，冲突即解除——注意，这步不会删掉租户 C 分支里其他没冲突的改动 - 如果租户 C 的枚举确实需要上线，就别用
--ours，改用git show feature/payment-tenant-c:constants.js > tmp-tenant-c.js单独提取变更，人工合并
多租户分支间 rebase 导致历史污染怎么办
git rebase 会重写提交哈希，而定制化分支的 commit 往往带租户标识（如 [tenant-b] add refund policy）。一旦对这些分支做 rebase，原始 commit ID 失效，CI 构建缓存、部署记录、甚至运维追踪链路都会断掉。
性能影响：rebase 过程中所有租户分支的 diff 都要重新计算，尤其当 src/tenants/ 下有 12 个子目录时，git status 响应明显变慢。
- 禁止对已推送的定制分支执行
git rebase，哪怕只是想“整理提交” - 用
git merge --no-ff替代：它生成明确的 merge commit，保留原始 commit ID，也方便回溯“哪个租户的变更在何时合入” - 如果真要清理历史，只在本地未推送的分支上操作，并确保团队同步更新 remote tracking branch
如何让 CI 自动识别租户定制分支的冲突风险
靠人工 git diff 看不出租户间逻辑耦合，但 CI 可以扫描文件路径模式和 commit message 关键词。
示例：当 PR 目标为 develop，源分支含 tenant-d，CI 脚本检查以下三项：
- 是否修改了
shared/下的文件？如果是，触发人工 review 强制项 - 是否在
src/tenants/tenant-d/外新增了tenant-d相关代码？比如误写进src/utils/，这类跨目录污染必须拦截 - commit message 是否含
[skip-ci]或[no-merge]？这类标记需拒绝合并，防止绕过租户隔离规则
最易被忽略的是路径别名问题：有人把 src/tenants/tenant-d 软链接到 src/modules/td，CI 扫描时若只查字面路径就会漏检。必须用 git ls-files 实际展开路径，而非依赖 shell glob。
