feature分支避免互相污染的关键是坚守原子性与责任契约：始终以master为基线创建，禁止跨feature合并，每日仅同步master而非develop，develop仅接受多feature联合验证后的统一合入，hotfix按需注入而非全量广播。
feature 分支如何避免互相污染？
多人并行开发时，feature/A 和 feature/B 同时修改同一文件（比如 src/api/auth.js），但彼此 unaware，等一起合入 develop 时才暴露冲突——这不是 Git 的错，是分支演进路线没隔离好。
关键不是“能不能合”，而是“谁该在什么时间点看到谁的代码”。feature 分支必须保持原子性：只承载自身迭代逻辑，不提前感知其他 feature 的变更。
- 禁止直接从一个
feature合并到另一个feature（如git merge feature/A到feature/B） -
feature分支始终以master为基线创建，不以develop或其他feature为源 - 每日同步仅限
git pull origin master，而非git pull origin develop - 若需复用某功能逻辑，应提取为独立模块（npm 包、monorepo 子包），而非跨分支拷贝代码
develop 分支到底该不该接受部分 feature 合并？
答案是否定的：develop 不是“临时集成区”，而是“全量预发布快照”。一旦允许 feature/A 单独合入，feature/B 就被迫依赖未验证的 A 代码，测试环境无法稳定复现。
真实场景中，develop 的每次更新都应对应一次明确的“多 feature 联合验证窗口”——比如每周三下午统一合入所有已自测通过的 feature/*，然后触发全链路 CI。
-
develop的 commit 历史必须只包含merge提交，且每个merge都带清晰的 PR 关联（如Merge pull request #42 from feature/login-v2） - 禁止在
develop上直接git commit修复 bug；bug 必须定位到具体feature分支修复，再重新走合并流程 - CI 脚本需校验：任何推送到
develop的提交，其 parent 必须是上一个develop头，或来自合法feature分支的 fast-forward 合并
test 分支如何支撑 B 插队 A 的紧急上线？
当 feature/B 突然要先于 feature/A 上线，test 分支不能简单删掉 A ——那会丢失 A 已验证的改动，还可能破坏 B 依赖的公共逻辑。
正确做法是用 git cherry-pick 构建最小化交付集，而不是靠分支删除或重置来“清理”：
- 从
feature/B创建临时分支release/b-urgent -
git cherry-pick所有 B 的提交（注意跳过 merge 提交和调试 commit） - 手动补丁修复 B 依赖但尚未合入
master的公共模块（如 utils 函数），确保不引入 A 的副作用 - 将
release/b-urgent推送至test，而非直接 pushfeature/B - 上线后，
feature/A仍保留在develop中，只需 rebase 到新master头即可继续
hotfix 如何避免污染正在并行的多个 feature？
hotfix 从 master 拉出没问题，但合回时若只合到 master，会导致所有 feature 分支后续 rebase 或 merge 时带入 hotfix，而其中部分 feature 可能根本不需要该修复（比如 hotfix 是支付超时，而 feature/C 是后台日志模块）。
真正安全的做法是“按需注入”，而非“全量广播”：
-
hotfix必须同时合入master和develop（保证主干一致性） - 对每个活跃
feature分支，由负责人自行判断是否需要该 hotfix：git cherry-pick <hotfix-commit>，而非强制同步 - CI 流水线需识别
hotfix/分支的推送，自动触发对所有 openfeature/*PR 的兼容性检查（比如运行受影响模块的单元测试） - 禁止在
hotfix中混入非修复逻辑（如“顺手优化了按钮样式”），否则会污染语义边界
分支演进路线最易被忽略的点，不是命令怎么写，而是每个分支的“责任契约”有没有被所有人理解并遵守。一旦有人把 develop 当成个人暂存区，或把 test 当作快速上线捷径，整条并行流水线就会在无声中退化成串行黑盒。
