Jujutsu 面向 Git 专家实战指南在 Git 仓库中体验更简单、更安全、更快的历史编辑【免费下载链接】jjA Git-compatible VCS that is both simple and powerful项目地址: https://gitcode.com/GitHub_Trending/jj/jj这篇指南面向已经熟练使用 Git 的开发者系统讲解 Jujutsujj相对于 Git 的实际优势从同仓库并存colocation、用提交替代暂存区到自动化的历史改写、基于操作日志的撤销、演变日志evolog以及jj absorb补丁栈吸收。读完本文你将掌握在熟悉的 Git 工作流中无缝切入jj的具体命令与适用场景并能从源码层面理解这些能力为何更安全、更高效。Git 与 Jujutsu 可在同一仓库中并存Colocation对于 Git 专家而言最大的心理障碍往往是换工具 放弃原有技能栈。Jujutsu 的设计从一开始就消除了这个顾虑Jujutsu 仓库与 Git 仓库存在于同一目录中你可以在同一工作区内交替使用jj和git命令。这种模式被称为 colocated 工作区glossary.md#colocated-repos。从仓库定义看colocated 有精确的技术含义使用 Git 后端时只要底层 Git 仓库的.git/目录是.jj/目录的兄弟目录该工作区即为 colocated。此时大多数为 Git 设计的工具都能直接使用jj与git命令可以互换执行。详见 git-compatibility.md#colocated-jujutsugit-repos。实操建议非常简单# 用 jj 处理它擅长的场景 jj log jj new jj squash --into - # 遇到 git 生态更顺手的场景随时切回 git git diff --stat git status如果你在某类场景下发现 Git 更顺手直接使用git命令即可处理完再回到jj若发现某个痛点尚无jj对应能力可以在项目的 issue 中提交功能请求。这种并存设计让迁移成本降到最低——你可以只为被改进的工作流引入 Jujutsu而无需放弃任何已熟悉的 Git 命令与工具。对于从零开始的新仓库colocation 甚至是默认行为配置项git.colocate是一个布尔选项控制jj git init与jj git clone创建的工作区是否默认采用 colocated 模式config.md#default-colocation。设git.colocate false可关闭该默认行为。没有暂存区用提交替代 Git 的 index/staging areaGit 的 index暂存区是学习曲线中最陡峭的概念之一git add、git reset、git rm --cached等一系列命令都围绕暂存区展开。Jujutsu 没有 index/staging area——因为重写提交既快又容易天然可以用提交来替代暂存区。不再需要为暂存区准备一套独立命令只需用jj split和jj squash来搬运进行中的工作其流畅度与搬运已完成的工作完全一致# 把工作副本提交拆成两个顺序提交file1 和 file2 放入第一个提交 jj split file1 file2 # 或交互式选择要拆分哪些改动 jj split # 把 file3 的改动并入父提交 jj squash file3 # 或交互式选择 jj squash -i从源码看这两个命令的参数设计正是为了替代暂存区操作split.rs 接受位置参数paths来指定放入第一个提交的文件集未指定路径或使用--interactive时则进入交互式选择squash.rs 同样支持paths限定只移动指定文件的改动--interactive则以交互方式挑选改动块。换句话说git add file1 file2 git commit的心智模型在 jj 中被统一为把改动并入某个提交这一种操作。自动且更安全的历史编辑如果你经常 amend、reorder 或 squash 提交Jujutsu 往往能用更少的命令完成同样的工作且自动处理所有后续影响。假设你想修改一个较早的提交abc在 Git 中通常需要三步git add file1 file2 git commit --fixup abc git rebase -i --autosquash而 Jujutsu 只需要一条命令直接把改动并入目标提交jj squash --into abc file1 file2这条命令背后是自动完成的重写目标提交被更新所有后代提交自动 rebase 到修改后的提交之上无需手动进入交互式 rebase 编辑器。squash的命令文档明确说明了这一语义——将改动从某个修订版移动到另一个修订版--into用于指定并入目标默认目标为工作副本提交未指定路径时配合--interactive选择改动见 squash.rs。对于 Git 专家这里的关键认知转变是在 Jujutsu 中历史不是不可触碰的重写历史是常态操作而工具会负责其余的一切。撤销操作日志比 reflog 更强大Git 的 reflog 功能强大但它是**按引用per-ref**记录的当一次误操作涉及多个 ref 或多个操作叠加时靠 reflog 回溯往往既繁琐又容易出错。Jujutsu 的操作日志operation log记录的是整个仓库的状态每一次变更都是一个可检查的操作operation你可以用一条命令把仓库恢复到任意历史状态。针对 Git 专家常见操作日志用法如下# 一步撤销上一次操作无需先弄清该 reset 哪个 ref可重复执行继续回退 jj undo # 查看带差异的操作日志弄清到底发生了什么 jj op log -p # 以仓库处于某个历史状态的方式执行任意命令 jj --at-operation ID status jj --at-operation ID log其中--at-operation是一个全局选项实现于 cli_util.rs它以指定操作时的仓库状态加载仓库并且隐式隐含--ignore-working-copy——即不会先对工作副本做快照而是查看可能过期的历史工作副本提交。这意味着你可以完全只读地穿越回过去检查状态而不会污染当前仓库。对比 reflogjj undo的语义是整个仓库层面的一次回退不需要关心具体是哪个 ref 出了问题jj op log -p让你看到每次操作改动了什么--at-operation则让回到过去成为一种可组合的查询能力。更系统的介绍见 operation-log.md。演变日志evolog追踪单个变更的历史Git 的 reflog 展示的是 ref 随时间如何移动却很难回答这个特定提交是如何一步步演变成现在这样的问题。Jujutsu 的演变日志evolution log简称 evolog正是为此设计的每次变更被重写如 amend、rebase、squash重写事件都会出现在 evolog 中。用法示例# 查看某个提交的演变历史 jj evolog REV # 从 evolog 中找到某个历史版本把完整或部分内容恢复到当前版本 jj restore --from REV --to 你可以用 evolog 找到之前的某个版本再通过jj restore把该版本的完整或部分内容恢复到当前版本。这对于改坏了想找回旧思路、只想恢复某几个文件的旧实现这类场景比在 reflog 与git show之间反复横跳要直接得多。jj absorb轻松更新补丁栈在补丁栈patch stack工作流中你需要同时维护多个相互依赖的提交。用 Git 修改多个提交中的内容时通常要为每个提交分别执行一次git commit --fixup ID最后再git rebase --autosquash合并整理。jj absorb把这一整套流程压缩为一条命令当你在工作副本中做了若干小修复并希望它们被吸收进最近的提交时jj absorb会自动把工作副本中的每处改动移动到最后一次修改该行的提交中。# 自动吸收工作副本中每处改动都并入最后修改对应行的提交 jj absorb # 交互式选择只吸收部分 hunk jj absorb --interactive从源码看该命令的完整语义定义在 absorb.rs它会拆分源修订中的改动把每处改动移动到最近的、修改过对应行的可变祖先提交如果目标无法唯一确定则改动保留在源提交中。相关参数包括--from源修订默认工作副本提交--into候选目标修订集默认mutable()所有可变提交只会考虑源修订的祖先--interactive只对选中的 hunk 执行吸收这些 hunk 可以分散吸收到多个祖先--tool指定不同的 diff 编辑器隐含--interactive位置参数paths只吸收指定路径的改动。若所有改动都被吸收且源提交无描述源提交会被自动废弃abandon。通过jj op show -p可以审查jj absorb产生的修改。需要明确其边界如果补丁栈中有多个提交修改了与工作副本相同的行jj absorb不会移动该改动因为目标不唯一。但绝大多数琐碎场景它都能一步到位剩下的歧义改动留给你自行决定如何 squash——这已经比逐个 fixup 高效得多。总结Git 专家迁移到 jj 的核心收益场景Git 的做法Jujutsu 的做法与现有工具共存迁移成本高同目录 colocationjj/git混用git-compatibility.md整理工作副本git add/git rm --cachedjj split、jj squash提交即暂存区修改历史提交fixup 交互式 rebasejj squash --into REV后代自动 rebase撤销误操作逐个 ref 翻 reflogjj undo、jj op log -p、--at-operation整个仓库层面追踪提交演变reflog 难以按提交追踪jj evologjj restore更新补丁栈多个 fixup autosquashjj absorb [--interactive]对于 Git 专家Jujutsu 的核心价值不在于又一个新工具而在于把 Git 中高风险、多步骤的操作历史改写、撤销、暂存、fixup收敛为低风险、自动化的单命令操作。你始终可以保留 Git 作为后盾在 colocated 仓库中按需切换。进一步的参考资料工作区与兼容性细节见 git-compatibility.md术语定义见 glossary.md操作日志系统见 operation-log.mdrevset 语法见 revsets.md。【免费下载链接】jjA Git-compatible VCS that is both simple and powerful项目地址: https://gitcode.com/GitHub_Trending/jj/jj创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Jujutsu 面向 Git 专家实战指南在 Git 仓库中体验更简单、更安全、更快的历史编辑【免费下载链接】jjA Git-compatible VCS that is both simple and powerful项目地址: https://gitcode.com/GitHub_Trending/jj/jj这篇指南面向已经熟练使用 Git 的开发者系统讲解 Jujutsujj相对于 Git 的实际优势从同仓库并存colocation、用提交替代暂存区到自动化的历史改写、基于操作日志的撤销、演变日志evolog以及jj absorb补丁栈吸收。读完本文你将掌握在熟悉的 Git 工作流中无缝切入jj的具体命令与适用场景并能从源码层面理解这些能力为何更安全、更高效。Git 与 Jujutsu 可在同一仓库中并存Colocation对于 Git 专家而言最大的心理障碍往往是换工具 放弃原有技能栈。Jujutsu 的设计从一开始就消除了这个顾虑Jujutsu 仓库与 Git 仓库存在于同一目录中你可以在同一工作区内交替使用jj和git命令。这种模式被称为 colocated 工作区glossary.md#colocated-repos。从仓库定义看colocated 有精确的技术含义使用 Git 后端时只要底层 Git 仓库的.git/目录是.jj/目录的兄弟目录该工作区即为 colocated。此时大多数为 Git 设计的工具都能直接使用jj与git命令可以互换执行。详见 git-compatibility.md#colocated-jujutsugit-repos。实操建议非常简单# 用 jj 处理它擅长的场景 jj log jj new jj squash --into - # 遇到 git 生态更顺手的场景随时切回 git git diff --stat git status如果你在某类场景下发现 Git 更顺手直接使用git命令即可处理完再回到jj若发现某个痛点尚无jj对应能力可以在项目的 issue 中提交功能请求。这种并存设计让迁移成本降到最低——你可以只为被改进的工作流引入 Jujutsu而无需放弃任何已熟悉的 Git 命令与工具。对于从零开始的新仓库colocation 甚至是默认行为配置项git.colocate是一个布尔选项控制jj git init与jj git clone创建的工作区是否默认采用 colocated 模式config.md#default-colocation。设git.colocate false可关闭该默认行为。没有暂存区用提交替代 Git 的 index/staging areaGit 的 index暂存区是学习曲线中最陡峭的概念之一git add、git reset、git rm --cached等一系列命令都围绕暂存区展开。Jujutsu 没有 index/staging area——因为重写提交既快又容易天然可以用提交来替代暂存区。不再需要为暂存区准备一套独立命令只需用jj split和jj squash来搬运进行中的工作其流畅度与搬运已完成的工作完全一致# 把工作副本提交拆成两个顺序提交file1 和 file2 放入第一个提交 jj split file1 file2 # 或交互式选择要拆分哪些改动 jj split # 把 file3 的改动并入父提交 jj squash file3 # 或交互式选择 jj squash -i从源码看这两个命令的参数设计正是为了替代暂存区操作split.rs 接受位置参数paths来指定放入第一个提交的文件集未指定路径或使用--interactive时则进入交互式选择squash.rs 同样支持paths限定只移动指定文件的改动--interactive则以交互方式挑选改动块。换句话说git add file1 file2 git commit的心智模型在 jj 中被统一为把改动并入某个提交这一种操作。自动且更安全的历史编辑如果你经常 amend、reorder 或 squash 提交Jujutsu 往往能用更少的命令完成同样的工作且自动处理所有后续影响。假设你想修改一个较早的提交abc在 Git 中通常需要三步git add file1 file2 git commit --fixup abc git rebase -i --autosquash而 Jujutsu 只需要一条命令直接把改动并入目标提交jj squash --into abc file1 file2这条命令背后是自动完成的重写目标提交被更新所有后代提交自动 rebase 到修改后的提交之上无需手动进入交互式 rebase 编辑器。squash的命令文档明确说明了这一语义——将改动从某个修订版移动到另一个修订版--into用于指定并入目标默认目标为工作副本提交未指定路径时配合--interactive选择改动见 squash.rs。对于 Git 专家这里的关键认知转变是在 Jujutsu 中历史不是不可触碰的重写历史是常态操作而工具会负责其余的一切。撤销操作日志比 reflog 更强大Git 的 reflog 功能强大但它是**按引用per-ref**记录的当一次误操作涉及多个 ref 或多个操作叠加时靠 reflog 回溯往往既繁琐又容易出错。Jujutsu 的操作日志operation log记录的是整个仓库的状态每一次变更都是一个可检查的操作operation你可以用一条命令把仓库恢复到任意历史状态。针对 Git 专家常见操作日志用法如下# 一步撤销上一次操作无需先弄清该 reset 哪个 ref可重复执行继续回退 jj undo # 查看带差异的操作日志弄清到底发生了什么 jj op log -p # 以仓库处于某个历史状态的方式执行任意命令 jj --at-operation ID status jj --at-operation ID log其中--at-operation是一个全局选项实现于 cli_util.rs它以指定操作时的仓库状态加载仓库并且隐式隐含--ignore-working-copy——即不会先对工作副本做快照而是查看可能过期的历史工作副本提交。这意味着你可以完全只读地穿越回过去检查状态而不会污染当前仓库。对比 reflogjj undo的语义是整个仓库层面的一次回退不需要关心具体是哪个 ref 出了问题jj op log -p让你看到每次操作改动了什么--at-operation则让回到过去成为一种可组合的查询能力。更系统的介绍见 operation-log.md。演变日志evolog追踪单个变更的历史Git 的 reflog 展示的是 ref 随时间如何移动却很难回答这个特定提交是如何一步步演变成现在这样的问题。Jujutsu 的演变日志evolution log简称 evolog正是为此设计的每次变更被重写如 amend、rebase、squash重写事件都会出现在 evolog 中。用法示例# 查看某个提交的演变历史 jj evolog REV # 从 evolog 中找到某个历史版本把完整或部分内容恢复到当前版本 jj restore --from REV --to 你可以用 evolog 找到之前的某个版本再通过jj restore把该版本的完整或部分内容恢复到当前版本。这对于改坏了想找回旧思路、只想恢复某几个文件的旧实现这类场景比在 reflog 与git show之间反复横跳要直接得多。jj absorb轻松更新补丁栈在补丁栈patch stack工作流中你需要同时维护多个相互依赖的提交。用 Git 修改多个提交中的内容时通常要为每个提交分别执行一次git commit --fixup ID最后再git rebase --autosquash合并整理。jj absorb把这一整套流程压缩为一条命令当你在工作副本中做了若干小修复并希望它们被吸收进最近的提交时jj absorb会自动把工作副本中的每处改动移动到最后一次修改该行的提交中。# 自动吸收工作副本中每处改动都并入最后修改对应行的提交 jj absorb # 交互式选择只吸收部分 hunk jj absorb --interactive从源码看该命令的完整语义定义在 absorb.rs它会拆分源修订中的改动把每处改动移动到最近的、修改过对应行的可变祖先提交如果目标无法唯一确定则改动保留在源提交中。相关参数包括--from源修订默认工作副本提交--into候选目标修订集默认mutable()所有可变提交只会考虑源修订的祖先--interactive只对选中的 hunk 执行吸收这些 hunk 可以分散吸收到多个祖先--tool指定不同的 diff 编辑器隐含--interactive位置参数paths只吸收指定路径的改动。若所有改动都被吸收且源提交无描述源提交会被自动废弃abandon。通过jj op show -p可以审查jj absorb产生的修改。需要明确其边界如果补丁栈中有多个提交修改了与工作副本相同的行jj absorb不会移动该改动因为目标不唯一。但绝大多数琐碎场景它都能一步到位剩下的歧义改动留给你自行决定如何 squash——这已经比逐个 fixup 高效得多。总结Git 专家迁移到 jj 的核心收益场景Git 的做法Jujutsu 的做法与现有工具共存迁移成本高同目录 colocationjj/git混用git-compatibility.md整理工作副本git add/git rm --cachedjj split、jj squash提交即暂存区修改历史提交fixup 交互式 rebasejj squash --into REV后代自动 rebase撤销误操作逐个 ref 翻 reflogjj undo、jj op log -p、--at-operation整个仓库层面追踪提交演变reflog 难以按提交追踪jj evologjj restore更新补丁栈多个 fixup autosquashjj absorb [--interactive]对于 Git 专家Jujutsu 的核心价值不在于又一个新工具而在于把 Git 中高风险、多步骤的操作历史改写、撤销、暂存、fixup收敛为低风险、自动化的单命令操作。你始终可以保留 Git 作为后盾在 colocated 仓库中按需切换。进一步的参考资料工作区与兼容性细节见 git-compatibility.md术语定义见 glossary.md操作日志系统见 operation-log.mdrevset 语法见 revsets.md。【免费下载链接】jjA Git-compatible VCS that is both simple and powerful项目地址: https://gitcode.com/GitHub_Trending/jj/jj创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
