Git 日常回退：保住工作，再修正历史

先建立独立练习仓库，包含一份说明文本和一张无关紧要的测试图片，提交初始版本。不要拿正式游戏的未提交工作当练习材料。本课命令需要在你确认过的练习仓库根目录运行，文件名可按自己的练习调整。每次准备回退，先回答三个问题：改动是否提交、是否推送共享、有没有尚未保存到历史的劳动。

在终端先运行 git status --short、git diff、git diff --cached。它们分别帮助你看状态、工作区差异和暂存差异。看到陌生路径就先停下来核对目录；不要把 reset --hard 或 clean -fd 当作万能“修复”。

修改测试文本，使用 git add -- practice.txt 暂存，然后执行 git restore --staged -- practice.txt。再看文件内容与状态：文字修改应仍留在工作区，只是退出了待提交清单。取消暂存不等于撤销编辑，这正是新手最需要亲眼确认的区别。

接着只在这份可丢弃的练习文本上测试 git restore -- practice.txt。它会用默认来源恢复工作区文件，覆盖相应的未暂存修改；如果这些修改没有其他副本，Git 不保证能帮你找回。执行前先看 diff，需要保留就先复制到明确的备份位置或提交一个练习快照。

在练习仓库做一个“把提示写错”的普通提交，记下实际提交编号。保持工作区干净后，用 git revert 提交编号 创建一个反向提交，再查看日志和文本。这里的“提交编号”必须替换成你从日志选出的值，不是让你原样输入四个汉字。revert 保留原来的事件经过，让协作者知道发生过修正。

若发生冲突，不要直接选择所有“我的”或所有“对方的”。先读冲突区域，弄清双方意图，修正后暂存并运行 git revert --continue；若决定放弃本次撤销，可用 git revert --abort 回到操作前。合并提交的撤销有额外语义，不作为本课首次练习对象。

让两位协作者各自修改同一张 PNG 的不同位置，看起来互不重叠，也不意味着 Git 能自动组合像素。Krita 源稿、音频和很多二进制格式同样不能依靠普通逐行合并。正确交接是先约定文件所有者和时间段，另一位改别的文件；需要并行时拆成有明确来源的独立资源，再由指定整合者合成。

Git LFS 解决大文件对象的存储传输方式，不会把二进制变得易合并。锁功能还依赖远程服务支持和团队遵守；不能声称配置 LFS 后自动实现强制单写。源稿与导出图应一起说明对应关系，避免新 PNG 搭配旧 KRA，或者只交一个 LFS 指针却没有真正上传对象。

开始工作前查看状态、同步已确认的上游变化，再认领本次文件；修改后检查 diff，只暂存本次需要提交的文件，写清“改变什么以及为什么”。提交后若团队需要共享，再推送，并检查 LFS 对象上传是否成功。提交到本机并不等于其他人已经拿到。

收到美术交接时，在另一份干净练习克隆中取回资源，确认图片能实际打开、Godot 能导入、场景引用仍存在。若只看到很小的文本指针，检查 LFS 安装和拉取结果，而不是把指针重命名为图片。不要为一次取回失败立刻执行全仓库历史迁移；历史重写应有独立范围与协作安排。

给自己三张情境卡：“不想把某文件放进这次提交”“试坏的未提交修改确定不要了”“已经共享的某个提交需要撤销”。分别选取消暂存、恢复工作区、revert，并先说清会保留什么、覆盖什么、是否改变历史。解释不出来时不要靠试命令猜。

最后写一份五行交接说明：提交编号、已改文件、验证结果、当前已知问题、下一位接手者。二进制协作再补谁负责源稿、谁负责导出。Git 是可追踪的工作记录，不替代外部备份，也不自动替你保存未提交劳动；真正可靠的日常流程是小步提交、明确所有权和一次干净取回验证。