分支同步策略是什么
本地分支与主线同步有两种口径：rebase 把个人分支重放到最新主线之上，历史线性、评审 diff 干净；merge 把主线并入分支，保留真实时间线、无需强推。口径要统一并写进贡献指南，否则评审前才来回扯皮，同步动作反复做。
基本信息
| rebase 同步 | 线性历史；已推送的分支需要 --force-with-lease |
|---|---|
| merge 同步 | 保留时间线；无强推需求 |
| 常见折中 | 共享分支用 merge，个人分支用 rebase |
| 默认行为 | git config pull.rebase 决定 git pull 用什么方式，团队可统一设置 |
| 安全前提 | 强推前确认无人基于该分支继续工作，并先 fetch 检查远端新提交 |
典型使用场景
- 评审前同步：个人分支 rebase 到最新主线，diff 只含自己的改动。
- 多人共享开发分支：用 merge 保留彼此提交，避免改写他人历史。
- 长期分支：定期 merge 主线，降低最终大合并的冲突量。
- 流水线校验：检查分支落后主线太多时提醒同步。
- 新人指导：把口径写进 CONTRIBUTING，减少评审中的临时要求。
- 历史重写影响评估：确认开放中的 PR 都基于新历史后再通知继续。
两种写法
两种写法
git fetch origin
git rebase origin/main # 线性：个人分支常用
git merge origin/main # 保留时间线：共享分支常用
git log --oneline --graph -8
git config pull.rebase false # git pull 缺省走 merge
git push --force-with-lease # rebase 已推送分支后，用 lease 保底两种口径对比
| 维度 | rebase | merge |
|---|---|---|
| 历史形态 | 线性 | 保留分叉与合并点 |
| 评审体验 | diff 干净 | 能看到同步过程 |
| 失败恢复 | 靠 reflog/ORIG_HEAD | 无改写风险 |
| 推送要求 | 需强推 | 正常推送即可 |
把口径写进贡献指南（CONTRIBUTING），评审前的同步动作就不会反复拉扯。口径混用会让同一分支出现两种历史形态，评审者难以判断真实改动范围。冲突少时 rebase 一步到位；冲突多或多人共写文件时 merge 更稳妥——先把冲突完整解决一次，再考虑历史形态。