独立游戏界最著名的技术特例彻底划上了句号。技术博主 Simon Willison 重新翻出了一桩开发史轶事：由 Tarn Adams 独力编写核心、以系统极度复杂著称的奇迹之作《矮人要塞》（Dwarf Fortress），已经结束了近二十年不使用任何源码版本控制系统的历史，正式将代码库接入了现代版本管理工具。
技术社区向来喜欢把这件事当作堂吉诃德终向现代软件工业低头的逸闻。但回到事实本身，这绝非一次自发的技术觉醒，而是一场由商业化成功、团队扩张倒逼出来的组织化妥协。从单人随性修改的本地文件，到被迫适应分支与合并，这家典型的古典手工作坊正在经历软件工程最基础也最真实的切肤阵痛。
告别单身时代：从千万级发售到第二位程序员入局
《矮人要塞》自 2002 年立项起，底层庞大的物理模拟与文明演化全凭 Adams 一人手工敲定。在长达二十年的时间里，Adams 长期依靠本地压缩包备份维系开发，把版本控制视为没有即时收益的黑盒。
早在 2013 年 3 月 23 日的 Reddit AMA 访谈中，Adams 就曾准确预言过打破这一习惯的前提条件：只有当自己需要和其他程序员一起工作时，版本控制才会产生意义。这一语成谶的设想，在九年后由于一场商业蜕变变成了现实。
2022 年 12 月 6 日，《矮人要塞》在 Steam 正式发售带有图形界面、全新交互与音效的付费版本。游戏发售迅速大卖，不仅让原本依赖社区零星捐赠的主创步入百万富翁行列，也带来了商业发行业务对持续更新与缺陷修复的硬性要求。仅凭一人之力敲代码、修漏洞的节奏被彻底打乱。
转折点随即在发售一个月内到来。2023 年 1 月 5 日，官方公告确认第二位程序员 Putnam 加入团队并直接参与缺陷修复。独奏变成了合奏，原本存放在个人硬盘里的代码再也无法靠直觉随意覆写，引入协作管理机制成了别无选择的现实路径。
工具并未消解复杂度：分支计划与合并冲突的真实恐惧
外部分析常带有一种理所当然的预设，认为开发者只要接通现代工具，研发流程就会自然顺畅。但事实恰恰相反，在 2023 年 3 月 14 日发表于 Game Developer 的专访中，Adams 直言日常工作中增加了密集的协作沟通与版本控制打理，开发流程明显变得更加繁琐复杂。
更重要的是，截至目前的官方公开材料，Adams 仅表示用上了版本控制工具，从未确认底层使用的是 Git 还是 Mercurial，更没有公开过任何标准化的拉取请求或代码审查规范。技术圈一厢情愿套用的现代工业工作流，在这座工坊里依然保留着相当原始的摸索特征。
真正的考验在于架构耦合。Adams 在同次专访中提到，团队计划在一个独立代码分支上推进底层的地图重写系统。这一决定立刻撞上了老派作坊的技术短板：Adams 坦言自己长期缺乏解决代码合并冲突的经验，对不同分支交织时如何处理冲突充满担忧。
二十年来，《矮人要塞》由一人按照完全个人的思维脉络编织而成，模块间咬合极深。当这样高度耦合的单体架构被强行切入多分支并行开发时，现代工具并未降低系统本身的混乱度，反而将隐性依赖赤裸地暴露在合并窗口面前。
引入现代工具并没有减少代码的纠缠，反而将二十年单体架构的耦合暴露无遗。
个人意志与工程规训的拉锯
软件工程界长久以来将无版本管理视作不可理喻的技术禁忌，把 Adams 的过往做法归为侥幸生存的反面教材。但这忽略了一个事实：《矮人要塞》之所以能构建出全球独一份的涌现式文明细节，恰恰源于开发者二十年间免受标准工作流约束、不受规范打扰的自由发挥。
现代工程规范保护的是协作下限，却往往削平个人艺术创作的锋芒。当《矮人要塞》跨过商业门槛、建立起持续服务玩家社区的商业契约时，作坊式的快意恩仇就必须让位给可追溯、可分工的工业规训。
对于后续的游戏演进而言，接纳版本控制并不意味着开发进度会立刻翻倍。玩家社区更应该观察的，是那项庞大的地图重写分支能否在保证底层逻辑不崩塌的前提下顺利合并进主干。这既是两名开发者磨合协作的试金石，也是这座古典代码巨构能否安度工业化改造的最大检验。
- 提醒.不要指望版本控制直接提升旧系统的重构速度，在缺乏模块解耦的前提下，跨分支合并的沟通成本反而可能拉长核心系统的交付周期。