Zagi：为AI协作优化的Git命令行工具，提升开发效率

1. 项目概述：为AI时代重构的Git命令行工具

如果你和我一样，每天大部分时间都在和Git打交道，同时又在深度使用各种AI编程助手（比如Cursor、Claude Code、Windsurf），那你肯定遇到过类似的困扰：git status的输出信息量太大，AI助手处理起来上下文窗口一下就满了；或者想快速为AI生成的几个不同方案创建独立分支进行对比，操作起来却相当繁琐。更别提那些AI工具自动生成的、塞满了Co-Authored-By:的提交信息，让提交历史变得杂乱无章。

最近在GitHub上发现了一个名为zagi的项目，它精准地戳中了这些痛点。简单来说，zagi是一个用Zig语言重写的Git命令行接口，它的目标不是替代Git，而是为现代开发流程，尤其是人机协作（Human-AI Pair Programming）场景，提供一个更高效、更智能的“前端”。它的核心设计哲学是：保持与原生Git命令的完全兼容性，但在输出格式、执行速度和为AI优化的功能上做到极致。这意味着你可以把git命令直接替换成zagi，原有的工作流完全不变，却能获得显著的效率提升和更好的开发体验。

这个项目来自开发者mattzcarey，目前已经在GitHub上获得了不少关注。它最吸引我的地方在于其务实的设计——没有试图重新发明轮子，而是巧妙地包裹在Git之上，解决了真实工作流中的摩擦。对于频繁使用AI编程助手的开发者、需要管理多个并行实验性分支的研究者，或是任何希望命令行更干净、更快的工程师来说，zagi都值得一试。接下来，我将从设计思路、核心功能、实操细节到避坑经验，为你完整拆解这个工具。

2. 核心设计思路与优势解析

2.1 为什么需要另一个Git前端？

在深入zagi的具体功能前，我们首先要理解它要解决的根本问题。原生的Git CLI无疑强大且稳定，但其设计诞生于一个纯人类协作的时代。当AI智能体成为日常编码的“协作者”时，一些原本不是问题的地方开始显现出不足。

首先，上下文窗口（Context Window）的浪费。AI模型（如Claude、GPT）在处理任务时，有严格的Token限制。原生Git命令如git status或git log的输出通常非常冗长，包含了大量对人类友好但对AI冗余的信息（如完整的文件路径、重复的提示文字、复杂的格式符号）。这些信息挤占了宝贵的上下文空间，导致AI无法看到更早的、更相关的代码或指令。

其次，操作效率的瓶颈。虽然Git本身很快，但CLI的输出渲染和解析有时会成为瓶颈，尤其是在需要频繁执行status、diff查看变更的场景。zagi通过优化输出管道和减少不必要的计算，宣称在已实现的命令上能有1.5-2倍的速度提升。

最后，工作流的不匹配。AI编程常常涉及“探索式开发”：针对一个问题，快速生成多个解决方案（例如，用Node.js实现一遍，再用Bun实现一遍），然后对比结果。用传统的Git分支管理这种方式非常笨重。此外，AI生成的提交信息往往包含元数据（如触发它的用户提示词），这些信息对于回溯和理解代码变更至关重要，但Git本身没有原生支持。

zagi的解决方案非常巧妙：它作为Git的一个“包装器”（Wrapper）或“别名”（Alias）运行。对于它已经优化过的命令（如status,log,diff），它直接处理并输出精简后的结果；对于它尚未实现的命令或复杂参数，它会无缝“直通”（Passthrough）给后端的原生Git执行。这样，用户获得了所有好处，却承担零风险——任何时候你都可以换回原生的git命令。

2.2 三大核心输出模式：适应不同场景

zagi的一个核心创新是提供了三种输出模式，这直接对应了不同的使用场景和消费者（人、AI、机器）。

1. 精简模式（Succinct - 默认）这是zagi的招牌功能，也是为AI优化最彻底的部分。它移除了所有装饰性文字，使用极简的符号和结构化的缩进来呈现信息。例如，git status不再输出 “On branch main” 和 “Changes to be committed:” 这样的引导句，而是直接展示分支名、暂存区状态和文件列表。这种格式信息密度高，Token利用率最大化，非常适合喂给AI助手。对于习惯了传统输出的开发者，可能需要几分钟适应，但一旦习惯，你会发现自己阅读效率也提高了。

