gitpane - 在终端里集中查看多个 Git 仓库

如果你只维护一个仓库，git status、lazygit 或 gitui 已经足够。但很多开发者的真实工作区并不是这样：一个产品拆成多个服务，一个客户项目配一组仓库，一个工具链同时有 CLI、Web、文档和部署脚本。问题不在于某个仓库里发生了什么，而是“我现在到底在哪些仓库里留下了未提交、未推送或未同步的状态”。

今天推荐的 affromero/gitpane 就是为这个场景做的。它是一个 Rust 写的终端仪表盘，会扫描指定目录下的多个 Git 仓库，在一个 TUI 里展示分支、dirty 状态、ahead/behind、worktree、stash、变更文件和提交图。当前 GitHub API 显示项目约有 98 stars、0 forks，许可为 MIT；crates.io 上的最新版本是 0.7.1。

项目概览

属性	详情
仓库	affromero/gitpane
Stars	约 98
Forks	0
主要语言	Rust
许可	MIT
crates.io 最新版本	0.7.1
创建时间	2026 年 2 月 24 日

它解决的是工作区级别的问题

很多 Git TUI 都擅长处理单个仓库：暂存 hunk、看 diff、处理 rebase、解冲突。gitpane 的重点不一样，它更像是工作区的总览层。

启动后，gitpane 默认扫描 ~/Code，也可以用 --root 指定目录。左侧是仓库列表，中间是当前仓库的变更文件，右侧是提交图和提交详情。仓库列表里会直接显示当前分支、是否有未提交改动、是否 ahead 或 behind、worktree 数量、stash 数量和文件变更数量。你不需要在十几个目录里来回 cd，先扫一眼就能知道哪里需要处理。

这种视角对几类人尤其有用：

• 同时维护多个微服务或内部工具的开发者；
• 经常在多个开源仓库之间切换的人；
• 用 git worktree 做并行开发或 AI agent 沙箱的人；
• 需要在下班前确认“没有把脏状态留在某个角落”的人；
• 想把 lazygit、gitui 这类单仓库工具前面再加一层总览的人。

三栏界面为什么实用

README 里展示的主界面是三栏布局：仓库、变更、提交图。这个设计的好处是信息密度比较高，但每一栏又对应一个明确的问题。

仓库栏 回答“哪个仓库需要注意”。它会显示 dirty 标记、ahead/behind 箭头、worktree 计数、stash 计数和变更数量。对多仓库工作区来说，这比逐个运行 git status 更接近真正需要的入口。

变更栏 回答“这个仓库改了什么”。选中仓库后，变更文件会直接列出来，按 Enter 可以打开 split diff。这样你可以先判断是临时文件、依赖锁文件，还是确实有需要提交的业务变更。

提交图 回答“这个仓库最近发生了什么”。gitpane 会展示最多 200 条提交，并支持搜索提交信息、作者和短 hash。它不是要取代完整的 Git 日志分析工具，但足够帮助你在工作区总览里快速定位分支状态。

worktree 感知是一个加分点

近两年越来越多开发流程会用 worktree：一边修主线问题，一边保留实验分支；或者让多个 AI 编码代理分别在独立 worktree 里跑任务。传统的单仓库视图很容易只看到当前目录，而忽略同一个仓库挂着多少并行工作区。

gitpane 会把 linked worktrees 计数显示出来，并可以展开查看。这一点很符合现在的开发现实：真正需要管理的不是单个 checkout，而是一个仓库在多个并行上下文里的状态。

实时刷新和操作入口

gitpane 使用 filesystem watcher 监听变化，README 里提到状态会在大约 500ms 内更新。它还支持右键上下文菜单，可以对仓库执行 push、pull、rebase 等操作，并用明确的 origin <branch> 形式处理远端分支。

这些能力让它不只是一个静态列表。你可以把它开在终端里，当成多仓库工作区的仪表盘：改动发生后自动刷新，看到 ahead/behind 后直接处理，发现遗漏仓库后重新扫描或手动添加。

当然，越靠近 Git 写操作，越要保持谨慎。我的理解是，gitpane 最适合作为“发现问题和进入上下文”的入口；真正复杂的 rebase、冲突解决或批量提交，仍然应该在你熟悉的 Git 工具里完成。

配置方式

gitpane 通过 TOML 配置根目录、扫描深度、固定仓库、排除目录、刷新频率和主题。默认配置会扫描 ~/Code，如果你的仓库结构更深，例如 ~/src/github.com/owner/repo，就需要把 scan_depth 调高。

一个典型配置大概是这样：

root_dirs = ["~/Code", "~/work"]
scan_depth = 3
pinned_repos = ["~/Code/important-project"]
excluded_repos = ["node_modules", ".cargo", "target"]

[watch]
debounce_ms = 500
poll_local_secs = 5
poll_fetch_secs = 30

它还支持内置主题和自定义主题。对长期驻留终端的工具来说，主题不是装饰问题，而是能不能舒服地看一整天的问题。

安装与使用

如果已经装了 Rust，最直接的方式是：

cargo install gitpane

然后运行：

gitpane
gitpane --root ~/projects

README 也提供了面向 macOS、Linux 和 Windows 的预构建二进制说明。需要注意的是，GitHub Releases 与 crates.io 的版本节奏可能不完全等价；如果你要在团队里统一使用，最好明确安装来源和版本。

需要注意的地方

gitpane 仍然是一个很新的项目，适合试用，但在把它放进日常工作流前，建议注意几个边界：

• 多仓库扫描依赖目录结构和 scan_depth，第一次配置需要花点时间；
• linked worktree 或 submodule 的 .git 形态可能影响自动发现；
• push、pull、rebase 这类操作要确认当前仓库和分支，不要只看一眼图标就执行；
• 如果团队对 Git 操作有严格规范，建议先把它当只读仪表盘使用；
• crates.io 与 GitHub release 状态要分别确认，尤其是需要预构建二进制时。

这些限制不影响它的核心价值。它的价值不是把 Git 变成另一个复杂系统，而是把“我手上这堆仓库现在是什么状态”这件事变得更可见。

总结

affromero/gitpane 的定位很清楚：不是替代 lazygit、gitui 或命令行 Git，而是在它们前面加一个工作区总览。它让你先看到多个仓库的分支、变更、远端差异和 worktree 状态，再决定进入哪个仓库处理。

如果你的开发目录里经常有一排仓库同时处于半完成状态，gitpane 值得试试。它把多仓库管理里最烦的第一步，也就是“先找出哪里有事”，压缩到了一个终端界面里。

项目地址：https://github.com/affromero/gitpane