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 依赖的公共逻辑。

Github Actions Linter

对 GitHub Actions 工作流 YAML 文件进行 lint 与验证，检查常见错误、安全隐患、已废弃的操作以及最佳实践。适用于要求进行代码检查、验证等场景。

下载

正确做法是用 git cherry-pick 构建最小化交付集，而不是靠分支删除或重置来“清理”：

• 从 feature/B 创建临时分支 release/b-urgent
• git cherry-pick 所有 B 的提交（注意跳过 merge 提交和调试 commit）
• 手动补丁修复 B 依赖但尚未合入 master 的公共模块（如 utils 函数），确保不引入 A 的副作用
• 将 release/b-urgent 推送至 test，而非直接 push feature/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></hotfix-commit>，而非强制同步
• CI 流水线需识别 hotfix/ 分支的推送，自动触发对所有 open feature/* PR 的兼容性检查（比如运行受影响模块的单元测试）
• 禁止在 hotfix 中混入非修复逻辑（如“顺手优化了按钮样式”），否则会污染语义边界

分支演进路线最易被忽略的点，不是命令怎么写，而是每个分支的“责任契约”有没有被所有人理解并遵守。一旦有人把 develop 当成个人暂存区，或把 test 当作快速上线捷径，整条并行流水线就会在无声中退化成串行黑盒。