2. 兼容模式（Compat）当你需要与团队共享命令输出，或者依赖某些脚本解析特定格式的Git输出时，兼容模式就派上用场了。使用git --compat [command]，zagi会生成与原生Git CLI完全一致的输出。这意味着你可以放心地在CI/CD脚本、代码审查工具或任何依赖特定输出格式的场景中使用zagi，而无需修改现有流程。这个设计体现了zagi的务实：优化但不破坏兼容性。

3. JSON模式（JSON）这是为自动化和工具集成准备的。使用git --json [command]，zagi会将结果以结构化的JSON格式输出。这对于编写脚本、与IDE插件集成、或将Git状态数据导入其他分析工具（如监控面板）非常有用。你可以轻松地使用jq这样的工具来过滤和查询提交历史、变更状态等信息，实现工作流的深度定制。

注意：默认的精简模式虽然高效，但可能会让一些依赖特定输出格式的周边工具（如某些Git GUI或自定义脚本）失效。如果你遇到这种情况，首先尝试使用--compat标志。如果问题依旧，那可能是该工具依赖了Git的某个非常具体的、zagi尚未实现的子命令或参数，此时zagi会直通给原生Git，通常也能解决。

2.3 性能与兼容性背后的技术选择

zagi使用Zig语言开发，这是一个注重性能、安全性和简单性的新兴系统编程语言。选择Zig而非Go或Rust，可能出于几个考量：首先，Zig可以生成极其轻量、无运行时依赖的原生二进制文件，这使得zagi的安装包非常小。其次，Zig对C语言的互操作性极佳，可以方便地链接Git的底层库（libgit2），或者直接调用Git子进程，为实现“直通”机制提供了便利。

项目宣称实现了121个Git兼容命令，并做到约50%更小的输出和1.5-2倍的速度提升。这些数据需要理性看待。“121个命令”很可能覆盖了最常用的子命令（add,commit,status,log,diff,branch,checkout等），但Git的命令体系非常庞大，一些边缘或复杂的命令组合可能仍在“直通”列表里。“50%更小的输出”在精简模式下是显而易见的，因为它移除了所有固定文本。“1.5-2倍更快”则可能源于：1）Zig本身的性能优势；2）更高效的输出生成逻辑，避免了Git内部一些为兼容性而存在的冗余步骤；3）更少的终端渲染开销（因为输出的字符数更少）。

在实际使用中，对于日常高频命令（如status,log -n 5），速度的提升是能感知到的，尤其是在大型仓库中。这种流畅感的提升，累积起来对开发体验的改善是显著的。

3. 核心功能深度解析与实操

3.1 安装与无缝集成：一步到位

zagi的安装过程设计得非常友好，力求对现有工作流零侵入。官方推荐的一键安装命令是：

curl -fsSL zagi.sh/install | sh

这个命令会完成以下几件事：

1. 从GitHub Releases下载对应你操作系统（macOS/Linux）和架构的最新版zagi二进制文件。
2. 将其安装到系统的可执行路径下（通常是/usr/local/bin）。
3. 最关键的一步：在你的Shell配置文件中（如~/.bashrc,~/.zshrc）为git命令设置一个别名（alias），将其指向zagi。

这意味着安装完成后，你在终端中输入的每一个git命令，实际上都是由zagi这个程序来处理的。这是实现“无缝替换”的核心。

实操心得：安装后务必重启你的终端（Terminal）或执行source ~/.zshrc（根据你的Shell）来使别名生效。我第一次安装时忘了这一步，输入git还是调用的原生命令，排查了一会儿才想起来。你可以用which git或type git来验证别名是否设置成功，如果显示git is aliased to zagi或类似信息，就说明成功了。

如果你喜欢从源码构建，步骤也很清晰：

git clone https://github.com/mattzcarey/zagi.git cd zagi # 确保已安装Zig 0.15+ zig build -Doptimize=ReleaseFast ./zig-out/bin/zagi alias

zig build会生成二进制文件，而最后的./zig-out/bin/zagi alias命令就是手动执行上述的别名设置步骤。

如何回退或临时使用原生Git？这是很多人关心的问题。由于zagi只是设置了一个Shell别名，因此你有多种方式切回原生Git：

1. 临时使用一次：使用命令的完整路径，如/usr/bin/git status。
2. 在当前会话中禁用：在终端执行unalias git（注意：这可能会影响其他依赖此别名的脚本）。
3. 永久卸载：从你的Shell配置文件中删除zagi添加的那行别名，并删除zagi二进制文件即可。你的原生Git完全不受影响。

