《矮人要塞》放弃不用版本控制：20年开发史的转折

一个传奇的终结

《矮人要塞》（Dwarf Fortress）的开发者 Tarn Adams 终于开始使用版本控制了。对于熟悉这个项目的玩家来说，这条消息的意义远超一般的开发工具更新——它标志着一个长达二十年的传奇习惯画上了句号。

这个项目以其惊人的模拟深度著称，从地形生成到矮人的情绪波动，再到文明的历史演化，几乎所有系统都在一个庞大的代码库中交织运行。正因为如此，不用版本控制这件事才显得格外不可思议。

从 2013 到 2023：态度转变的完整轨迹

Tarn Adams 对版本控制的拒绝并非一时固执，而是一种有意识的选择。

“黑箱”顾虑

2013 年，他在 Reddit 的 IAmA 活动中直言：

“我不用版本控制——我不喜欢那种感觉：代码被提交进一个黑箱子里，却看不到即时的好处。”

这个表述很直白地道出了他的核心顾虑：版本控制对当时的他来说，收益不够直观。

“我就是不适合”

2016 年接受 PC Gamer 采访时，他的态度更像是一种自我认知：

“我甚至不用版本控制。如果你不知道那是什么，你就不会冲我嚷嚷。但如果你知道版本控制或源码管理是什么，你肯定会问，‘你不用版本控制？你到底哪里有问题？你怎么工作的？’我就是不适合那套东西。已经 15 年了，理由随着时间变过，但这就是我目前的理解。”

这段话里有一个容易被忽略的信息：他并非不了解版本控制的价值，而是长期认为自己无法融入那种工作方式。对一个单人主导、连续性极强的项目来说，这种判断未必完全没有道理——毕竟，没有合并冲突，没有分支管理，也没有团队协作的刚性需求。

合并冲突（merge conflict）是多人协作中版本控制最常被诟病的痛点：当两个人修改了同一文件的同一区域，系统无法自动决定保留哪一份，必须人工介入。此外还有分支管理、提交粒度、历史清理等需要纪律性的操作。对一个长期单人开发的项目来说，这些成本确实几乎不存在，Tarn Adams 所描述的“不适合”也部分源于此——他面对的是一套为团队协作设计的工具，而他的工作模式恰恰绕开了它最核心的用途。

转折出现在 2023 年

到 2023 年接受 Game Developer 采访时，他的说法已经变了：

“我现在要查 Discord 频道，还要用版本控制之类的东西，所以流程确实比以前复杂了一些。”

这句话出现在 Steam 版本发布的背景下。据 PC Gamer 报道，Steam 发行让开发者成为了百万富翁。Steam 版本带来的不只是收入，还有更复杂的发布流程、更频繁的更新节奏，以及更广泛的协作需求。

为什么这件事值得讨论

不用版本控制的代价

版本控制的核心价值在于可追溯性和可恢复性。对于一个像《矮人要塞》这样逻辑密度极高的项目，任何一次误删或回归错误都可能需要数小时甚至数天的人工排查。没有版本控制意味着：

• 无法回滚到任意历史版本
• 无法用 diff 对比修改前后的差异
• 无法通过分支安全地试验新功能
• 难以定位是哪次改动引入了 bug

Tarn Adams 能在这套约束下持续开发二十年，靠的是极强的记忆力和代码掌控力。这本身就是一种罕见的开发模式。

版本控制（Version Control）是一类用于追踪文件变更历史的系统，最常用的实现是 Git。它的基本单位是“提交”（commit），每次提交会为当前代码状态打一个可回溯的快照，并附带作者、时间与说明。开发者可以借此回滚到任意历史版本、比较两次修改的差异（diff）、在独立分支上试验新功能而不影响主线，并在多人协作时合并各自的改动。对于单人项目，它至少提供了两重保障：误删或被破坏的代码可以恢复，bug 可以被定位到某一次具体改动。正因如此，现代软件开发几乎默认把版本控制当作基础设施，而非可选项。

为什么最终改变

从外部看，Steam 发布是明确的催化剂。当项目从“一个人的长期实验”变成“有商业承诺和玩家期待的正式产品”，流程的可靠性就变得不可回避。Discord 社区管理、更频繁的补丁发布、潜在的协作需求——这些都在推动工作流走向规范化。

Tarn Adams 并没有公开说明具体是从哪一天开始用的版本控制，也没有透露用的是 Git 还是其他工具。但他在 2023 年的表述已经明确表明，版本控制已经成为他日常工作的一部分。

Steam 发布对《矮人要塞》而言不只是上架一个商店页面。它意味着付费用户、退款政策、更新日志、平台审核与期望管理，把项目从“持续更新的个人实验”推向“有商业承诺的产品”。这类转变会放大流程缺陷的代价：一次无法回滚的错误更新可能影响数十万付费玩家，而频繁补丁又要求快速定位回归问题。Discord 社区则进一步提高了沟通与协调的密度。这些因素叠加，使版本控制从“可有可无的个人偏好”变成“维持发布节奏的必需工具”。

对独立开发者的启示

《矮人要塞》的例子容易被误读为“不用版本控制也能成功”。更准确的解读是：它是在极端条件下靠个人能力撑过了二十年，而最终仍然转向了行业标准工具。

对于绝大多数开发者来说，版本控制的收益在项目早期就会显现。Tarn Adams 自己也承认，随着项目规模扩大和外部协作增加，不用版本控制的理由逐渐失效。

这个转变并不戏剧化，也没有伴随任何公开的“我错了”宣言。它只是在一个采访问题里被顺带提及，就像一件早就该发生的事终于发生了。对一个以固执和深度著称的项目来说，这种平淡本身或许就是最好的注脚。