Skip to content
Go back

gitui vs lazygit: Two Git TUIs Compared

By SumGuy 10 min read
gitui vs lazygit: Two Git TUIs Compared

You’ve Got Forty Tabs Open and Git Is Still in the Way

You’re three hours into a feature branch. You’ve got a staging commit that has three unrelated changes in it, a stash you forgot about, and you cannot remember if you already pushed fix/auth-token or just imagined it. git log --oneline --all --graph prints forty lines of spaghetti and you need to cherry-pick exactly one commit.

This is where people start reaching for a GUI. And honestly? Fair. But opening GitKraken or GitHub Desktop feels like hiring a forklift to move a box of cereal. You just want something in the terminal that isn’t git flags stacked four deep.

Enter gitui and lazygit — the two Git TUIs that actually get used in the wild. They’re both fast, keyboard-driven, and live in your terminal where you’re already working. They’re also pretty different once you dig in.

Let’s figure out which one is worth installing on the machine you do real work on.


What You’re Getting Into

lazygit has been around since 2018. It’s written in Go, it’s mature, it has a massive feature surface, and it has opinionated opinions about your workflow. Current release as of mid-2026 is 0.44.x. It’s the one people mean when they say “I use a TUI for git.”

gitui is younger, written in Rust, and released as 0.27.x in 2025. It’s faster to start, simpler in scope, and has a more “just show me the diff” philosophy. If you’ve seen it recommended on r/rust or in Helix editor discussions, that’s why.

Both are available via pretty much every package manager:

Terminal window
# lazygit
brew install lazygit
# or
sudo apt install lazygit # Ubuntu 24.04+
# gitui
brew install gitui
# or
cargo install gitui

They’re both single binaries. No dependencies to babysit.


The First Thirty Seconds

Open lazygit with lg (alias it, trust me) in any repo and you get a five-panel layout: files, branches, commits, stash, reflog. It’s a lot of real estate. Navigation uses h/l for panels and j/k within them — Vim muscle memory ports directly.

Open gitui with gitui and you get a cleaner two-section view: staged/unstaged on the left, diff preview on the right. Tab switches between files, commits, stashing, and log views. It’s quieter. Less happening on screen at once.

Neither one has a learning cliff in the traditional sense — you can fumble through both on day one — but they’re solving slightly different problems.

lazygit wants to be your complete Git interface. gitui wants to get out of your way while you stage and commit.


Staging and Committing

This is where most people spend most of their time, so let’s start here.

lazygit

In lazygit, files panel on the left. Press space to stage a whole file. Press e to open in your editor. Press enter to see the diff and then use space on individual hunks. It’s smooth once the keybinds are in your fingers.

Committing: press c in the files panel, type your message, hit enter. Done. If you want to amend, press A. If you want to commit with --no-verify (we don’t judge), it’s C then an option in the modal.

The hunk staging is where lazygit shines for day-to-day work. You can select specific lines within a hunk using visual mode (v) and stage exactly those lines. This is the feature that makes you feel like you have superpowers at 2 AM when you need to split a commit that got away from you.

gitui

gitui’s staging workflow feels more like a refined git add -p. You see unstaged files, you move to the diff pane with Tab, you press 1 to stage a hunk or 2 to stage just selected lines. Press c from the staging area to commit.

It’s genuinely fast. The Rust foundation shows — no perceptible lag on large repos. On a repo with 80k+ commits, scrolling the log in gitui is instant. lazygit can stutter a little on the initial load for monster repos.

For committing, gitui keeps it simple. No fancy modal options for --no-verify, no reword-in-place for old commits. You commit, you push, you move on.

Winner for staging complexity: lazygit.
Winner for raw speed and simplicity: gitui.


Branching and Merging

lazygit

The branches panel is where lazygit earns its reputation. You can:

The interactive rebase (i) is honestly the killer feature. You get a visual representation of the commit graph, you can squash/fixup/reword/drop commits by pressing a letter, and you can drag commits to reorder them. That last one. Drag to reorder. In a terminal. It just works.

gitui

Branching in gitui is present but pared down. Create, checkout, delete — the basics are there. You won’t find interactive rebase in gitui. What you get instead is a clean log view that lets you tag commits and compare branches visually without the extra ceremony.

If your workflow involves a lot of git rebase -i sessions — squashing before PRs, cleaning up a branch before merge — lazygit is the better tool, full stop.

Winner for branching and rebase workflow: lazygit by a comfortable margin.


Configuration

lazygit

lazygit config lives at ~/.config/lazygit/config.yml. It’s YAML and it’s deep. You can theme it, rebind every key, define custom commands that run shell scripts, set per-repo overrides, and configure how it handles push/pull behavior.

Here’s a minimal config to get dark mode and a saner git log format:

~/.config/lazygit/config.yml
gui:
theme:
activeBorderColor:
- green
- bold
selectedLineBgColor:
- reverse
nerdFontsVersion: "3"
git:
paging:
colorArg: always
pager: delta --dark --paging=never
log:
order: "topo-order"
showGraph: always

If you use delta for diffs (and you should — cargo install git-delta), lazygit integrates with it cleanly. That config above will pipe all diffs through delta with syntax highlighting. It’s the kind of setup that makes git diff feel embarrassing by comparison.

gitui

gitui config is a TOML file at ~/.config/gitui/key_bindings.ron for keybindings and theme.ron for theming. The format is Rusty Object Notation (RON) which is… fine. It’s readable but you won’t find a million blog posts with copy-paste configs for it.

A basic key rebind looks like this:

(
open_help: Some(( code: F(1), modifiers: "")),
move_left: Some(( code: Char('h'), modifiers: "")),
move_right: Some(( code: Char('l'), modifiers: "")),
move_up: Some(( code: Char('k'), modifiers: "")),
move_down: Some(( code: Char('j'), modifiers: "")),
)

The default keybinds aren’t Vim-style, which is slightly annoying. The above fixes that. You’re doing this config edit on day one.

Winner for configurability: lazygit.
Winner for config that just works out of the box: neither, but gitui is simpler to understand.


The Things Each One Gets Wrong

lazygit’s problems

It can be too much. If you open lazygit to stage two files and push, you’ll find yourself ten minutes later doing an interactive rebase you didn’t plan on, accidentally exploring reflog, and rebinding keys. This is a feature to some people and a trap to others.

The startup time isn’t bad — usually under 100ms — but on a cold system with a very large repo it can feel sluggish compared to gitui’s essentially instant open.

Custom commands are powerful but the docs for them are written for people who already know what they want to do. Figuring out the right {{.SelectedLocalBranch.Name}} template variable requires reading the source code comments or the GitHub discussions.

gitui’s problems

No interactive rebase is a real limitation for people who squash commits before every PR. You’re back to the terminal for that workflow, which somewhat defeats the purpose of having a TUI.

Remote management is minimal. You can fetch and push, but managing multiple remotes, renaming them, pruning stale branches — you’re dropping to the command line for that too.

The documentation is thin. The README covers installation and the feature list, but if you hit a weird behavior there’s not much written about it. The issue tracker is helpful but requires digging.


Performance Reality Check

On a mid-sized repo (Node.js project, ~3k commits, ~400 files):

Metriclazygitgitui
Cold start~120ms~40ms
Log scroll (500 commits)smoothinstant
Large diff render (5k lines)slight lagfast
Memory at idle~30 MB~15 MB

These numbers are approximate and depend heavily on your machine, but the pattern holds: gitui is the faster tool. lazygit is fast enough that it won’t bother you unless you’re on an older machine or in a genuinely massive monorepo.


Who Should Use Which

Here’s the honest breakdown:

Use lazygit if:

Use gitui if:

Use both if:

That last one is not a joke. Some people use gitui for the fast stage-commit loop and drop into lazygit when they need to do branch surgery or interactive rebase work. Both binaries are small enough that this doesn’t feel wasteful.


Quick Start Aliases

If you install lazygit, alias it immediately:

Terminal window
# ~/.bashrc or ~/.zshrc
alias lg="lazygit"
alias lgg="lazygit -p $(git rev-parse --show-toplevel 2>/dev/null || pwd)"

For gitui, it’s short enough already, but:

Terminal window
alias g="gitui"

Yes, just g. You’re typing it constantly.


The Bottom Line

lazygit is the more powerful tool. If you’re a developer who lives in git — feature branches, PR review cycles, rebasing before merge — it’ll fit into your workflow faster than you expect and the keybinds will feel obvious within a week. The interactive rebase alone is worth the install.

gitui is the faster, simpler tool. If you’ve been putting off trying a Git TUI because you don’t want another thing to configure and learn, gitui is the lower-friction entry point. It does the 80% of git work that occupies 95% of your time, and it does it very quickly.

The good news: there’s no wrong answer. They’re both single binaries, they don’t conflict, and switching between them costs nothing. Install lazygit first. If it feels like too much, try gitui. If gitui feels too limited, go back. You’re not committing to a strategy here, you’re just picking a tool.

Either way, you’re done typing git log --oneline --all --graph | head -30 into a terminal at 11 PM trying to find where that branch diverged.


Share this post on:

Send a Webmention

Written about this post on your own site? Send a webmention and it'll show up above once verified.


Next Post
Boundary vs Teleport

Discussion

Powered by Garrul . Sign in with GitHub or Google, or post anonymously.

Related Posts