这种别名机制的设计非常聪明，它将选择权完全交给了用户，且回退成本为零。

3.2 Fork功能：革命性的并行工作流管理

git fork是zagi中最让我眼前一亮的功能。虽然名字叫“fork”，但它与GitHub的Fork概念不同，实际上是基于Git的“工作树”（Worktree）功能构建的一个超强封装。Git Worktree允许你在同一个仓库的不同目录下检出不同的分支，这对于同时进行多个任务非常有用，但CLI操作起来有些复杂。

zagi的fork命令极大地简化了这个流程，并将其理念用于管理AI编程中的“多方案探索”。

基本操作：创建与切换

# 为“基于Node.js的方案”创建一个名为 nodejs-solution 的fork git fork nodejs-solution # 为“基于Bun的方案”创建一个名为 bun-solution 的fork git fork bun-solution

执行后，zagi会在当前仓库根目录下创建一个名为.forks/的隐藏文件夹，并在里面为每个fork创建独立的目录。每个目录都是一个完整的工作区，拥有独立的Git工作树，指向一个新的分支（分支名通常与fork名关联）。

你可以直接cd进入对应的目录进行开发：

cd .forks/nodejs-solution # 在此进行Node.js版本的编码，提交等操作 cd ../bun-solution # 在此进行Bun版本的编码，提交等操作

每个fork里的操作都是完全独立的，就像在两个独立的仓库克隆中工作一样，但它们共享同一个Git对象数据库，非常高效。

方案对比与决策当你完成了不同fork中的实验后，回到主仓库目录，可以轻松对比和决策：

# 列出所有fork及其最新的提交信息 git fork

这个命令会给出一个清晰的列表，显示每个fork的名称、对应的分支以及提交数量，让你一目了然。

决策时，你有两个选择：

1. --pick（挑选合并）：将某个fork的更改合并回主分支（或当前分支），并保留两个分支的历史。这类似于git merge，是一种非破坏性操作。

   git fork --pick bun-solution

2. --promote（晋升替换）：用某个fork的整个历史替换掉主分支的历史。这类似于git reset --hard加上强制推送，但更安全可控。这个操作会丢弃主分支上原有的提交，请谨慎使用。

   git fork --promote nodejs-solution

清理实验结束后，可以删除fork：

# 删除单个fork git fork --delete bun-solution # 删除所有fork git fork --delete-all

注意事项：fork功能依赖于Git的Worktree。如果你的仓库本身是一个Worktree（即你不是在“主工作树”中），git fork可能无法正常工作。此外，.forks/目录默认是隐藏的，不会被Git跟踪（通常已在.gitignore中），但其中的每个fork工作区里的内容是需要你自己管理的。在删除fork前，请确保你已经将需要的代码通过pick或promote进行了整合，或者已另行备份。

3.3 智能体模式：为AI协作而生

这是zagi区别于其他Git增强工具的核心。当你在Cursor、Claude Code、Windsurf或OpenCode等集成了AI的编辑器中使用终端时，zagi能自动检测到并启用“智能体模式”。你也可以手动启用：

export ZAGI_AGENT=my-agent-name

智能体模式解锁了几个关键特性：

1. 提示词追踪AI编程的本质是“用自然语言指令生成代码”。记录下生成某次提交的原始提示词（Prompt），对于后续理解“为什么这段代码长这样”至关重要。

git commit -m "添加用户退出功能" --prompt "在页面顶部导航栏添加一个醒目且符合Material Design风格的退出按钮"

通过--prompt参数，这个用户请求会被记录下来。之后，你可以使用git log --prompts来查看提交历史以及关联的提示词，这在进行代码审查或回溯决策过程时价值连城。

2. AI作者归属AI工具在提交时，可能会在提交信息中添加Co-Authored-By:行。zagi可以自动识别是哪个AI智能体（如Claude、ChatGPT）参与了提交。使用git log --agent可以过滤和查看特定AI的贡献。

3. 会话记录更强大的是，zagi可以记录一个完整的“会话”（Session），即从AI工具启动到结束的一系列操作和对话。通过git log --session可以查看这个完整的上下文流。这对于复现问题、理解AI解决问题的完整思路链条非常有帮助。

