Git Truck analyses a repository on your machine and shows it in the browser

Everything happens on the machine that runs it

Git Truck is described as a local, interactive visualization workspace for Git repositories, built for inspecting a codebase through structure, commit activity, authorship and history. The list of what it lets you do is short: browse and zoom into the repository structure, see who worked where, when and what they worked on, spot active areas of the codebase, and explore how the codebase changed over time.

The reasons it exists are stated as plainly as the features. It runs locally with no tracking, cloud storage, remote servers, ads or subscription, it works offline, and it works with any Git repository. Those three points are the design constraints that shape everything else in the project, and they are the reason to consider it when a repository cannot be sent to a hosted service.

The questions it claims to answer quickly are the ones a new contributor or an auditor actually asks. How is the repository structured, and where has the project been active recently, who has changed the most lines per file, and where and when have specific contributors worked. The README illustrates each of these with example images from another repository.

There is an academic dimension as well, which is unusual for a tool in this category. The README links a research papers repository under the same organisation, and the topics list includes git, nodejs, npm, repository and visualization. A tool that has published research behind its metrics is making a different claim from a tool that simply draws a treemap, and it is worth reading how the metrics are defined before you use them to judge a colleague.

The project is TypeScript, MIT licensed, and published to npm as git-truck.

The three dimensions are structure, activity and authorship

Breaking the feature list into its parts shows what the visualisation is actually built on, and each part has an obvious counterpart in the Git data model.

Structure is the file tree. The example screenshots in the README are captioned as a file type visualisation, and the feature list says you can browse and zoom into the repository structure. That is a treemap of the tree, which is where the file type colouring comes from.

Activity is the commit history over time, and the second example screenshot is captioned as the most changed files recently. This is the view that answers where the project has been active, and it is the one that turns a commit log into a picture of a codebase's hot spots.

Authorship is the third dimension, and it has two forms in the example images: a top churner view for who has changed the most lines per file, and a contributors metric for where and when specific contributors have worked. Churn by line count is a deliberately blunt measure, and it is worth remembering that a large diff is not the same as a large contribution, since reformatting and generated files distort it.

The three views interlock, which is the point of the tool. You zoom into a directory in the structure view, then look at which files under it are changing, then look at who is making those changes. That combination is what answers the ownership question in a code review or an onboarding session, and it is why the tool is a workspace rather than a single chart.

The advanced options are not in the README, which says to run git truck --help for them. The documentation site at git-truck.github.io/git-truck/docs is the feature overview to read next.

Installing the CLI and pointing it at a repository

The requirements are Node.js and Git, both linked from the README, and the install is a single global npm install:

npm install -g git-truck@latest

The at-latest suffix is in the command itself, which tells you the project's expectation that you want the newest published version rather than whatever a lock file pins.

With the CLI on your path, you move into the repository and run the command:

cd path/to/repository
git truck

Or you can pass the path directly, which is what a script would do:

git truck path/to/repository
git truck path/to/folder-with-repositories

The two path forms behave differently, and the difference is documented. When the path contains multiple repositories, Git Truck opens a repository browser. Otherwise it opens the visualisation in your default browser. So the same command either analyses one repository and shows it, or gives you a picker when you point it at a directory of repositories.

The project description also offers the zero-install path, npx -y git-truck, which runs the package without installing it. That is the quickest way to see whether the tool is worth installing.

The troubleshooting section lists two things worth knowing before you file a bug. If the browser does not open automatically, copy or click the URL from the terminal, which happens often in a headless or remote environment where the CLI cannot reach a desktop browser. And large repositories can take a little while to analyse the first time and may feel slow to navigate and interact with.

The CLI is a launcher for a React Router web app

The package.json makes the architecture plain. The published package is git-truck, MIT licensed, with the CLI entry point at ./cli.mjs exposed as a binary named git-truck, and the published files are LICENSE, README.md, build/, public/ and cli.mjs.

So the npm package is a static web application plus a small Node launcher. The build scripts show how it is produced: build-vite runs react-router build to produce the front end, and build-cli runs tsdown to bundle the CLI, with the full build running both under NODE_ENV=production. The start script runs node . with optional .env and .env.local files loaded, and the .env.example in the repository contains a single variable, LOG_LEVEL=debug.

The front end is a Vite and React Router application, with the configuration split across vite.config.ts, react-router.config.ts and the tsconfig variants. The UI itself is a separate concern from the analysis, which is why the public/ directory is shipped as a static asset directory alongside build/.

There is a second way to run it that matters for containerised environments. The repository has a Dockerfile, a run-with-docker.sh script and a .devcontainer directory, so there is a supported path for running the tool inside a container where opening a browser on the host needs a forwarded port. The Dockerfile is small: it starts from node:18, installs some shell tools including git, sets a working directory of /usr/app and runs npm install git-truck inside the image, so the container carries the tool rather than the host.

The repository also ships an e2e suite with Playwright, a playwright.config.ts and unit tests with vitest, and the test script runs the e2e suite first and the unit tests second, with a build step before the e2e run.

Versions move fast: 5.0.0 in the tree, v4.0.0 published

The release history shows how quickly this project moves. The visible tags are v3.0.0 on 2026-02-26, v3.3.0 on 2026-03-10 and v4.0.0 on 2026-05-28, and the repository is not archived with the last push on 2026-10-12.

But the package.json in the repository says version 5.0.0, and the npm install command in the README pulls git-truck@latest. The combination means the published package and the tagged release are not the same thing right now: the tree has moved past the last tag, and the npm latest may be either the v4 line or a 5.x prerelease depending on what the maintainers published. The scripts give a hint, since pub-pre runs npm version prerelease followed by npm publish with the next tag, so prerelease versions are published to a dist tag rather than to latest.

For an interactive tool that a person runs on demand, that ambiguity matters less than it would for a library. For a script that runs in CI, it matters a lot, and the answer is to pin an exact version rather than use the at-latest form in the README.

The supporting files are worth a look before you build on it. The repository has a CHANGELOG.md, a REQUIREMENTS.md, an AGENTS.md and a CLAUDE.md, a CONTRIBUTING.md, a .changeset directory for release notes, and a docs directory that holds the example images the README links to. The REQUIREMENTS.md and the changelog are the two documents to read first if you want to know what a given version actually does.

Licensing is MIT with the LICENSE file at the root, which is the simplest possible case for a tool you install globally on a work machine and a permissive one for anyone who wants to embed the visualisation in an internal dashboard.

Editorial conclusion

Git Truck suits a maintainer or reviewer who needs to understand an unfamiliar repository quickly, or who wants to show a colleague who changed which parts of a codebase, since the analysis runs on your machine and the visualisation opens in your browser without an account. It is the wrong tool for a continuous metric feed, for a service that exposes repository analytics to many users, or for a very large monorepo where the first analysis is slow, because the README warns that large repositories take a while to analyse the first time and can feel slow to navigate. Before adopting it for CI, read REQUIREMENTS.md and the CHANGELOG.md, and note that the package.json carries version 5.0.0 while the most recent published release is v4.0.0 from 2026-05-28, so pin deliberately rather than tracking whatever latest resolves to.

Frequently asked questions

Official sources

1. git-truck/git-truck on GitHub
2. License: MIT
3. Project website
4. README
5. Releases