多分支并行开发的关键在于工作流设计、环境同步和分支生命周期管理；git worktree add 需注意钩子继承、编辑器配置复制和本地文件处理；feature 分支用 --no-ff 合并，release 分支须 --ff-only；hotfix 应 cherry-pick 到 develop 并规范提交信息。
多分支并行开发不是“能不能做”，而是“怎么避免互相污染、切换卡顿、配置错乱”。Git原生支持分支并行，但真实协作中，90%的问题不出在Git命令本身，而出在工作流设计、环境同步和分支生命周期管理上。
git worktree add 怎么用才不踩坑
直接 git worktree add <path><branch></branch></path> 很快，但容易漏掉三件事：新工作树没继承主仓库的 Git hooks、编辑器配置（如 .vscode/settings.json）不会自动复制、.env.local 这类本地配置文件可能被误提交或遗漏。
- 始终用绝对路径指定
<path></path>，避免相对路径在不同 shell 环境下解析出错 - 添加前先确认目标目录为空，
git worktree add不会覆盖已有文件，但会报错退出 - 如果需要复用主工作树的钩子，手动软链接：
ln -s ../.git/hooks <new-worktree>/.git/hooks</new-worktree> - 别依赖
git worktree list判断分支是否已存在——它只显示已注册的工作树，不校验分支是否存在
feature 分支 vs release 分支的合并策略差异
功能分支（feature/xxx）和发布分支（release/v1.2.0）面对的合并场景完全不同：前者强调历史可追溯性，后者强调可回滚性和部署确定性。
使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。
-
feature分支合入develop时，推荐git merge --no-ff：保留分支边界，方便后续用git log --first-parent快速过滤集成点 -
release分支合入main前，必须先git checkout main && git merge --ff-only release/v1.2.0：强制要求快进，否则说明main已被意外修改，需立即中止发布流程 - 禁止对
release分支执行git rebase：它会被打上 tag 并用于部署，变基会改变 commit hash，破坏部署一致性
如何防止 hotfix 分支污染 develop 的变更节奏
热修复（hotfix/xxx）必须同时修复 main 和 develop，但直接两次 merge 容易漏掉一次，或把 develop 上尚未合入的 feature 提前带进生产。
- 标准流程是：从
main切出hotfix/xxx→ 修复并测试 → 先git merge回main→ 再git cherry-pick <commit-hash></commit-hash>到develop，而不是 merge 整个分支 - cherry-pick 后立即在
develop上运行 CI 流水线，验证该补丁在开发环境中无副作用 - 所有 hotfix 的 commit message 必须以
[HOTFIX]开头，并关联 Jira ID，便于审计追踪 - 避免用
git merge hotfix/xxx直接进develop：这会把 hotfix 分支的整个历史（含 merge commit）拖进来，污染develop的线性演进
真正难的不是命令怎么写，而是每次切分支时，你能否一眼看出这个分支的上游是谁、有没有未推送的提交、是否已被其他同事基于它继续开发——这些信息藏在 git branch -vva 和 git log --oneline --decorate --simplify-by-decoration 里，但没人会天天手动敲。建议把它们封装成 alias，比如 git alias ll 'log --oneline --decorate --simplify-by-decoration'，不然再好的分支策略也撑不过两周。