这些元数据存储在哪里？一个精妙的设计是，所有这些额外信息（提示词、智能体、会话）都不是直接塞进提交信息里污染历史的。zagi将它们存储在Git Notes中。Git Notes是一个内置的、用于为提交添加额外注解的机制，这些笔记存储在独立的引用（如refs/notes/agent）里。默认情况下，Notes只存在于本地仓库，不会通过git push推送到远程，因此不会影响团队协作。你也可以选择共享这些笔记，但这需要显式操作。

相关环境变量

• ZAGI_REQUIRE_PROMPT_COMMIT=1：设置此变量后，在智能体模式下，每次提交必须使用--prompt参数，否则提交会被拒绝。这强制养成了记录提示词的好习惯。
• ZAGI_STRIP_COAUTHORS=1：许多AI工具会自动添加Co-Authored-By:行。设置此变量后，zagi会在提交前自动移除这些行，保持提交信息的整洁。这个功能非常实用。

3.4 安全护栏：防止“手滑”灾难

我们都有过“手滑”的时刻：不小心执行了git reset --hard HEAD~1丢掉了未暂存的修改，或者git clean -fd删错了文件。zagi内置了一个可选的“安全护栏”机制。

export ZAGI_GUARDRAILS=1

设置这个环境变量后，zagi会拦截一些它认为“高危”的破坏性命令，例如：

• git reset --hard ...
• git push --force/git push -f
• git clean -f/git clean -fd
• git checkout -f ...

当尝试执行这些命令时，zagi会输出错误信息并阻止操作。

紧急情况下如何绕过？安全护栏不能阻塞真正需要进行的操作。zagi提供了覆盖机制：

1. 首先，你需要设置一个覆盖“密码”（本质上是一个令牌）：

   git set-override my-secret-token

2. 然后，在执行高危命令时，通过环境变量传递这个令牌：

   ZAGI_OVERRIDE=my-secret-token git reset --hard HEAD~1

这样，命令就会被放行。这个设计既提供了安全保护，又在必要时保留了控制权。

实操心得：建议在个人开发环境中长期开启ZAGI_GUARDRAILS=1，并将其写入Shell配置文件。对于团队共享的开发环境或CI/CD服务器，则需要谨慎评估，因为自动化脚本可能需要执行这些命令。覆盖令牌应妥善保管，避免泄露。这个功能让我想起了git config --global --add safe.directory之类的安全配置，但zagi的实现更直观、更主动。

4. 日常使用场景与命令对比

4.1 高频命令对比：从冗长到精炼

让我们通过几个最常用的命令，直观感受zagi带来的变化。假设我们在一个简单的项目仓库中。

场景一：查看状态 (git status)

• 原生Git输出:

  On branch main Your branch is up to date with 'origin/main'. Changes to be committed: (use "git restore --staged <file>..." to unstage) new file: src/utils/logger.ts Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: README.md Untracked files: (use "git add <file>..." to include in what will be committed) .env.local

  超过10行，包含大量指导性文字和重复的状态标题。

• zagi默认输出:

  branch: main staged: 1 file A src/utils/logger.ts modified: 1 file M README.md untracked: 1 file ? .env.local

  只有6行，使用A(新增)、M(修改)、?(未跟踪)等简洁标记，状态一目了然，信息密度极高。

场景二：查看提交历史 (git log --oneline -5)

• 原生Git输出:

  a1b2c3d (HEAD -> main) Fix null pointer exception in user loader e4f5g6h Update API endpoint documentation 7890i1j Merge pull request #42 from feat/add-search j2k3l4m Add search functionality with fuzzy matching m5n6o7p Initial project setup

  每行包含完整的短哈希和提交信息。

• zagi默认输出 (git log -5):

  a1b2c3d (2025-01-20) Fix null pointer in user loader e4f5g6h (2025-01-19) Update API docs 7890i1j (2025-01-18) Merge PR #42 j2k3l4m (2025-01-17) Add fuzzy search m5n6o7p (2025-01-16) Initial setup

  zagi省略了(HEAD -> main)这类信息（因为通常上下文已知），但增加了日期，并将哈希和日期放在更紧凑的格式里，同样更易扫读。

场景三：查看差异 (git diff)原生Git的diff输出是完整的Unix diff格式，包含很多@@ -1,5 +1,7 @@这样的上下文行。zagi的diff输出则进行了大幅精简，专注于展示具体的增删行，移除了冗余的上下文标记，使得在终端中阅读变更更加聚焦。

4.2 与现有脚本和工具的兼容性

