Skip to content
Shell & TerminalHow-To Published Updated 5 min readViews unavailable

How to Use a TUI Git Client

Setting up a terminal-based git interface for staging, committing, browsing history, and resolving conflicts visually without leaving the terminal.

A TUI git client gives you a visual, navigable interface over git’s staging area, commit history, and branches — genuinely faster than composing individual git commands for common day-to-day operations, without leaving the terminal for a full graphical git GUI.

Step 1: choose a TUI git client

lazygit   — extremely popular, highly visual, keyboard-driven
tig       — text-mode interface, especially strong for
            browsing history and diffs

lazygit tends toward a more complete, all-in-one interactive experience; tig leans toward being a fast, focused history/diff browser with lighter-weight staging support.

Step 2: install your chosen tool

# lazygit
brew install lazygit          # macOS
sudo apt install lazygit       # Debian/Ubuntu (check for a
                                # current version via the
                                # project's own install docs)

# tig
sudo apt install tig
brew install tig

Step 3: launch it inside a git repository

cd your-project
lazygit

TUI git clients operate on whatever git repository your current working directory belongs to — no separate configuration step needed to point it at a specific repo.

Step 4: stage and unstage files visually

lazygit: navigate to the "Files" panel →
  press Space to stage/unstage a specific file →
  press a to stage all

Seeing exactly which files are staged versus unstaged in a persistent visual panel, rather than repeatedly running git status, makes it considerably easier to build precisely the commit you intend.

Step 5: stage individual hunks within a file

lazygit: select a file → press Enter to view its diff →
  navigate to a specific hunk → press Space to stage
  just that hunk

Partial-file (hunk-level) staging — splitting unrelated changes in the same file into separate, logically coherent commits — is meaningfully easier to do correctly through a visual diff view than via git add -p’s line-by-line prompts alone.

Step 6: commit directly from the interface

lazygit: press c → type a commit message →
  confirm

Step 7: browse commit history and diffs

lazygit: navigate to the "Commits" panel →
  select any commit to view its full diff
tig: launches directly into a browsable
  commit history view by default

Visually browsing history with immediately visible diffs is often faster for understanding “what actually changed and when” than piecing it together from git log and separate git show commands.

Step 8: manage branches visually

lazygit: navigate to the "Branches" panel →
  create, checkout, merge, or delete branches
  directly from the list

Step 9: resolve merge conflicts through the interface

lazygit: conflicted files are flagged specifically →
  navigate into a conflict → select which side to
  keep for each conflicting section

Resolving conflicts through a structured visual interface, rather than manually editing conflict markers in a plain text editor, reduces the chance of accidentally leaving a stray conflict marker in the final resolved file.

Why a TUI git client is worth learning alongside the git CLI directly

The git command line remains the right tool for scripting and for operations you want fully explicit control over — a TUI client’s real advantage is making the state of a repository (what’s staged, what’s changed, how history branches) immediately visible and directly manipulable, which is exactly the kind of task that’s awkward to do well through individually-typed commands alone.

Where lazygit itself came from

Australian developer Jesse Duffield built the first version of lazygit in 2018, releasing it publicly on August 5 of that year — his own stated motivation was that certain git operations he used regularly (interactive rebase, stash management, worktrees) felt needlessly painful to drive purely through the command line, and he specifically wanted a Go project to practice with at the time he built it. What started as a side project grew into one of the most widely adopted terminal git interfaces available; Duffield has since stepped back from day-to-day maintenance to focus on his own startup, handing primary maintainership to long-time co-maintainer Stefan Haller.

Why tig’s pager-based design suits some workflows lazygit doesn’t

tig is built around being a fast, keyboard-driven pager over git’s own output rather than a full interactive application state machine the way lazygit is — this makes it noticeably lighter weight and often more responsive over a genuinely slow SSH connection, since it’s fundamentally closer to less piping through formatted git log output than to a full TUI application redrawing complex interactive state. If your primary need is fast, read-heavy history and diff browsing rather than active staging and conflict resolution, tig’s narrower focus can be the better fit specifically because it does less, not despite it.

Confirming which specific commit a staged change will actually attach to

Before committing through either tool’s interface, double-check the currently selected/highlighted commit context if you’re doing anything beyond a simple linear commit — both lazygit and tig support more advanced history operations (interactive rebase, fixup commits) where selecting the wrong target commit produces a confusing, hard-to-untangle result. The visual interface makes staging state easy to see, but it doesn’t eliminate the need to understand what git operation you’re actually about to perform before confirming it.

A third option built specifically for large-repository speed: gitui

gitui, also written in Rust, targets the same broad feature set as lazygit — staging, committing, branching, stashing — but is built around async rendering specifically to stay responsive on very large repositories, where benchmarks against repositories the size of the Linux kernel show it running roughly twice as fast as lazygit while using a fraction of the memory. The tradeoff is real: lazygit has broader support for advanced operations like interactive rebase, while gitui deliberately stays narrower and faster. If your day-to-day repositories are large enough that either lazygit or a graphical git client noticeably lags, and you don’t specifically need interactive rebase driven through the tool’s own interface, gitui is worth trying as the speed-optimized alternative.

Related:

Sources:

Comments