版本控制CLI【免费下载链接】gitoxideAn idiomatic, lean, fast safe pure Rust implementation of Git项目地址https://gitcode.com/GitHub_Trending/gi/gitoxide点击查看免费下载本文以 gitoxide 仓库中面向 Agent 的 Tix 技能文档 为核心系统讲解如何用 Tix 安全地改写提交历史、修复 CI 失败同时保留人类审阅状态✨ 补丁审阅标记与 ✔️ 检查通过标记。读完本文你将掌握tix travel、tix amend --index、tix new、tix reword、tix enrich commit note以及tix rebase-update [FILE]的完整操作纪律并理解其底层实现依据Tix 行为规范 与 enrich 命令源码。认识 Tix为大型仓库而生的提交历史浏览器Tix 是 gitoxide 仓库中一个tig风格的程序按照 gix-tix/README.md 的描述它的设计初衷是展示项目历史、允许裁剪视图以隐藏指定分支、复制选中 hash并且在查看大型仓库时比tig更快、更省内存。其行为契约由 gix-tix/spec.md 统一定义它是一个极简的、tig启发的、为大型仓库优化的提交历史浏览器必须在 Linux 内核级别的历史规模下保持可用不能为了不可见的元数据牺牲响应性。在 Agent 工作流中Tix 与 Git 有明确的分工Use Tix for history mutations and Git for inspection and staging.即Tix 负责一切历史变更历史变更、改写、重放Git 负责检视与暂存。同时技能文档明确强调用户指令决定操作范围、签名、QA 与推送这份技能本身不授予任何额外授权。换句话说Tix 是执行工具操作的合法边界始终来自用户的明确要求。Tix 的命令面相当完整spec.md 列出了tix [REVISION]...浏览、tix show打印完整历史视图、tix travel时间旅行式检出、tix stash、tix rebase todo/apply、tix enrich、tix new/reword/amend等子命令。本文聚焦于 SKILL.md 所规范的编辑既有提交 修复 CI场景。动手前检查、选择与状态判定任何历史变更之前必须建立对当前状态的完整认知git status --porcelainv1 --branch tix show记录三项基准信息起始分支、起始 hash、起始 change ID。由于仓库中可能同时有其他 Agent 在工作每次变更前都应重新检查状态必要时等待其他 Agent 的操作落定。Tix 会在每个提交 hash 后显示一个change ID。根据 spec.md 的定义每个七字符提交 hash 之后紧跟一个七字符reverse-hex逆序十六进制change ID两者宽度相等发生前缀冲突或重复时行首会出现沟槽标记。技能文档给出了一个重要建议后续旅行travel时优先使用 change ID 而不是 hash因为编辑与重放过程中 hash 会变化而 change ID 在提交被改写后依然稳定spec.md 说明 enrichment 正是以提交的有效 change ID为键存储的。另一个必须理解的概念是pending replay待处理重放当某个祖先提交被编辑后Tix 可能不会立即把后代提交的变更重放到编辑后的历史上而是推迟到tix travel到达它们时才执行。因此在编辑祖先内容后查看tix show某些审查标记可能暂时消失这属于正常现象不应据此误判。任务决策表amend、fixup、reword 还是 newSKILL.md 给出了一个核心决策表它决定了不同任务对应的默认动作TaskDefault actionAdd independent workCreate a new commit.Change only a messageReword the requested target directly.Change a commits contents without✨Amend it directly; do not create a fixup, regardless of other enrichments.Change a commits contents with✨Preserve it; insert afixup!immediately above it.理解这张表的前提是理解两个审查标记✨补丁审阅/重构批准标记由人类审阅者在 Tix change 中通过tix enrich patch refackiewed设置。只有人类审阅者才能显式设置或清除该标记——Agent 严禁调用该命令包括--clearAgent 自己的审阅、检查通过、正面反馈或收尾请求都不构成授权依据。✔️记录某个精确树的检查通过状态由tix enrich tree checks-pass管理。它不暗示审阅通过审阅标记也不代表检查通过两者互不蕴含。如果用户指令与决策表冲突以用户的显式指令为准除非用户明确要求否则不要 squash fixup。变更之后不得伪造任何标记也不得把一次聚焦测试当作完整的 QA 画像。底层实现enrichment 的存储机制这两个标记连同todo、note属于 Tix 的enrichment机制其实现可在 gix-tix/src/enrich.rs 中确认。根据 spec.md提交级 enrichment 存储在 worktree 本地的refs/worktree/tix/enrichGit notes 中以提交的有效 change ID 为键使用人类可读的 Git config 格式独立的[commit]键保存todo true和可选的多行note值树级 enrichment 存储在refs/worktree/tix/enrich-treenotes 中直接以tree object ID为键[tree] checks-pass true因而适用于每个拥有该精确树的提交并且一旦改写改变了树标记自然消失。对应地command/enrich.rs 中的子命令结构为tix enrich commit todo|note|git-note与tix enrich tree checks-pass布尔型命令幂等地设置或清除标记note 命令调用 Git 编辑器、删除空 note、对未变更的 note 不做改动且所有命令的目标默认是HEAD也接受 Git revspec 或无歧义的 change ID 前缀。编辑命令实战travel、amend、new、fixup、reword切换目标提交tix travel对于内容编辑必须从干净的 index 与 worktree出发先旅行到目标提交确认HEAD正确后再编辑tix travel $target_change旅行到目标后执行聚焦验证。当HEAD正确时其他 Agent 的未暂存变更不需要旅行或清理只暂存自己拥有的路径/hunk新文件必须显式加入。修改提交内容tix amend --indextix amend --index--index是必须的否则当 index 与HEAD相同时amend和new会回退到已跟踪的 worktree 变更未跟踪文件不会被隐式包含。--index消费整个 index因此如果存在他人无关的暂存变更需要先协调。该行为与 spec.md 一致命令行tix amend --index禁用 worktree 回退仅当 index 有暂存内容时改写提交否则报告nothing to amend。创建 fixup生成精确首行 新建提交当目标提交带有✨标记而必须保留时在旅行到目标之后用如下命令生成 fixup 的精确第一行git show -s --formatfixup! %s HEAD $message_file注意不要从tix show复制主题行因为tix show渲染 Markdown可能省略字面反引号。也没有tix new --fixup这样的旗标。接着追加一个空行并在消息中说明失败原因、修正内容与验证结果然后使用完整的消息文件并以负责 Agent 的真实姓名/邮箱作为作者tix new --index --author $agent_author --file $message_file创建 fixup 后记录其新 change ID 作为fixup_change并给它添加一条 Tix notenote 中只包含如果这个 fixup 是普通提交时它应有的单行标题。解释保留在提交体里提交主题保持精确的fixup! original subject。note 文件必须放在检出目录之外旧提交处文件可能消失再通过 Git 编辑器非交互地保存TIX_FIXUP_NOTE_FILE$note_file GIT_EDITORcp $TIX_FIXUP_NOTE_FILE \ tix enrich commit note $fixup_changetix enrich commit note没有--message或--file旗标。必须先确认 enrichment 成功再继续若失败应直接在现有 fixup 上补完 note而不是另建提交。仅修改消息tix rewordtix reword $target_change --file $message_file先检视目标内容再提供其完整替换消息。即使HEAD移动了也要忠实于显式目标基于文件的消息会保留 enrichment。单纯润色文字不转移作者权只有内容责任发生变化时才用--author指定作者例如tix reword --author Agent Name agentexample.com见 gix-tix/AGENTS.md。临时禁用提交签名当签名被禁用时既有工作流使用命令级前缀同样适用于new与rewordGIT_CONFIG_COUNT1 GIT_CONFIG_KEY_0commit.gpgSign GIT_CONFIG_VALUE_0false tix amend --index关键是保留任何既有配置覆盖项不要覆盖它们也不要修改持久化的 Git 配置。相关源码与仓库纪律佐证command/enrich.rs 的测试boolean_enrichments_are_idempotent_and_target_the_selected_commit证实todo 与 checks-pass 标记的设置/清除是幂等的且只作用于目标提交默认HEAD不被波及command/enrich.rs 的测试editors_preserve_other_enrichments证实编辑 note 会保留 todo 标记Tix note 与普通 Git note 均使用编辑器输出gix-tix/AGENTS.md 记录了 gix-tix 目录专属的provisional commit 规则开始修改跟踪文件前从干净 worktree 创建一个以WIP wipinvalid为作者的临时空提交任务完成后暂存变更并 amend 该提交把作者替换为负责 Agent 的真实身份、更新主题与正文最终提交必须包含完整任务且 worktree 干净。SKILL.md 特别提醒这条规则只适用于 gix-tix/ 目录下的编辑并非每次 Tix 操作都要遵守。tix rebase-update [FILE]把可见栈更新到新基tix rebase-update是技能层级的命令而非字面安装的 Tix 子命令当用户在请求中提到它时它的含义是把当前可见栈更新到更新的隐藏本地分支 tip 上底层通过tix rebase todo --update-base实现。可选的FILE是要保留的 todo 路径未提供时在检出目录之外创建任务专属的临时文件成功后删除。开始前依次刷新以下信息git status --porcelainv1 --branch tix show tix rebase todo --help不得带着未合并条目、或带着无关的脏 index/worktree 开始**——rebase 可能同时需要它们来做冲突恢复。也不要仅仅为了让检出变干净就去 stash、丢弃或吸收其他 Agent 的变更。先生成计划而不立即应用tix rebase todo --update-base $todo_file必须等生成成功并完整阅读计划。保留每一个可见提交、fork、ref 以及生成的检出目标除非用户显式要求额外历史编辑。不要手工构造新基也不要用猜测的--onto替代--update-base。应用审阅过的文件并选择可恢复的冲突tix rebase apply --materialize-conflicts $todo_file应用成功即更新完成。只有当 Tix 报告保存了操作且 index 中存在未合并条目时才接受冲突。此时检查tix rebase status、git diff --cc以及 index 阶段:1:、:2:、:3:保留双方的提交意图只暂存解决方案然后继续tix rebase continue --materialize-conflicts后续每个冲突重复检查 → 解决 → 继续的循环。铁律包括操作已保存后绝不重跑原始 todo绝不用tix amend记录 rebase 冲突除非用户要求保留部分结果并放弃剩余操作否则不调用tix rebase stop。完成后验证tix rebase status无已保存操作git status --porcelainv1 --branch与tix show正常确认更新的隐藏基在祖先链中、预期的检出与 refs 已恢复、所有原始可见变更仍被表示、且没有无关文件进入被改写的提交。若提供了FILE就保留它否则只删除任务专属的临时 todo。从实现看--update-base与--onto互斥且没有可用的更新目标 tip属于错误spec.md默认情况下 todo 冲突不改变任何东西显式--materialize-conflicts [CONTINUE]才接受部分结果、检出冲突提交带未合并 index并写出新的可编辑续接 todo且以非零退出码结束防止脚本把未完成的 rebase 误认为完成spec.md。重放与恢复Replay and Recovery编辑可以先行推进 refs而把后代变更留到稍后重放。完成祖先编辑任务后用tix travel $return_branch重放祖先链并恢复附着状态如果初始是 detached则通过保存的 change ID而非过期的 hash返回。尊重用户后续的检出变更直接目标的 reword 并不因祖先被改写而必须旅行回去。针管理pin交给 Tix 的正常命令。若 travel 报告重放冲突但没有改变文件使用tix travel --materialize-conflicts $target_change它刻意以非零退出码结束且必须对应未合并的 index。检查git diff --cc与阶段:1::2::3:保留双方提交意图暂存解决结果后tix amend --index再重试 travel——仅暂存是不完整的。其他失败后先检查状态修正环境问题再重试绝不重复已成功的变更也不要用 reset 替代诊断。不要自动 stash 或吸收其他 Agent 的工作旅行前完成已授权、任务专属的变更或保留验证过的补丁/副本含未跟踪文件。tix stash与travel --stash是可选项。应用失败后先保留恢复提交、检查已应用了什么再恢复任何东西。消息与恢复材料放在检出目录之外。验证与收尾Validate and Finish保持提交自包含。对 CI 修复运行聚焦检查并把取消导致的干扰与真实失败区分开。用户明确要求全面 sweep 时遵循 tix-qa-sweep 技能它按从旧到新的顺序访问每个没有✔️标记的可见提交先确定 Fast格式化、lint、类型、静态/依赖检查或 Thorough加上构建、测试、文档与集成检查画像再在每次修复后用tix enrich tree checks-pass标记通过的树全程保留用户的排除项、审查保留规则与 QA 级别。不要在每次修复后自动启动完整 QA。复用构建缓存不删除缓存、不禁用增量编译、不把已授权的增长当作附带清理。完成后返回请求的检出位置核验状态、位置、diff 与最新的tix show保留未被触碰的审查标记不要重建已失效的标记。存在并发工作时只验证预期变更是否被提交而不是强行让一切变干净。最终报告应给出最终 hash/change ID、验证结果与推送状态包括远端 CI 仍在测试更旧 head 的情形成功后只删除任务专属的临时文件中断时保留恢复材料。小结Tix 把 gitoxide 仓库的提交历史编辑变成一套可审计、可恢复的纪律性操作以 change ID 为锚点旅行按审阅状态✨决定 amend 还是 fixup用文件化消息保留 enrichment用tix rebase todo --update-base与tix rebase apply --materialize-conflicts完成可见栈更新最后以tix enrich tree checks-pass与聚焦 QA 收尾。其所有行为都有 gix-tix/spec.md 与 gix-tix/src 下的源码与测试背书本文给出的命令序列可直接在当前仓库或任何使用 Tix 管理的仓库中执行。赞分享版本控制CLI【免费下载链接】gitoxideAn idiomatic, lean, fast safe pure Rust implementation of Git项目地址https://gitcode.com/GitHub_Trending/gi/gitoxide点击查看免费下载相关推荐gitoxide重base操作Rust实现的Git提交历史改写gitoxide重base操作Rust实现的Git提交历史改写 在日常开发中你是否遇到过这样的困扰提交历史混乱不堪难以追溯代码变更多人协作时分支合并版本控制CLIFiddler中文版与Charles终极对比哪个网络调试工具更适合你Fiddler中文版与Charles终极对比哪个网络调试工具更适合你 在当今的Web开发和网络调试领域选择合适的调试工具至关重要。Fiddler中文版和C开发工具接口测试如何在5分钟内搭建个人专属AI知识库AnythingLLM全攻略如何在5分钟内搭建个人专属AI知识库AnythingLLM全攻略 你是否曾幻想拥有一个能理解你所有文档的AI助手无论你是学生整理学习资料、职场人士管理项目文人工智能AI 应用RAGAI Agent后端前端上一篇FFmpeg批处理工具3步实现视频批量转换自动化下一篇OpCore Simplify重新定义Hackintosh配置的智能自动化革命创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考