git-graph：面向分支模型的 Git 命令行历史图工具

获取下载链全程约 1 分钟

打开微信，搜索「软件教程管家」关注，或长按下方二维码关注
回复关键词 git-graph
公众号自动回复网盘链接，点击即可保存下载

打开微信扫一扫关注
或搜索【软件教程管家】

分支一多，git log 的历史就成了一团乱线：谁从哪个分支切出来、哪个合并到底合了什么，光靠缩进和星号很难一眼看明白。git-graph 是一个面向分支模型的 Git 命令行历史图工具：它按 GitFlow 或你自定义的分支模型，把提交历史画成结构清晰的终端图，样式、颜色和提交信息格式都能自己定。本篇讲清它适合哪些仓库、怎么上手，以及动手之前必须先核对的几件事。

项目名称	git-graph
仓库地址	git-bahn/git-graph
开发语言	Rust
开源许可证	MIT
Star 数	约 1003（2026-11-13 实测）
最近更新	2026-11-12（仓库动态）
核心定位	面向分支模型的 Git 命令行历史图工具

项目介绍：历史图按分支模型画，而不是按提交堆出来

git-graph 不是又一个 git log 的换皮包装，它的出发点是“分支模型”：先告诉工具你的团队用 GitFlow 还是自定义模型，工具再按这个模型去归类每一次提交、每一次合并，画出来的图里分支归属一目了然。预定义模型开箱即用，团队有自己的分支规矩也可以写 TOML 配置文件定义模型、按名称调用，模型文件放在应用数据目录下的 git-graph/models 里。

它只做一件事：把历史讲清楚。输出完全在终端里，没有图形界面，不挑桌面环境；显示样式、颜色和提交信息格式都可以配置，包括只用 ASCII 字符的样式，在老终端、远程会话或需要把结果粘进文档的场合也能用。提交信息格式支持类似 git log –format 的自定义写法，想看作者、想看时间、想看短哈希，都由你决定。README 还提到，基于 git-graph 有一个交互式 Git 终端应用 git-igitt，需要在终端里直接操作提交时可以一并评估。

核心功能

按分支模型画历史图：直接在终端展示结构化的 Git 历史图，分支从哪里分、合到哪里去，图的形状本身就是答案。
预定义与自定义分支模型：支持 GitFlow 等预定义模型，也支持用 TOML 文件写自己的分支模型，按名称调用。
多种显示样式：提供多种终端样式，包括仅使用 ASCII 字符的样式，兼容性要求高的环境也能正常显示。
自定义提交信息格式：支持类似 git log –format 的自定义格式，图上每一行显示什么信息由你定。
颜色与样式可配置：终端颜色、线条样式可以按个人或团队习惯调整，长时间看图也不费眼。
三种分发路径：提供预编译二进制、Cargo 和 Homebrew 安装路径，按环境选一种即可。

适用场景对比

场景	推荐程度	理由
团队按 GitFlow 或固定分支模型协作，要经常审查复杂历史	优先选它	这正是项目的主场景：图按模型画，分支归属一眼可辨
想在终端里快速浏览仓库图谱，不想开图形客户端	优先选它	纯命令行输出，远程服务器、弱终端环境都能用
团队分支规则特殊，预定义模型套不上	优先选它	TOML 自定义模型按名称调用，规则可以随仓库版本管理
只要看一次提交列表，不关心分支结构	不必用它	git log 本身就够，为一张图多装一个工具属于多余
要在终端里交互式操作提交、变基、挑拣	先评估 git-igitt	git-graph 只负责展示，交互操作是姊妹项目 git-igitt 的事

一句话取舍：如果核心需求是终端里的结构化 Git 历史图、分支模型配置和可控的输出格式，优先选它；如果需求还包括交互式提交操作、多远程仓库支持，或者合并分类不受提交摘要约束，先读手册和源码确认能力，不要默认它全都覆盖。

上手步骤

