单分支开发适合2–3人小团队、无灰度环境、日更或小时级发布的场景，如内部工具或saas前端；一旦并行开发超两个功能或需选择性回滚，便易引发冲突、无法原子回滚及发布标记失焦等问题。
单分支开发：main 上直接提交，适合谁？
单分支策略本质是“不设分支”，所有开发、修复、测试都压在 main（或 master）上。它不是偷懒，而是对协作规模和发布节奏的主动选择。
适用场景非常具体：2–3人小团队、无灰度/预发环境、日更或小时级发布（如内部工具、SaaS 前端）。一旦团队开始并行开发两个以上功能，或者需要回滚某次上线而不影响其他改动，单分支就会迅速暴露问题——比如你刚合入一个登录优化，紧接着有人提交了支付接口重构，两者同时上线后出问题，你根本分不清是哪个改坏的。
常见错误现象包括：
- 冲突频发：多人频繁
git pull后git push，容易因未及时拉取最新而触发非必要冲突 - 无法原子回滚：
git revert某个 commit 可能误撤掉他人同期提交的无关改动 - 发布标记失焦：打
v1.2.0标签时，实际包含“登录优化”+“404 页面改版”+“日志埋点新增”，但你想只回退其中一项？做不到
多分支合并：merge 与 rebase 的真实分工
多分支不是为了“看起来专业”，而是为了解耦开发节奏与发布节奏。关键不在“有没有分支”，而在“怎么合并”。git merge 和 git rebase 解决的是完全不同的问题。
git merge 是协作事实的记录者。它保留两个分支各自的完整历史，生成一个带两个父提交的 merge commit。这让你能回答：“这个功能是在哪天、基于哪个基线、和哪些其他改动一起上的？” 对审计、排查、回溯至关重要。但代价是历史图谱变复杂，尤其当频繁合并短生命周期分支时，git log --oneline 会出现大量重复的 “Merge branch 'feature/xxx'”。
git rebase 是本地历史的整理者。它把你的功能分支提交“重放”到目标分支最新位置，生成全新哈希的提交，形成线性历史。但它只应在 私有分支 上使用——一旦推送过，再 rebase 就必须 git push -f，会破坏他人本地历史。团队共用的 main 或 dev 分支上禁止 rebase。
使用 gh project CLI 管理 GitHub Projects v2。在代理需要列出待办事项、设置项目字段（如状态、迭代、优先级等）时使用此技能。
典型误用：
- 在已推送的
feature/login分支上执行git rebase main后强制推送，导致同事git pull失败或丢失本地修改 - 用
rebase替代merge合并到main，结果线上 bug 无法快速定位是哪个原始提交引入的（因为原始 commit ID 已失效） - 在 CI 流水线中对
main执行rebase，导致构建缓存错乱、部署包不可复现
Squash Merge：不是简化，是抽象
git merge --squash 不是“省事的 merge”，而是一种明确的抽象层设计：把一次功能交付的所有中间过程（调试、重构、补丁）压缩为一个语义清晰的交付单元。
它生成的提交没有父提交指向原分支，也不保留原分支历史。这意味着你失去了“这个功能是分几次完成的”这一维度信息，但换来了主干历史的可读性。适合用于 GitHub/GitLab PR 合并场景——评审者看到的是最终效果，而不是开发者本地的试错过程。
注意三个硬约束：
- 必须手动
git commit，--squash不会自动提交；忘记这步会导致工作区残留未提交变更 - 无法用
git bisect精确定位 bug 引入点，因为中间状态被丢弃了 - 如果后续需 cherry-pick 其中某次中间修改，只能靠代码 diff 人工还原，无法直接引用原 commit
选哪种？看发布流程是否允许“后悔”
单分支适合“改完就发、发完就跑、错了立刻修”的闭环场景；多分支适合“功能隔离、分批验证、按需上线”的受控场景。真正决定策略的，不是 Git 本身的能力，而是你们的发布流程能否容忍“上线后发现要回滚其中一部分，且不影响其余部分”。
最容易被忽略的一点是：分支策略一旦选定，切换成本极高。单分支团队想升级为 Git Flow，不是加几个分支命令就行，而是要重建 CI 触发逻辑、PR 评审机制、标签管理规范，甚至重构发布脚本。反过来，重度依赖 rebase 整理历史的团队，若突然要求审计合规，会发现所有 commit 时间戳和作者信息都与原始开发行为脱钩。