这是评估任何Git增强工具能否投入生产使用的关键。zagi在这方面做得相当出色。

1. 对于依赖Git输出格式的脚本如果你的Shell脚本、CI/CD流水线（如GitHub Actions, GitLab CI）或自定义工具依赖于解析特定格式的Git输出（例如，git log --pretty=format:"%H|%an"），你有两种选择：

• 使用git --compat模式运行你的命令，确保输出与原生Git 100%一致。
• 如果脚本调用的是zagi尚未实现或直通的复杂命令组合，zagi会自动将其传递给原生Git执行，因此通常也能正常工作。

2. 对于IDE和GUI客户端大多数IDE（如VS Code, IntelliJ IDEA）和Git GUI客户端（如Fork, Sourcetree）通常不是直接调用系统git命令，就是使用内置的Git库（如libgit2）。对于前者，如果IDE使用的是系统PATH中的git，而你已经将其别名指向zagi，那么IDE也会享受到zagi的优化。对于后者，则不受影响。

注意：有些高级GUI工具可能会因为zagi的精简输出而无法正确解析状态。如果遇到问题，一个快速的测试方法是打开IDE的内置终端，执行git status看看输出是否是zagi格式。如果是，可以尝试在IDE的设置中指定原生Git的完整路径。

3. 别名与自定义配置如果你在~/.gitconfig中设置了大量的Git别名（alias），不用担心。zagi在接收到命令后，会先检查是否是自己的内置命令或扩展命令（如fork）。如果不是，它会将整个命令（包括别名展开后的结果）传递给原生Git。因此，你自定义的git st、git co等别名应该都能继续工作。

5. 高级技巧、问题排查与局限性

5.1 环境变量配置最佳实践

为了获得最佳且一致的zagi体验，建议将以下配置添加到你的Shell配置文件（~/.zshrc或~/.bashrc）中：

# 启用安全护栏，防止意外数据丢失 export ZAGI_GUARDRAILS=1 # 设置一个强密码作为覆盖令牌，请务必替换 'your-strong-secret-here' export ZAGI_OVERRIDE=your-strong-secret-here # 在智能体环境中，要求每次提交都必须附带提示词 export ZAGI_REQUIRE_PROMPT_COMMIT=1 # 自动移除AI工具添加的协作者行，保持提交历史整洁 export ZAGI_STRIP_COAUTHORS=1 # 如果你主要使用JSON格式进行脚本处理，可以设置默认输出为JSON # export ZAGI_DEFAULT_FORMAT=json

重要提示：ZAGI_OVERRIDE是一个秘密令牌，理论上不应该长期设置在环境变量中，因为这降低了安全护栏的意义。更安全的做法是：平时不设置ZAGI_OVERRIDE，仅在需要执行高危操作时，在命令前临时指定，如ZAGI_OVERRIDE=temp-token git reset --hard HEAD~1。上述配置中写入是为了方便演示，在实际生产环境中请根据安全习惯调整。

5.2 常见问题与解决方案

即使设计得再完善，在实际使用中也可能遇到一些小问题。以下是我在深度使用过程中遇到的一些情况及解决方法。

问题1：安装后git命令行为没有变化

• 症状：执行git --version显示的仍然是旧版本，或者输出格式没有变成zagi的简洁模式。
• 排查步骤：
  1. 检查别名是否生效：运行type git或alias git。期望输出是git is aliased to zagi或类似信息。
  2. 如果没有别名，检查你的Shell配置文件是否已加载。尝试source ~/.zshrc（或~/.bashrc）。
  3. 如果还没有，手动检查配置文件末尾是否有zagi安装脚本添加的行。如果没有，可以手动添加：alias git=zagi。
  4. 确认zagi二进制文件在PATH中：运行which zagi。

问题2：某些Git插件或包装脚本报错

• 症状：例如，某些项目自带的git-hook脚本、或像git-flow这样的扩展工具执行出错。
• 原因：这些脚本可能依赖非常特定的Git输出格式，或者调用了zagi尚未完美模拟的参数组合。
• 解决方案：
  1. 临时方案：在运行该脚本或命令时，使用git --compat模式。
  2. 永久方案：修改该脚本，在调用git命令时显式使用原生Git的路径，如/usr/bin/git。
  3. 如果错误发生在zagi的“直通”环节，可以尝试在GitHub上给zagi项目提Issue，说明具体命令和错误。

问题3：git fork命令失败，提示“not a git repository”或类似错误

