jj 版本演进全解从 CHANGELOG 读懂 jj 的发布节奏、破坏性变更与核心新特性【免费下载链接】jjA Git-compatible VCS that is both simple and powerful项目地址: https://gitcode.com/GitHub_Trending/jj/jjjj 的发布说明全部记录在仓库根目录的 CHANGELOG.md 中网站端则通过 docs/changelog.md 这个轻量包装文件对外展示。本文以该变更日志为骨架带你掌握 changelog 的组织规范Keep a Changelog Semantic Versioning、逐版本解读最近的 0.43–0.45 系列发布的核心新特性与破坏性变更并说明如何通过源码与发布流程文档docs/releasing.md印证这些特性的真实实现从而在升级 jj 版本前准确评估影响面。一、changelog 的两个入口与组织规范jj 仓库中存在两个与变更日志相关的文件CHANGELOG.md仓库根目录真正被人工维护的完整变更日志从v0.3.02022-03-12changelog 启用之前的最后一个版本一直记录到v0.45.12026-09-03当前共约 5600 行、50 余个版本条目docs/changelog.md网站入口文件正文只有 9 行其全部内容就是一个include-markdown指令把根目录的 CHANGELOG 引入到站点中并开启rewrite-relative-urlstrue和commentstrue。网站源码 web/docs/plugins/remark-include-markdown.mjs 中也内置了同类 include 插件用于站点构建。这种“根目录为事实源、文档目录做转发”的设计保证了两处展示永远一致。根文件的文件头明确声明了组织规范The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.每个版本块如## [0.45.0] - 2026-09-02内部固定分为以下小节这是阅读时的固定框架小节含义升级时的关注度Release highlights本版本最有亮点的特性高决定“为什么升”Breaking changes破坏性变更最高决定“升不升得动”Deprecations弃用声明未来版本将移除中需要排期迁移New features新功能与新配置项高决定“升级能用什么”Fixed bugs缺陷修复中修复版本常因此发布Contributors贡献者名单低文件末尾CHANGELOG.md#L5598-L5651集中存放每个版本 tag 的 compare 引用链接例如[0.45.0]: ...compare/v0.44.0...v0.45.0这是 Keep a Changelog 规范的标准做法用于让读者快速定位任意两个版本之间的完整代码差异。二、[Unreleased]下一版本正在发生什么changelog 顶部的[Unreleased]区块CHANGELOG.md#L9-L27记录了尚未发布的变更是预判下一个版本影响面的第一手资料。当前区块内容包含Breaking changes最低支持的git命令版本从 2.41.0 提升到 2.42.0。原因是jj workspace add开始使用git worktree add --orphan而该选项是 Git 2.42.0 才引入的。New featuresjj workspace add新增--colocate/--no-colocate标志控制是否随工作区创建 Git worktree。默认行为是当前工作区处于 colocated与 Git 共享工作副本状态且git.colocate配置为true时自动 colocatejj workspace forget在存在对应 Git worktree 时会将其一并删除jj git colocation status/enable/disable现在支持子工作区status能正确报告 colocate 状态并包含工作区名enable会创建 Git worktreedisable会删除它从而允许在工作区创建之后再切换 colocate 状态。三、v0.45.12026-09-03典型的修复版本0.45.1 是一个纯修复发布CHANGELOG.md#L37-L50修了两个与构建/签名相关的真实问题无Cargo.lock构建恢复可用bisynccrategix 的传递依赖的所有版本被 yank 之后cargo install jj-cli这类不带Cargo.lock的构建会失败此版本修复后重新可用SHA-256 Git 仓库的提交签名签名现在按 Git 的惯例存入gpgsig-sha256头部使 Git 能识别这些提交为已签名jj 自身也能读回这些签名。这类条目体现了 jj 的版本号策略x.y.z的补丁号用于修复如 0.45.1、0.17.1、0.15.1 均为修复发布功能与破坏性变更集中在x.y.0。四、v0.45.02026-09-02jj converge自动收敛分叉提交这是本 changelog 中技术含量最高的一个版本CHANGELOG.md#L52-L129其发布亮点是全新的jj converge命令尝试自动解决“分叉”divergence——即同一个 change ID 下出现两个或更多可见 revision 的情况——通过创建一个新提交来替换这些分叉提交命令会应用一系列启发式规则尝试自动得出好方案启发式无法决断时回退为交互式询问用户支持非交互模式若需要询问则直接中止而不做任何修改。结合仓库源码可以印证其完整行为。cli/src/commands/converge.rs 中的命令文档注释给出了比 changelog 更细的语义命令按--revisions/-r参数或revsets.converge配置求值 revset然后按 change ID 分组存在多于一个 revision 的 change ID 即视为分叉若无分叉则直接成功返回若存在多个分叉 change会提示用户先选一个用户可能被询问三类事项合并 revision 描述、为解选父节点、很少见地选择作者新 revision 只替换匹配 revset 的分叉 revision其子孙被 rebase 到解上指向分叉 revision 的本地 bookmark 会更新到解上解中可能存在文件冲突即使原来没有冲突操作结果可用jj op show -p审查用jj evolog查看 change 演化历史不满意可jj undo。changelog 中提到的“非交互模式”对应--no-interactive参数源码 cli/src/commands/converge.rs#L102-L108。默认的收敛搜索空间配置在 cli/src/config/revsets.tomlconverge mutable() divergent()即默认只对“可变且分叉”的 change 生效避免误伤不可变历史。底层算法实现位于 lib/src/converge.rs提供find_divergent_changes、converge_change、apply_solution等函数行为由集成测试 cli/tests/test_converge_command.rs 覆盖设计文档见 docs/design/jj-converge-command.md。0.45.0 的其他要点Breaking changesjj config {edit,set,unset} --user不再在存在多个配置文件时交互式提示而是直接作用于第一个加载的用户配置文件如~/.config/jj/config.toml或conf.d/的第一个文件要精确指定请用--file PATH该选项正是此版本新增的非 colocated 仓库中jj git import不再导入处于 detached Git HEAD 分支上的提交。Fixed bugs选摘默认的immutable_heads()revset 现在包含untracked_remote_tags()对应 docs/config.md 的“Set of immutable commits”一节默认 pager 参数加入-K--quit-on-intr在less中按 CtrlC 可以干净退出不再留下终端损坏状态colocated 仓库中外部git add在 jj 命令之后不再产生含重复条目的树——根因是 jj 在.git/index中遗留了过期的 cache-treejj log在涉及隐藏 revision 与log-graph-prioritizerevset 时的崩溃已修复。另一个值得注意的内核变更Git HEAD 状态改为按 worktree 内部跟踪。这是为 colocated 仓库支持多个 Git worktree 做准备每个 jj 工作区可以有自己的 Git HEAD存量仓库会自动迁移。五、v0.44.02026-08-05Tag 的 fetch/push 稳定化与jj run大增强0.44.0 的发布亮点是标签tag的拉取与推送正式稳定化tag 可以像 bookmark 一样被 track/untrack被 track 的 tag 默认会被推送CHANGELOG.md#L162-L253。Breaking changesjj git fetch现在以与 bookmark 相同的方式拉取 tagtag 以nameremote形式拉取并被同名的本地 tag 自动跟踪。在现有仓库中运行一次jj git fetch会重新拉取全部 tag 以初始化跟踪状态。Git 侧的tagOpt配置不再被读取要关闭 tag 拉取需设置remotes.name.fetch-tags ~*jj git clone --fetch-tagsall|none|included被移除改由--tagPATTERN取代jj git push --all现在会连同所有 tag 一起推送jj file search输出改为“每行匹配内容 文件路径前缀”而非只列含匹配的文件路径旧行为可用--name-only恢复重复传参不再是错误最后一个取值生效jj --no-pager --no-pager version与jj log -n 5 -n 10现在都合法别名中“烤进”的参数也可以被显式覆盖。可重复参数如--config、jj log -r不受影响仍收集所有值。New features选摘新增merge_point()revset 函数类似fork_point求多个分支的汇合点与builtin_log()revset 别名revsets.log默认值改为builtin_log()自定义 log revset 可直接复用它而非复制整段表达式新增try(expr, fallback...)模板函数用于抑制模板运行时错误jj run系列增强默认按从旧到新处理 revision即使--jobs 1也保证第 N 个 revision 在第 N-1 个启动之后才启动新增--passthrough子进程 stdout/stderr 直通终端、--ignore-changes命令即使改了工作副本也不编辑任何 revision、--ignore-errors命令非零退出时继续跑剩余 revisionjj tag track/jj tag untrack命令用于把本地 tag 与远端关联拉取来的 tag 默认已跟踪新增diff.stat.max-bar-width配置与模板diff.stat()的max_bar_width参数限制--stat条形宽度jj absorb支持--interactive/-i/--tool可交互地挑选要吸收的 hunk实现“只吸收提交的一部分而不用先 split”jj git push新增--allow-conflicts。这一版本的 tag 相关命令对应源码目录 cli/src/commands/tag/含 track.rs、untrack.rs、list.rs、set.rs、delete.rs测试见 cli/tests/test_tag_command.rs。tag 的演进脉络在 changelog 中完整可查0.38.0 引入实验性的jj git fetch --tag与remote_tags()revset 函数 → 0.41.0 提供remotes.name.fetch-bookmarks/fetch-tags配置 → 0.44.0 稳定化是一条典型的“实验 → 配置化 → 稳定”路线。六、v0.43.02026-07-01jj run批量执行命令0.43.0 的发布亮点是全新的jj run命令CHANGELOG.md#L339-L404对一组 change 批量运行某条命令每个 change 都在自己的私有工作副本中执行命令可以更新工作副本其变更/冲突会按正常快照机制传播回去。changelog 给出的典型用法jj run -- cargo check --all-features jj run -- cargo fix也就是说“对一堆提交逐个跑编译检查/自动修复”这类批量维护操作从此有了官方支持。其实现位于 cli/src/commands/run.rs设计文档在 docs/design/run.md测试覆盖在 cli/tests/test_run_command.rs。0.45.0 还修复了它的一个行为问题某个 revision 上的命令以非零码退出后不再继续对剩余 revision 执行需要时可用 0.44.0 引入的--ignore-errors显式放宽。0.43.0 的其他要点Breaking changesrevset 与模板中弃用的git_head()和git_refs()函数被移除Git 风格的引用符号如refs/heads/main不再能解析为 revision应使用 bookmark/tag 的name或nameremote语法弃用的ui.revsets-use-glob-by-default配置项被移除jj bookmark track/untrack不再支持kind:bookmarkremote模式bookmarkremote符号语法仍支持。New features选摘jj现在会在/etc/jj中查找系统级配置文件jj config gc可删除~/.config/jj/repos下已被删除/移动仓库的配置jj git fetch现在按 change ID 对“被重写的被 bookmark revision 的子孙”做 rebase此前栈式提交栈中的重写提交不会总被 rebase不可变子孙除外新增forks()revset 函数返回所有多于一个子节点的提交colors配置支持删除线样式{ crossed-out true }jj gerrit upload支持-o/--option等价git push -o。Fixed bugs选摘修复 Intel Raptor Lake CPU 与 aarch64 上写坏 loose Git 对象的问题——此前 jj 可能报告提交成功但git fsck随后会以corrupt loose object失败。七、从 changelog 看 jj 的版本约定与升级检查清单综合整份 changelog可以归纳出以下可验证的版本约定供升级决策参考语义化版本x.y.0承载新特性与破坏性变更x.y.1为修复发布0.45.1、0.17.1、0.15.1、0.28.1、0.28.2、0.6.1、0.5.1 均如此。当前工作区版本为 0.45.1见 Cargo.tomlworkspace.package.version 0.45.1最低 Rust 版本 1.89弃用有明确周期被弃用的命令/配置/函数通常在下几个小版本正式移除changelog 会同时记录“弃用”和“移除”两个时间点。例如 0.42.0 弃用jj evolog对 0.30 遗留 predecessor 的支持、0.39.0 移除jj op undo并建议改用jj op revert或jj undo/redo0.43.0 移除git_head()/git_refs()。升级前搜一遍自己用到的命令是否出现在更早版本的 Deprecations 小节即可预判风险对 Git 兼容性的边界会随版本上移最低 Git 版本要求从 0.38.0 的 2.41.0 提升到 Unreleased 的 2.42.0这类条目直接影响 CI 环境与 macOS 等自带 Git 偏旧的系统破坏性变更条目自带迁移指引几乎每条 Breaking change 都给出了替代方案--fetch-tags被移除时给出--tagPATTERNfile search输出变化时给出--name-only--user行为变化时给出--file。一次实用的升级前检查流程可以这样组织# 查看上一版本 tag 在哪里确认 changelog 基线 jj log -r heads(tags()) # 用 jj 自己对比上一版本 tag 与当前 HEAD 之间的 CHANGELOG 差异 jj diff --from heads(tags()) --to main CHANGELOG.md该命令组合出自官方发布流程文档 docs/releasing.md。八、changelog 是如何被写入和发布的了解 changelog 的生产流程能帮你理解其中条目的来源与可信度。docs/releasing.md 完整描述了 jj 的发布流程关键步骤与 changelog 强相关提交一个更新 changelog 与 Cargo 版本的 PR允许并鼓励对 changelog 做编辑性整理——填充 “Release highlights”、把重要条目前移、统一语言与格式、核对错放的条目获取 CHANGELOG 差异用的正是上节的jj log -r heads(tags())jj diff --from heads(tags()) --to main CHANGELOG.md命令维护末尾的 compare 引用链接新版本 tag 要加一条指向“上一版本 tag … 新版本 tag”的 GitHub compare URL同时把[unreleased]链接更新为“最新版本 … HEAD”。对照 CHANGELOG.md#L5598-L5651 可以看到每条链接都严格遵循compare/v0.44.0...v0.45.0的形态生成贡献者名单可用gh api /repos/jj-vcs/jj/compare/$root...main加 jq 过滤的方式生成也可以本地用jj log -G -r heads(tags())..main -T * author \n | sort -fu生成后再补全用户名打 tag 并发布 GitHub Release在 Releases 页面新建v0.number.0tag把 changelog 条目粘贴进 release body发布 crates建议在全新 clone 中执行cargo publish --workspace——原因是cargo publish会把匹配[include]模式的被忽略文件一并打包在含敏感内容的工作副本中执行有安全风险。对使用者而言这份流程文档还隐含了一个实用信息每个 release 的讨论入口Create a discussion for this release和逐版本 compare 链接都是固定的因此把某个具体行为变化归因到具体版本时changelog 是权威依据。九、结语jj 的 changelog 是一份维护规范、粒度细到“为什么改”的变更日志docs/changelog.md转发根目录的 CHANGELOG.md每个版本按 Keep a Changelog 的五段式结构组织破坏性变更都附迁移路径发布流程docs/releasing.md保证了条目与 tag、crates 版本的一致性。以 0.45.x 为例配合源码交叉印证cli/src/commands/converge.rs、cli/src/config/revsets.toml、cli/src/commands/run.rs可以确认 changelog 条目与实现一一对应。掌握本文的读法后你可以在升级 jj 前系统性地核对 Breaking changes 与 Deprecations 两个小节并把[Unreleased]区块作为下一版本影响面的前瞻依据。【免费下载链接】jjA Git-compatible VCS that is both simple and powerful项目地址: https://gitcode.com/GitHub_Trending/jj/jj创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考