准确说，不是GitHub专门“保留版本”，而是Git本身的机制就会记录每一次提交的完整历史；只要你把代码推送到了GitHub，远程仓库就会同步保存完整的提交链，所有历史版本都会永久留存。
本地仓库和GitHub远程仓库是对等的，都保存了完整的版本历史——哪怕断网，你在本地也能随意回滚到任意历史版本。
一、Git版本的本质：每一次提交都是一个永久存档
Git的版本管理核心是「提交（commit）」，这是所有回滚操作的基础：
- 每执行一次
git commit，Git就会生成一个全局唯一的哈希ID（类似a1b2c3d），对应这一时刻整个项目的完整代码快照。 - 所有提交按时间顺序串成一条链，前一个提交是后一个的父节点，形成完整、不可篡改的版本历史。
- 我们常说的
main分支，本质只是一个可移动的指针，默认永远指向最新的一次提交。
所谓“版本回滚”，本质就是把 main 这个指针，从最新的提交，移动到之前任意一个旧提交上。
二、本地和GitHub的历史是完全同步的
Git是分布式版本控制系统，本地和远程的历史记录是对等的：
- 你本地的仓库里，默认就有完整的提交历史链，离线状态也能自由查看、回退任意版本。
- 执行
git push把代码推送到GitHub时，会把本地的所有提交记录同步到远程仓库，GitHub上就有了和本地完全一致的全部版本。 - 反过来，新同事执行
git clone下载项目时，会把所有历史版本一起下载到本地，而不是只下载最新的代码。
简单说：只要推送到了GitHub，哪怕本地电脑硬盘损坏，重新克隆仓库，所有历史版本也能完整恢复。
三、在GitHub上直观查看历史版本
你可以直接在GitHub网页上浏览所有历史：
- 进入仓库 → 点击
X commits（提交次数），就能看到main分支从第一个版本到最新的所有提交记录，按时间倒序排列。 - 点击任意一次提交，就能查看这次修改了哪些文件、具体的代码差异。
- 你可以直接浏览任意历史版本的完整代码，也可以下载对应版本的压缩包。
四、回滚远程main分支的两种方式（重点）
本地回滚非常自由，但多人共用的远程main分支，不建议随便用强制覆盖的方式回滚。结合你们两人协作的场景，推荐两种方案：
1. 方案A：git revert（公共分支首选，最安全）
原理：不删除任何历史提交，而是新建一次提交，把之前的修改反向撤销回去。
- 优点：完全不改写历史，所有人的代码都能正常拉取，不会出现版本混乱；出问题也可以再 revert 回来，全程可追溯。
- 适用场景：
main/master公共主分支、线上代码回滚、多人协作的分支。 - 操作示例（回滚最近一次提交）：
git revert HEAD
git push origin main
推送后，线上执行 git pull 就能同步回滚后的代码，全程安全可控。
2. 方案B：git reset --hard（仅适合本地/私有分支）
原理：直接把分支指针移动到目标提交，指针之后的提交记录会被“抹掉”。
- 注意：如果对应提交已经推送到远程，回滚后必须用
git push -f强制推送覆盖远程，否则会报错。 - 风险：多人协作时，如果其他人已经拉取了被抹掉的提交，再次推送会把历史又带回来，造成版本混乱和代码丢失。
- 适用场景：自己本地的私有分支、还没推送到远程的提交、只有你一个人使用的分支。
五、补充：历史版本会不会丢失？
正常操作下，提交记录是永久保存的：
- 只要不执行
git reset --hard强制删除、不手动深度清理历史，所有版本都会一直保留。 - GitHub不会自动删除你的提交历史，哪怕是几年前的版本，随时都能回溯。
- 最佳实践：公共主分支永远用
revert回滚，不要用reset -f强制覆盖，最大限度避免历史丢失和协作冲突。