• 症状：在仓库目录下执行git fork new-feature失败。
• 排查：
  1. 确认当前目录确实是一个Git仓库根目录（存在.git文件夹）。
  2. 确认当前仓库不是另一个Git工作树（Worktree）。zagi的fork功能本身基于Worktree，但不能在子Worktree中创建新的fork。你可以通过git rev-parse --is-inside-work-tree和git rev-parse --is-bare-repository来检查。
  3. 检查.forks/目录是否已存在且可能权限有问题。

问题4：智能体模式未自动启用

• 症状：在Cursor等编辑器中，git commit --prompt没有被记录，或者git log --prompts看不到信息。
• 排查：
  1. zagi通过检查特定的环境变量（如CLAUDECODE,OPENCODE）来检测是否在AI编辑器中。运行env | grep -E '(CLAUDECODE|OPENCODE|ZAGI_AGENT)'查看。
  2. 如果编辑器没有设置这些变量，你可以手动设置：export ZAGI_AGENT=cursor。
  3. 确认提交时使用了--prompt参数，并且提示词被正确记录到了Git Notes中。可以运行git notes --ref=prompt show <commit-hash>来验证。

5.3 当前版本的局限性

了解一个工具的边界和它了解其功能一样重要。zagi目前仍处于活跃开发阶段，有以下几点需要注意：

1. 命令覆盖度：虽然实现了121个命令，但Git的命令体系非常庞大（git help -a可以看到所有命令）。一些不常用或非常复杂的命令（如git bisect,git filter-repo等）可能仍处于“直通”模式。对于绝大多数日常开发，这已经足够。
2. 平台支持：目前官方主要支持macOS和Linux。Windows平台可能通过WSL2运行良好，但原生Windows支持可能有限或需要从源码构建。
3. 与其他Git扩展的交互：如果你使用了复杂的Git配置、多级别名、或者像git-lfs(大文件存储) 这样的扩展，需要测试兼容性。zagi的直通机制应该能处理大部分情况，但边界案例可能存在。
4. 输出格式的“锁入”：一旦你习惯了zagi的精简输出，再回头看原生Git的输出可能会觉得冗长。这本身不是问题，但如果你需要和团队分享命令行输出，可能需要切换回--compat模式，或者团队其他成员也需要适应。

6. 总结与个人使用体会

经过一段时间的深度使用，zagi已经成为了我开发环境中不可或缺的工具。它带来的效率提升是细微但持续的：更快的命令响应、更清晰的终端输出、以及fork功能对多任务并行开发的革命性简化。特别是与AI助手协作时，精简的输出意味着我可以将更多的终端历史上下文提供给AI，让它更好地理解项目状态。

我最欣赏的几点：

1. 无侵入性设计：通过别名实现替换，回退成本为零，这让我敢于在任何项目上尝试。
2. 务实的功能聚焦：没有试图做一个大而全的Git GUI，而是精准地优化了命令行交互中最痛的几个点：输出冗长、并行工作流管理复杂、AI协作元数据缺失。
3. 出色的用户体验：fork命令的抽象级别恰到好处，将复杂的Git Worktree概念包装成了直觉化的操作。安全护栏也是一个非常贴心的设计。

给新用户的建议：如果你是第一次使用，我建议采取以下步骤：

1. 先观察，后行动：安装后，先在你个人的一个非关键项目中使用几天。用git --compat和默认模式交替执行相同命令，感受输出差异。
2. 逐步启用高级功能：先熟悉默认的精简输出。然后尝试一两个git fork来管理你的某个功能的不同实现方案。最后，再在AI编程环境中尝试--prompt提交。
3. 善用--compat标志：当需要分享命令输出或运行不确定的脚本时，养成加上--compat的习惯，可以避免很多兼容性问题。
4. 关注项目动态：zagi是一个活跃的开源项目，新的功能和优化在不断加入。关注其GitHub仓库的Release，可以及时获得更新。

最后，zagi代表了一种趋势：我们的开发工具正在从“为人设计”向“为人机协作设计”演进。它没有改变Git的核心，而是优化了人与Git、以及人与AI通过Git交互的界面。对于任何身处现代软件开发流程中的工程师，尤其是积极拥抱AI编程助手的开发者来说，花一点时间了解和尝试zagi，很可能会为你带来意想不到的效率和体验提升。它的学习曲线非常平缓，而带来的回报却相当直接。