这篇笔记记录如何使用 VS Code 的 Git Graph 扩展，把当前分支回退到某个历史提交，并在需要时将回退后的状态同步到远端仓库。
先分清：回退本地，还是也要改远端
Git 的提交历史可以理解为一条不断向前延伸的链。Reset 会把当前分支指针移回较早的提交；如果较新的提交已经推送到 GitHub 等远端，远端仍然保留着较新的历史。此时要让远端也回退，就需要改写远端分支历史。
- 如果后续提交只存在于本地、还没推送，回退通常只影响本地分支。
- 如果后续提交已经推送，而自己确实要让远端也回到旧版本，则通常需要带保护检查的强制推送。
- 如果分支由多人共同使用，不要擅自改写远端历史；优先用 Revert 新增一个反向提交。
回退前先做检查
- 在 VS Code 打开 Git Graph：点击 Git Graph 视图，或在命令面板执行
Git Graph: View Git Graph。 - 看清当前检出的本地分支。后续 Reset 作用于当前分支，操作前确认分支名没有选错。
- 找到希望回到的目标提交，检查提交说明和时间，确认它确实是想恢复的版本。
- 如果不确定是否还会需要当前进度，可以先从当前提交创建一个备份分支。
- 确认没有尚未保存、又想保留的工作区修改。Hard Reset 会覆盖工作区文件。
在 Git Graph 中回退
- 在目标提交上右键。
- 选择 Reset current branch to this commit…（将当前分支重置到此提交）。
- 根据是否保留目标提交之后的本地修改，选择 Reset 模式：
| 模式 | 分支指针 | 暂存区与工作区 | 适用情况 |
|---|---|---|---|
| Soft | 移到目标提交 | 后续改动保留在暂存区 | 想撤回提交、但保留改动并准备重新提交 |
| Mixed | 移到目标提交 | 后续改动保留在工作区，未暂存 | 想撤回提交并继续整理文件；通常是默认选项 |
| Hard | 移到目标提交 | 暂存区和工作区都恢复为目标提交状态 | 想让本地文件完全回到旧版本 |
Hard 会丢弃目标提交之后尚未另行保存的本地改动。确认选择后，再检查 Git Graph 中当前分支标签是否指向目标提交，并检查项目文件是否符合预期。
把回退结果同步到远端
如果远端本来没有那些较新的提交，普通推送可能就够了；如果远端已经包含 Reset 之前的提交，普通 Push 通常会因为不是快进更新而被拒绝。
- 在 Git Graph 中先点 Fetch，刷新远端分支信息。
- 右键当前检出的本地分支标签，例如
main，选择 Push Branch…。 - 选择远端（通常是
origin）和对应的同名分支，先尝试普通推送。 - 如果提示
non-fast-forward，并且确认远端也应该回到当前旧提交，在推送对话框选择 Force With Lease 再确认。
Force With Lease 会在更新远端前检查远端分支是否仍处于已知状态。如果 Fetch 之后远端又有新提交，它会拒绝推送，避免不知情地覆盖新工作。不要把它和不带检查的 Force Push 混淆。
强制推送成功后，远端分支会指向当前本地提交，回退范围内的远端提交不再位于这条分支的历史上。其他协作者可能需要重新同步分支，因此只对自己管理、确认可以改写的分支这样做。
什么时候用 Revert
Reset 是移动分支指针、改写历史；Revert 则会创建一个新提交，用相反的改动抵消某个旧提交，不会删除已有历史。
- 自己的个人分支，想让本地和远端都回到一个旧状态：可以 Reset；若远端已有后续提交，同步时谨慎使用 Force With Lease。
- 共享分支或不确定其他人是否基于这些提交继续开发：优先 Revert，再普通推送。