两兄弟接连两次丢数据，只有一个人拿了回来。美术丢掉了全部模型与贴图，只能从头重做；程序员整台机器报废，却一行代码都没丢，因为他在别处留了冗余的 Git 副本。同一个团队、同一场灾难，结局完全相反。差别不是运气，而是第二份拷贝放在哪里。
快速信息
来源：Hypercane Studios 的复盘 Rage Runner Postmortem，2014年1月29日发表于 Game Developer。本文关于该团队的事实均出自这篇复盘。
游戏：Rage Runner，OUYA 上的快节奏 3D 躲避障碍游戏，2013年3月28日发售，用 ShiVa 3D 开发约六个月，团队是两兄弟。
对这个故事简单版本的纠正：这不是一次丢盘被 Git 救回，而是接连两次事故。美术的文件永远丢了，只有程序员的代码是经 Git 拿回来的。
本文不声称的内容：不写两次事故的具体日期、不写 Git 托管方或推送频率、不写姓氏，也不声称美术资产进了 Git。复盘里都没有这些。
最后核实：2026年10月31日。
先丢一切的是美术
Jacob 负责美术、建模、贴图、关卡设计与市场，Zach 负责程序与关卡设计。他们的第一个主要作品，是让玩家以最快速度冲过数英里手工沟槽、躲避障碍的游戏，关卡不是程序生成的，也不给玩家提示。Jacob 一直在为 3D Max 的卡顿问题头疼，程序卡死后，他重新打开，飞船模型却加载不出来。用他自己的话说，这次崩溃抹掉了他全部项目文件、全部模型、全部贴图，一切都没了。反删除工具只找回了一点零星数据，大部分丢失的东西永远没了。
他差点放弃。最后他做了第三次、也是最后一次飞船、沟槽与障碍物的重建与重贴图，而这一次他懂得更多。他说 2 万面作为游戏资产是荒唐的，飞船的新目标是 5 千面以下，他达到了，沟槽则降到了 500 面以下。他写道，丢掉资产可能是发生在他身上最好的事，因为重做后的游戏看起来更好。这确实是一种恢复，但要看清它的性质：这是靠重做来恢复，不是靠还原来恢复。时间是重新花掉的，只是技术更好了，原文件再也没有回来。
接着程序员的机器报废，却什么都没丢
在 Jacob 的硬盘损坏后不久，按 Zach 对事件的概括，Zach 的 RAID 阵列也坏了，毁掉了他全部数据。他坦率地写，如果整个项目都丢了，他大概也就放弃了。结果，他那份过分谨慎的最坏情况备份计划起了作用：他拿起一份冗余的 Git 仓库副本，就能继续干活，一行代码都没丢。请仔细读这句话：保住的是代码，不是整个项目，关键词是冗余，也就是多份副本，而不是死掉那台机器上的单个仓库。复盘没有写 Git 托管方、推送频率，也没写未提交的工作是否还在，所以本文都不声称。
Zach 的恢复还附带第二个自己造成的麻烦，值得留下来，因为它说明备份救不了什么。在重装机器时，他装了一个 Windows 8 开发者预览版。大约一个月后预览版过期，机器每两小时强制重启一次，于是他定了一个 1 小时 50 分钟的闹钟，在每次强制重启前保存，就这样撑了整整一个月。他之所以这么做，是因为重新配置开发环境——Android SDK 与 NDK、32 位与 64 位 JDK、环境变量与构建脚本——要花整整一到两天的生产力。Git 救了他的代码，却没有救他的工作机器，而一次草率的重装选择让他付出了一个月的闹钟代价。
能复用的部分
下面的步骤不是 Hypercane 团队做过的事，复盘里没有备份清单，所以它们是改写给你自己项目的通用做法，全部只停留在你自己的项目里。教训不是 Git 有魔法：只存在于死掉那台机器上的仓库不是备份，而只覆盖代码的备份也覆盖不了美术，这正是两兄弟结局相反的原因。你的检验很简单：如果你的机器今晚报废，你自己项目里哪些部分能从别处拿回来，哪些只能像 Jacob 的飞船那样重做？
周一早上照着做
给你自己的项目列一张清单：哪些东西只存在于一台机器上——代码、美术源文件、贴图、关卡文件、构建设置。清单上的任何一项都属于 Jacob 那一堆，不是 Zach 那一堆。
把你自己代码的第二份副本放到工作机器以外的地方，并实测能否在另一台机器上克隆出来。从没恢复过的副本只是愿望，不是备份。
也给你自己的美术与关卡源文件找第二个家，和代码分开。不要因为代码有备份，就默认它们也有。
把你自己的环境重建笔记写下来：SDK、工具版本、环境变量、构建脚本。Zach 那一个月的闹钟，就是凭记忆重建要付的代价。
绝不要在你唯一的工作机器上，用预览版或会过期的系统来重建死掉的机器。让你的恢复路线保持无聊、稳定、经过测试。
在你自己的项目里经历任何一次数据惊吓后，先记下实际丢了什么、实际拿回了什么，再让记忆把一次部分恢复美化成全部恢复。