我用 Jujutsu 版本控制系统实现二维版本管理的实践

这个夏天，我参加了 r/roguelikedev 的暑期活动，内容是跟着某篇 Roguelike 编程教程写一个 Roguelike 游戏[1]。我并不是想学编程，所以借这个活动来尝试学点别的东西。今年我想攻克的事情之一，就是二维版本控制。我们跟着的教程有 14 章。我希望在写代码时使用版本控制，但同时也想用版本来对应教程的章节：项目结束时，我既想要一份我写教程过程中所做改动的历史（横轴），也想要一份读者跟着教程走时应该做的改动的历史（纵轴）。

只要每一章建一个 Git 分支、把上一章作为父节点，就能得到我想要的结构。这样当我更新第 1 章的代码时，就可以把它向前推进到第 2 章、第 3 章等等。不过，Jujutsu 版本控制系统[2]可以自动完成这件事。我不用管理所有分支和合并，而是可以专注于图中的“写作”那一列，随时编辑任意一章。Jujutsu 会把改动从一章滚动推进到其他章。我决定在这个项目里试一试。已经有人在博客里写过 Jujutsu 的特性了；我打算聚焦于自己想要的二维输出。

例子：在做地下城生成那一章时，我意识到本可以把瓦片数据结构设计得更好。把这些改动放在地下城代码之前很容易。这张图里，横轴是时间，纵轴是章节。我在地下城生成和瓦片地图结构之间来回切换。等我对两者都满意之后，才转向更好的数据结构。不用管颜色，那是可视化工具带来的。

例子：在做视野（field of view）那一章时，我发现前面好几章有很多地方本可以改进。我对 Jujutsu 已经足够得心应手，以至于我的大脑不再把提交看作“板上钉钉”，而是看作“这个我能修！”然后我就修了。

例子：大部分改动都集中在最新的几章（这张图的底部）。但偶尔我也会回到更早的章节（这张图的顶部）。红色表示我遇到了合并冲突，必须先解决才能回去继续做最近的章节。

例子：随着我越来越习惯跨提交做改动，我想出了更好的命名，要在整个项目里统一使用。我希望这些改动从最开始就存在，所以我结合使用了常规的 jj edit（把改动向前传播到后面的章节）和 jj absorb 命令（把改动向后传播到更早的章节）。这需要大量清理。改动本身没有合并冲突，但改完的代码并不总能编译通过。如果我在第 1 章把 apple 改成了 zebra，而第 2 章里也用过 apple，Jujutsu 并不会知道要把那个名字也一起改掉。所以我只能手动修改，并逐章测试。

例子：我很喜欢可以事后修改版本控制的变更描述。这里就是我在回头把所有变更描述统一格式：

感想：只靠阅读来学习是很难的。这个项目里，我想尝试做很多事情，看看哪些行得通、哪些行不通。这个项目有点特殊，因为我不仅想做出游戏的最终版本，还想产出 50 个都能运行的中间版本，并且代码要干净，能用在教程系列里。

我认为 Jujutsu 是这个项目里一个合理的工具。我可以用它来开发，也可以导出到 Git，这样别人就不必使用 Jujutsu。GitHub 仓库[3]里有 54 个 Git 提交，而不是 Jujutsu 内部那约 5000 个提交。

到目前为止，对我来说主要的缺点是很多事情都是自动发生的，我无法全部跟踪。我需要更好地理解它在幕后做了什么，这样才能更有信心地使用它，同时避开一些坑。

做出来的游戏可以在网页上玩。我写了笔记，但这次没有写教程。