怎样用 Git 保存进度、与别人协作并安全撤销修改？
区分文件修改、本地提交和远端同步，先检查差异，再选择适合当前状态的撤销方法。
本页目录
直接回答
Git 用提交记录项目变化，GitHub 等平台负责托管和协作。保存文件不等于提交，提交到本地也不等于已经上传。一次改一件事、改完测试、回滚前先看差异，这三个习惯比记住所有命令更重要。撤销必须先判断改动是否提交、是否已经共享，以及是否混有别人的未提交工作。官方文档说明 revert 会用新的提交反向撤销已有提交；它与丢弃未提交内容、重写分支历史不是同一件事。
适用场景
- AI 改坏了功能，想回到之前的可用状态
- 换电脑、多人或多个 Agent 协作
- 推送被拒绝，或出现合并冲突
一步一步做
先识别仓库当前状态
查看当前目录、分支、远端地址和工作区差异。分清已有用户改动与本次任务修改。提交前检查文件列表，避免把密钥、构建产物、临时截图和无关文件一起上传；忽略文件也要确认此前是否已经被跟踪。
做一个有意义的提交
围绕一个可以解释的结果修改和验证，逐文件看 diff 后选择要提交的内容。提交说明描述改变了什么行为。练习可以只改标题颜色，真实项目则可能是修复上传失败或增加历史记录，而不是把所有未完成工作混成“更新”。
同步前确认远端变化
提交在本地形成记录，push 才将提交传到远端。多人协作时先了解远端新增了什么，再按项目约定整合。遇到推送拒绝不要直接强推，先判断是分支落后、权限问题还是远端配置不正确。
按冲突的业务含义合并
冲突说明两份修改影响了同一位置，不代表随便保留一边就正确。阅读双方目的、关联调用和数据结构，再形成符合当前需求的结果。解决文本标记后继续检查功能，编译成功不能证明没有丢掉另一边逻辑。
选择撤销范围并复验
整理建议：先保全当前工作，再明确要撤销哪个文件或提交。已经共享的普通提交通常可评估 revert；合并提交及依赖它的后续变更要单独分析。代码回退不会自动恢复数据库或外部服务状态，涉及迁移时需要对应恢复方案。
用一次小改动走完分支到合并
先区分词义：Git 管本地版本；GitHub 托管仓库；clone 是本地副本，fork 是平台上的独立仓库副本；branch 隔离一条修改线；PR 是审查和合并请求。练习时从干净的已知基线建分支，只改一段文案，检查 diff、运行相关验证，再提交。需要协作时推送该分支并核对 PR 的目标分支和完整差异；按项目流程审查合并。commit、push 和上线是不同事件，自动部署也取决于分支配置。
按双方意图解决冲突
遇到冲突先保留当前工作并读清两边修改目的，判断是内容冲突还是行为冲突。编辑成同时满足必要意图的最终内容，清掉冲突标记，再运行受影响流程和检查；不能只点“全部采用我的”就算解决。无法确定的业务选择留成明确问题，其他不受影响的工作可继续；不要用强推消除提示。
案例拆解
假设练习：撤销文案修改而保留修复
假设你先修改标题颜色，再查看差异、提交、推送，后来需要撤销这次改色。如果其后又修好了上传功能，只想撤销标题颜色，就应定位那次颜色修改，避免把整个项目倒退到上传修复之前。若颜色修改与大量无关变化混在同一个提交，撤销就更难，这正是小而完整提交的价值。
另一个假设情形是你改按钮文案，另一分支修了该按钮的 disabled 条件。合并后应同时保留新文案和禁用条件。仅保留自己的整段组件会丢掉故障修复，因此除了没有冲突标记，还要实际测试“提交中不能重复点击”。
行动检查
可复制模板
安全撤销前的分析请求
工作模板
我要撤销［行为或提交］，并保留［必须保留的内容］。
先只读检查当前分支、未提交改动、目标提交和后续依赖。不要自动 reset、删除文件或强推。
请说明哪些文件和行为会变化，是否涉及数据库或外部状态，并提出最小恢复方案与验证步骤。确认范围后按已有授权执行，不能覆盖无关改动。
第一次 Git 协作练习
练习仓库与基线提交：
当前分支／是否有未提交改动：
新分支：［如 practice/button-copy，以项目规则为准］
本次仅修改：
提交前差异与验证：
提交说明：［为什么改、用户看到什么变化］
是否需要推送／目标远程与分支：
PR 的 base／compare：
冲突记录：文件｜双方意图｜合并后行为｜验证结果
合并后的提交与实际页面：
恢复方法：［新提交反向修复或项目认可方式］
可先用 git status、git diff、git log --oneline -5 只读观察；具体写入与推送按当前仓库流程执行。
易错点
- 看见 push 失败就强推：可能覆盖协作伙伴的历史。
- 把代码托管当成数据库备份：用户数据通常不在 Git 里。
- 把清理密钥历史当成泄露处理完成：已经暴露的凭据首先要吊销或轮换。
相关指南
官方参考
-
Git：git-revert — 说明 revert 通过新增提交撤销既有变化，区别于丢弃工作区内容。 资料核查记录日期：2026-10-18。
-
GitHub：GitHub flow — 说明分支、提交、PR 审查和合并的基本流程。 资料核查记录日期：2026-10-18。