Dwarf Fortress 这款游戏终于舍得用版本控制系统了

一个运行了二十多年、复杂度高到离谱的模拟游戏，在这么长的时间里竟然完全不用版本控制，这在现代软件工程看来简直是不可思议的。但 Dwarf Fortress 确实做到了，主创 Tarn Adams 之前在 2013 年和 2016 年的采访中都明确表示过自己不用版本控制，理由很直观：他不习惯把代码提交到一个像“黑盒”一样的东西里，觉得这样没有直接的收益。这种极其个人主义的开发方式在独立游戏史上非常罕见，尤其是面对一个需要处理海量实体模拟、地质构造和历史生成的庞大代码库时。
直到 2023 年 3 月，在准备 Steam 正式版发布相关的采访中，Tarn Adams 才提到他现在开始使用版本控制工具和 Discord 频道来处理开发流程，这意味着开发模式发生了质变。

为什么一个复杂项目在没有版本控制的情况下能撑 15 年

大多数开发者习惯的流程是：写代码 → commit → push → 遇到 Bug → git revert。但对于早期单人主导的 Dwarf Fortress 来说，这种机制可能反而成了负担。在没有版本控制的年代，Tarn Adams 实际上是在用一种极其原始但对他个人有效的“快照”方式管理代码。
这种模式在项目极早期是行得通的，因为代码逻辑全部在主创的大脑中，他不需要通过提交记录来回溯某个功能的变更点，因为他记得所有改动。但这种方式的风险在于，一旦出现难以察觉的回归 Bug，开发者必须在海量的源代码中手动寻找那个导致崩溃的字符，而不能通过 git bisect 快速定位。
在这种环境下，代码的稳定性完全依赖于开发者的记忆力和极其严苛的自测。当一个项目规模扩大到一定程度，且需要从一个人的业余爱好变成一个商业产品时，这种“单点依赖”的风险就变得无法承受。

从个人创作转向商业化后的流程重构

Dwarf Fortress 进入 Steam 之前，经历了一次极其痛苦的现代化改造。为了让游戏能够在 Steam 上顺利运行并提供更好的性能，Tarn Adams 必须对代码进行大规模的优化和升级。这时，版本控制就不再是一个“可选项”，而成了“生存项”。
在转向商业化过程中，版本控制解决了以下几个核心问题：

• 协同开发： 随着项目的规模增加，单纯靠一个人维护所有逻辑已经不现实。引入版本控制后，团队成员可以在不同的分支上并行开发新功能，而不会互相覆盖代码。
• 风险对冲： 在进行大规模重构（如优化 Steam 版的性能）时，如果没有版本控制，一次错误的全局替换可能会导致整个项目无法编译，且无法瞬间恢复。
• 发布节奏： 正式版需要经过严格的测试和版本迭代，通过标签（Tag）管理版本，才能确保分发给用户的是经过验证的稳定版，而不是某个随手保存的临时文件。

这种转变对开发者意味着什么

对于大多数习惯了 Git 或 SVN 的程序员来说，Tarn Adams 之前的做法像是一种“艺术般的蛮干”。但从另一个角度看，这证明了在逻辑自洽的情况下，工具并不是决定产品质量的唯一因素。
不过，当项目进入 2023 年这个节点，面对数百万潜在的 Steam 用户，原有的开发习惯必须失效。如果继续沿用那种“不提交到黑盒”的模式，在面对复杂的平台兼容性问题和大规模并发 Bug 时，开发效率会呈指数级下降。
现在他提到流程变得 "more involved"（更复杂了），这其实是一种自嘲。对于习惯了直接修改文件的开发者来说，处理 Merge Conflict（合并冲突）确实比直接覆盖文件要繁琐得多，但这种繁琐换来的是工业级的稳定性。

总结一个核心逻辑

如果一个项目的复杂度在增加，但开发团队规模保持在 1 人且对代码有绝对掌控力，那么版本控制的边际效用在初期确实较低。但一旦出现以下三个条件，版本控制将成为强制要求：

1. 引入了外部协作人员（如 Steam 版的优化团队）。
2. 目标平台从本地运行转向大规模商业分发。
3. 代码重构的频率高于新功能增加的频率。

Dwarf Fortress 的这次转变，本质上是从“个人手工艺品”向“商业软件产品”的进化。虽然失去了那种纯粹的、反常规的开发浪漫感，但对于玩家来说，这意味着更少的崩溃和更快的更新速度。