Gitu: a Magit-style Git TUI for the terminal, built in Rust

What Gitu is for, and who should care

Gitu is a Git porcelain that lives in a terminal rather than in Emacs. The README describes it as "A Git porcelain *outside* of Emacs", inspired by Magit. That phrasing sets the audience: people who like Magit's interaction model, where you press a key to stage a hunk or open a commit view, but who do not want to run their Git workflow inside an editor.

The feature list is deliberately Magit-shaped. Staging and unstaging work at file, hunk and line granularity. Committing supports commit, amend and fixup. Rebasing covers elsewhere, abort, continue, autosquash and interactive. There is fetching, logging for the current or another branch, pulling and pushing to the configured upstream or pushDefault, resetting at soft, mixed and hard levels, reverting commits, and stashing with save, pop, apply and drop.

This is not a general-purpose Git client that tries to expose every command. The README says Gitu "aims to implement many of the core features of Magit over time", which is an honest statement about scope: the list above is what exists now, and the rest is future work. If your daily workflow depends on a Git feature that is not on that list, Gitu is not the tool for that task yet.

How the TUI maps to Magit keybinds and Git state

The interaction model is a keybind layer over Git operations, with keys that "try mimic Magit, while staying Vim-like". Pressing h opens a help menu, and the README notes that the menu can be shown permanently by setting general.always_show_help.enabled = true in the config file. For anyone coming from Magit, that help menu is the fastest way to find where a familiar binding moved.

The parts of the implementation that are visible from the repository are the dependencies. Gitu is written in Rust and links libgit2 through the git2 crate with default features disabled, so repository access does not shell out to the git binary for those operations. The UI layer uses crossterm. Configuration is parsed with figment and toml, and the CLI is built with clap plus clap_complete, which is what backs the completion generation command. Syntax highlighting in the commit and diff views comes from tree-sitter grammars: the Cargo.toml lists parsers for Rust, TOML, JavaScript, C, JSON, C++, Ruby, Haskell, Go, C#, Python, TypeScript, Bash, PHP, Java, Scala, OCaml, HTML and Elixir. A notify dependency suggests filesystem watching, and arboard is present for clipboard access, with the wayland-data-control and windows-sys features selected.

One consequence of the tree-sitter list is build weight. Compiling Gitu from source pulls in a large set of grammar crates, several of them pinned with exact versions, which is worth knowing before you expect a quick cargo install on a slow machine.

Installing Gitu and making a first commit

The README points to docs/installing.md for install instructions and notes that Gitu is available from package managers; the packaging status badge links to the project's Repology page, which is the place to check whether your distribution has a package. Shell completions are generated by the binary itself. The README gives this command:

gitu completion <shell>

Replace <shell> with your shell name to print a completion script.

If you build from source instead, the repository is a Cargo project, so the standard Cargo workflow applies: clone the repository and run cargo install --path . from its root, or cargo build --release and run the binary from target/release/gitu. The Cargo.toml declares the package name as gitu and the version as 0.43.0.

Configuration lives in a TOML file. On Linux and macOS the README gives the path as ~/.config/gitu/config.toml, and on Windows as %USERPROFILE%\AppData\Roaming\gitu\config.toml. The README directs you to src/default_config.toml for the default configuration, which is the file to read before writing your own. A minimal edit that matches a documented key looks like this:

[general.always_show_help]
enabled = true

With that set, the help menu stays visible instead of appearing only after pressing h.

Editor behaviour is controlled by environment variables. The README states that VISUAL, EDITOR and GIT_EDITOR are checked in that order. Commit messages are opened by Git in GIT_EDITOR, but if you want file edits to go to a different editor, set VISUAL or EDITOR accordingly. For a first real use, open a repository in your terminal, run gitu, stage a hunk, write a commit message in the editor that opens, and confirm the result with git log in a second terminal.

Where Gitu stops short

The README's feature list is the boundary. It covers staging, showing, branching, committing, fetching, logging, pulling, pushing, rebasing, resetting, reverting and stashing. It does not mention submodules, worktrees, bisect, blame, reflog browsing, patch export or Git LFS. None of those are promised, and for many teams at least one of them is part of normal work.

There is also a platform gap in the documentation. The README gives config paths for Linux, macOS and Windows, so Windows is not excluded, but the install section defers entirely to docs/installing.md and the package manager badge, and the README itself does not describe a Windows install path. If you are on Windows, check that document before assuming a package exists.

The editor chain is a real source of confusion. Because VISUAL, EDITOR and GIT_EDITOR are checked in a fixed order, a machine with a stale EDITOR exported in a shell profile will send Gitu's file edits somewhere unexpected while Git still opens GIT_EDITOR for commit messages. That split is intentional per the README, but it means two different editors can appear in one session. Verify the environment before blaming the tool.

Gitu compared with lazygit and the plain git CLI

The obvious comparison is lazygit, which appears in the related searches for this project. Both are terminal Git clients, and both are standalone binaries rather than editor plugins. The difference is the interaction model: Gitu's keybinds are explicitly modelled on Magit, with a Vim-like flavour, while lazygit follows its own panel-based scheme. If your muscle memory comes from Magit, Gitu's bindings will feel closer to what you already do; if it comes from lazygit, the reverse is true. Gitu's README also notes that it aims to implement core Magit features over time, so it is explicitly a partial port in progress, not a feature-complete replacement.

The other comparison is doing nothing and staying with the git command line. Gitu's advantage there is granularity: staging a single line or hunk without git add -p's interactive prompt, and seeing log, status and rebase state in one screen. The cost is that anything outside the documented feature list sends you back to the shell anyway, and you now have two mental models to keep straight. For a workflow that is mostly git commit -am and git push, a TUI adds a layer without removing many keystrokes.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-08-22. Releases are frequent: v0.43.0 on 2026-07-11, v0.42.0 on 2026-05-22 and v0.41.0 on 2026-03-11, which is roughly a release every two months. The version in Cargo.toml matches the latest release, so the source tree and the published version stay in step. A CHANGELOG.md and a cliff.toml are present at the repository root, and the Makefile runs git cliff --unreleased as part of its test target, so release notes are generated rather than hand-written.

Gitu is MIT licensed. That is permissive: you can use, modify and redistribute it, including in commercial settings, provided the licence text and copyright notice are preserved. Nothing here is legal advice; read the LICENSE file in the repository for the actual terms.

The upgrade cost is mostly the pre-1.0 version number. At 0.x, minor releases can change configuration keys or keybinds, and the README's default config file is the reference for what a given version expects. Because the project ships often, a config written against 0.41.0 may need a look after a jump to 0.43.0. Checking CHANGELOG.md before upgrading is the cheap step, and the Makefile shows the project's own test target runs cargo clippy with -Dwarnings and cargo fmt --check, so the codebase is held to a lint standard even while the interface is still moving.

Editorial conclusion

Adopt Gitu if you already think in Magit's keybinds and want them in a plain terminal, or if you want hunk and line staging without leaving a TUI. Do not adopt it if you need a GUI, a Windows-first workflow, or features outside the README's list such as submodule or worktree management, because the README does not claim them. Before committing, run gitu in a scratch repository, press h to read the help menu, and confirm that the editor Gitu opens for commit messages is the one you expect from VISUAL, EDITOR or GIT_EDITOR.

Frequently asked questions

Official sources

1. altsem/gitu on GitHub
2. Issues
3. License: MIT
4. README
5. Releases