先看证据
复杂项目也可能觉得版本控制没有即时收益
Simon Willison 在 2026 年 10 月 11 日的一篇博客中回顾了《矮人要塞》开发者 Tarn Adams 对版本控制态度的变化：Adams 早年长期不用，到了 2023 年则说自己已经开始使用。这个变化值得技术负责人读，不是因为它证明某种工具终于适用于一款复杂游戏，而是因为它揭示了工具何时变得有用，往往取决于工作方式，而不只是代码规模。
2013 年，Adams 解释自己不使用版本控制，是因为不喜欢代码被提交进一个“黑箱”，而且看不到直接好处。2016 年他仍公开表示不用，并说这种状态已经持续约 15 年。这个年数是当时的自我描述，不是精确的采用起点，但足以说明这不是一时疏忽，而是一种长期维持的工作习惯。
从常见的软件工程经验看，版本控制能留下变化记录，也能让不同改动分开管理，因此《矮人要塞》这样长期演进的项目似乎格外适合它。但 Adams 的说法显示，功能上的适配并不等于个人会立即感受到收益。如果主要开发者觉得自己仍能直接掌握代码变化，那么提交和协作约定带来的流程感，可能比抽象的可追溯性更显眼。理解这一点，不是替长期不用版本控制背书，而是提醒团队：工具的收益要落在具体工作里，才会成为实际收益。
转折来自流程，不是某个明确的迁移时刻
到 2023 年 3 月，Adams 在谈《矮人要塞》Steam 版发布的采访中说，自己现在既要查看 Discord 频道，也要使用版本控制，开发过程因此“复杂了一点”。这句话提供了清晰的时间边界：采访时已经采用，但公开资料没有交代确切开始日期，也没有说明从旧做法迁移到新做法的步骤。另一份访谈转录提到他大约在“3 个月前”开始使用，不过原始录制日期不清楚，不能据此换算出具体月份。
采访还提到，参与者增多，Kitfox 的协作也进入日常开发。但现有材料没有证明其中任何一个因素单独促成了版本控制的采用，更不能把这段变化写成 Steam 发布直接带来的技术升级。谨慎的读法是，Adams 描述的工作已经包含更多沟通和协调，版本控制也出现在这个更复杂的流程里。相关背景能说明变化发生在协作扩大的时期，却不足以还原唯一的因果链。
这也解释了为什么 Adams 把变化描述成流程“复杂了一点”，而不是把版本控制说成无需代价的改进。对个人开发者而言，额外的提交步骤或规则可能只是摩擦。多人参与时，同一套记录和协调机制则可能帮助大家处理共同变化。关键不在于给流程贴上“简单”或“先进”的标签，而在于比较新增的协调成本，是否换来了团队确实需要的共同工作能力。
分支能让工作并行，却不会替团队解决整合
Adams 谈到过版本控制可能支持的一种安排：为大型地图重写开一个分支，同时继续修补旧版本，或者开展其他较大的功能工作。分支在这里的作用，是让一条新工作线与正在维护的版本暂时分开，而不是自动完成重写，也不是保证两边的改动日后能轻松合并。它解决的是工作可以如何并行，而非并行本身的全部难题。
这个区别对技术负责人很实际。若旧版本必须继续维护，而重写又不适合等到维护工作全部停下才开始，分支就提供了一个组织变化的手段。但分开工作越久，双方需要协调的变化也可能越多。版本控制保存和隔离这些变化，却不会替开发者判断哪些修改可以共存、哪些需要重新设计。
Adams 预期大型分支会带来“相当严重”的合并冲突，也坦言自己处理这类情况的经验不多。这不是一个已经顺利合并的成功案例，而是他对计划代价的明确判断。对团队来说，开分支的决策应该同时考虑谁来整合、如何处理冲突，以及维护旧路径会持续多久。若没有这些安排，分支只是把冲突推迟到以后，并不等于风险已经被管理。
别把版本控制的作用误读成维护两套游戏
《矮人要塞》的经典版和图形版并不是两套独立代码库。采访材料说明，两者共享底层网格结构，经典版与图形版的区别主要通过替换显示字形实现。因此，把版本控制的引入解释为团队需要同时维护两套游戏代码，并没有材料支持。更有根据的理解，是版本控制为重写、旧版修补和其他功能工作提供了并行管理的可能。
同样需要克制的是对工具细节的推断。公开资料只说 Adams 使用了版本控制，没有说明具体工具、仓库托管平台、分支策略或提交评审方式，也没有交代所有代码和资源是否都纳入同一套管理。现有信息甚至不足以把它具体称作 Git。对技术读者来说，这些空白不是可以用行业惯例补齐的细节，而是判断这项实践时必须保留的边界。
这个案例能支持的判断更有限，也更实用：当长期由核心开发者掌控的项目开始需要多人协作，或者旧版本维护与新方向开发必须同时推进，版本控制的价值可能从抽象的记录能力变成明确的协调能力。引入它会让流程更复杂，而分支会带来整合成本。负责人应据此评估团队是否有能力承担冲突处理，并把工具选择、分支策略和维护周期单独设计，而不是把“开始用版本控制”当作问题已经解决。