按环境选一种安装路径：发布页有预编译二进制，也可以用 Cargo 或 Homebrew 安装，装完确认 git-graph 在 PATH 里，或在仓库目录中用完整路径调用。
先在小仓库跑一次默认图：进一个 Git 仓库目录直接运行 git-graph，对照 git log 看图的分支归属是否和你理解的一致，先建立信任再用到大仓库。
试一个预定义分支模型：如果团队用 GitFlow，先按预定义模型出图，确认 develop、feature、release、hotfix 各分支在图里的位置符合团队约定。
按需写自定义模型：预定义模型不够用时，在应用数据目录下的 git-graph/models 里写 TOML 模型文件，按名称调用，先拿一个分支少的仓库验证模型规则。
定好输出格式再日常用：提交信息格式按类似 git log –format 的写法配好，样式和颜色按终端习惯调好，顺手了再把它收进日常工作流。

自定义模型前先定好的 5 个要点

先确认团队的分支命名规矩：模型靠分支名和合并关系归类，命名不统一、分支名随意起，模型再准也画不准，先对齐规矩再写配置。
合并提交的摘要行不要改：工具依赖合并提交的摘要信息对合并分支分类，改了摘要等于拆了分类依据，图会错位。
自定义模型文件要进版本控制：TOML 模型是团队资产，放进仓库或 dotfiles 管理，换电脑、换成员都不用重新发明一遍规则。
先在小仓库验证模型再推广：模型规则写错不会报错，只会画错图，拿分支少的仓库逐条验证，确认无误再用到主仓库。
样式先按最弱终端配：团队里有人用老终端或远程会话，先确认 ASCII 样式在那台终端上显示正常，再考虑彩色样式。

注意事项

只支持主远程仓库 origin：项目目前只支持 origin 这一个远程仓库，多远程仓库的场景要先确认是否满足需求。
合并摘要是分类依据：合并提交的摘要行不应被修改，团队里习惯改合并信息的人要先统一这个约定。
Windows 下管道输出可能有编码问题：在 Windows PowerShell 中把输出通过管道写入文件时可能出现编码问题，README 建议改用默认 Windows 控制台。
它只展示，不操作：git-graph 不做提交、变基、挑拣这些交互操作，需要交互式终端操作时评估姊妹项目 git-igitt。
复杂仓库要先看手册：公开信息有限，更复杂仓库历史、特殊终端环境和边界分支模型的兼容性，需结合 README 手册或源码确认。

常见问题

它和 git log –graph 有什么区别？
git log –graph 按提交顺序画线，git-graph 按分支模型归类后再画图；分支模型固定的团队用 git-graph，图里的分支归属更明确。

一定要写 TOML 模型吗？
不用，GitFlow 等预定义模型开箱即用；只有团队分支规则特殊时才需要写 TOML 自定义模型。

自定义模型文件放哪里？
放在应用数据目录下的 git-graph/models 里，按名称调用；建议把模型文件纳入版本控制管理。

能在 Windows 上用吗？
能用，但注意 PowerShell 下管道写入文件可能有编码问题，README 建议改用默认 Windows 控制台。

没有图形界面是不是缺点？
看场景：要的是终端里快速看图、远程服务器上看图，命令行正是优势；要的是点鼠标操作提交，选 git-igitt 或图形客户端更合适。

适合谁，不适合谁

适合需要在终端审查复杂分支历史、比较不同分支模型，或希望用纯命令行方式查看 Git 图谱的开发者和团队，尤其适合按 GitFlow 或自定义分支模型协作、又不想为看一张图打开图形客户端的人。如果你每天都在终端里工作，分支一多就靠记忆硬扛，这个项目值得优先试用。

不适合的场景也很明确：只需要偶尔看一次提交列表的人用 git log 就够；需要在终端里直接操作提交的人先看 git-igitt；多远程仓库、合并摘要不受约束的场景，先读手册和源码确认能力再决定。

方案	起点	适合谁
git-graph	按分支模型画终端历史图，模型可自定义	按固定分支模型协作、常在终端审查历史的人
git log –graph	系统自带，零安装	偶尔看一次图、不关心分支模型的人
git-igitt	基于 git-graph 的交互式终端应用	要在终端里直接操作提交的人
图形 Git 客户端	点鼠标看图、拖拽操作分支	不喜欢终端、要图形化操作的人