同步上游分支
让本地与自己的分支跟上上游仓库：先拉取上游，再把本地主干快进到上游主干，然后同步到自己的远端，最后把工作分支对齐到上游基线。这是一套固定顺序的动作，照着做最省事。
基本信息
| 频率 | 每次开工前与提交评审前各做一次 |
|---|---|
| 顺序 | 拉取上游、更新本地主干、同步自己的远端、更新工作分支 |
| 更新方式 | 主干用快进更新，工作分支对齐上游基线 |
| 收益 | 冲突尽早暴露，评审差异干净 |
| 注意 | 对齐后提交哈希会变化，已推送的分支需要按规则更新 |
典型使用场景
- 向开源项目提交补丁前先对齐上游
- 贡献分支落后上游较多时先同步
- 评审前减少与本次改动无关的差异
- 长期维护的分支需要定期跟进上游
- 排查「上游已修复但本地仍有问题」的情况
常用示例
常用示例
git fetch upstream # 拉取上游最新状态
git switch main # 切到本地主干
git merge --ff-only upstream/main # 快进更新，避免多余合并提交
git push origin main # 同步到自己远端的主干
git switch feature/x && git rebase upstream/main # 工作分支对齐上游基线
git log --oneline -3 # 确认基线已更新步骤与目的
| 步骤 | 目的 |
|---|---|
| 拉取上游 | 拿到最新基线与标签 |
| 更新主干 | 让本地主干与上游一致 |
| 同步自己的远端 | 让评审看到正确的基线 |
| 更新工作分支 | 减少与上游无关的差异 |
把同步做成例行动作，比在评审当天临时处理大规模冲突轻松得多。
主干用快进更新可以避免产生无意义的合并提交，历史看起来更干净。
对齐后提交哈希会变化，已推送的分支需要按规则重新推送，并提前告知协作方。
同步前确认本地没有未保存的改动，避免操作中途被打断留下一半状态。