keifu：把 Git 提交图搬进终端的系谱浏览器
Git 谱系，解开。用于以颜色和清晰度导航提交图的 TUI。
秒懂
- 它是什么？
- keifu 是一个用 Rust 写的 Git 提交图 TUI，主打彩色分支、鼠标操作和窄终端适配。它刻意不做完整 Git 客户端，只覆盖日常分支与提交操作，适合在终端里快速切换分支、查看提交脉络的人。
- 适合谁用？
- keifu 适合那些常年在终端里工作、需要在多个分支间快速切换的开发者，尤其是 vibe coding 风格下并行开分支的场景。它不适合需要复杂暂存、交互式 rebase 或完整 Git 功能的人，也不适合在纯文本终端（无 Unicode 线框）里使用。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 47 天前。
- 用什么语言写的？
- 主要是 Rust（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是 git log --graph 的阅读痛点
git log --graph 的输出在分支一多时就变成一团乱麻，线条交错、颜色单一，很难一眼看出当前分支的位置。keifu 把提交图渲染成带每条分支独立颜色的 Unicode 图形，配合提交详情、文件变更统计和 diff 视图，让阅读提交历史变成一件更直观的事。它面向的是那些在终端里工作、又不想为了看提交图而打开 GUI 工具的人。keifu 的定位很明确：它不是一个完整的 Git 客户端，只支持基本的操作，如 checkout、stage、commit、push，刻意保持简单。
数据流与界面机制：500 条提交的限定视图
keifu 在启动时从当前目录自动发现 Git 仓库，并加载最多 500 条提交，覆盖可见分支。这个上限意味着超大仓库的历史不会全部载入，但足以应付日常的分支查看。界面分为提交图、提交详情、文件列表和 diff 视图几个面板，用 Tab 切换焦点。提交图按分支着色，多个分支指向同一提交时，标签会折叠成 main +2 的形式，按 h 或 l 可以在同提交的不同分支间切换。文件变更统计显示在详情面板，diff 视图带语法高亮和词级变更强调。远程分支默认显示，按 o 可以隐藏，隐藏后仅由远程分支可达的提交也会被排除。
安装与启动：三个途径，一条命令
keifu 可以从 crates.io 安装：cargo install keifu。也支持 mise 和 Homebrew：mise use -g github:trasta298/keifu@latest 或 brew install trasta298/tap/keifu。从源码编译则 git clone 后 cargo install --path .。运行方式是在 Git 仓库目录里直接执行 keifu，它会自动发现仓库。配置项集中在 docs/configuration.md，但 README 没有给出具体的配置键，需要自行翻阅文档。依赖要求很朴素：终端支持 Unicode 线框和颜色，fetch 和 push 需要系统里有 git 命令。
日常操作：从切分支到提交的快捷键地图
键盘操作覆盖了日常 Git 工作流。Enter 检出选中的分支或提交，b 在选中提交创建分支，d 删除本地分支，f 从 origin fetch，c 打开消息对话框提交暂存内容，p 推送当前分支。文件暂存是逐文件级别的，按 s 暂存或取消暂存选中文件，a 全暂存，u 全取消。提交只包含暂存的内容，等同于 git commit。搜索分支用 / 触发增量模糊搜索，支持上下选择。复制提交哈希或分支名用 y 和 Y，走 OSC 52 剪贴板协议。鼠标支持点击选择、双击打开 diff、点击状态栏提示执行动作，滚轮按面板滚动。
值得注意的边界行为与失败模式
keifu 有几个明确的设计限制，可能成为某些场景下的坑。合并提交的 diff 只对比第一父提交，初始提交则对比空树，这可能导致 diff 不完整。变更文件上限 50 个，超出部分不显示，二进制文件不显示行数统计。检出远程分支时，如果本地分支已存在但指向不同提交，会被强制更新到远程状态，这可能是危险操作。删除操作只对本地分支有效，fetch 和 push 必须配置 origin 远程。另外，Ghostty 终端的滚轮事件会一次滚动多行，README 建议调整 mouse-scroll-multiplier 来缓解。这些限制说明 keifu 更适合查看和轻量操作，而不是处理复杂的合并审查。
与 git log --graph 及 GUI 工具的取舍
keifu 的直接替代品是 git log --graph，但后者没有颜色区分分支，也没有交互式选择。另一个思路是使用 GUI 工具如 GitKraken 或 VS Code 的 Git 面板，但 keifu 的优势在于不离开终端，且不需要图像协议，任何支持 Unicode 的终端都能跑。相比那些工具，keifu 缺少 hunk 级暂存和交互式 rebase，这是它明确放弃的功能。如果你需要细粒度的暂存控制，keifu 不是合适的选择。反过来，如果你只是想在终端里快速看清分支结构并切换，keifu 的彩色图和鼠标支持比 git log --graph 舒服得多。
维护与升级成本：MIT 许可下的轻量依赖
keifu 采用 MIT 许可，代码托管在 GitHub，最新版本 v0.6.0 发布于 2026 年 7 月。安装方式决定了升级路径：cargo install 需要手动重新安装，mise 和 Homebrew 则各自管理版本。项目依赖 ratatui 作为 TUI 框架，这意味着升级 ratatui 时 keifu 可能需要同步更新。由于项目只支持基本 Git 操作，功能面窄，升级风险相对可控，但也没有看到自动升级机制。对于个人使用，cargo install keifu 后偶尔检查新版本即可。
编辑结论
keifu 适合那些常年在终端里工作、需要在多个分支间快速切换的开发者，尤其是 vibe coding 风格下并行开分支的场景。它不适合需要复杂暂存、交互式 rebase 或完整 Git 功能的人，也不适合在纯文本终端（无 Unicode 线框）里使用。采用前先确认你的终端支持 Unicode 线框和鼠标事件，并检查 Ghostty 的滚轮问题是否影响你的使用。若你只想要一个只读的提交图查看器，可以先用 git log --graph 对比一下，看 keifu 的彩色渲染是否真的值得多装一个工具。
社区笔记