GitUI and Git Worktree

What is GitUI?

GitUI is an open-source terminal UI for Git built with performance in mind. Written entirely in Rust, it provides a keyboard-driven interface for staging, committing, branching, diffing, and more. Its key strengths include:

• Speed: Benchmarks show it is significantly faster than other terminal Git UIs, especially on large repositories.
• Low resource usage: Minimal memory footprint compared to Electron-based Git clients.
• Intuitive keybindings: Context-sensitive keyboard shortcuts displayed at the bottom of the screen.
• Cross-platform: Runs on Linux, macOS, and Windows.

# Install GitUI

# macOS
brew install gitui

# Arch Linux
pacman -S gitui

# Cargo (any platform with Rust installed)
cargo install gitui

# Nix
nix-env -iA nixpkgs.gitui

# Windows (scoop)
scoop install gitui

Worktree Support Status in GitUI

As of early 2026, GitUI does not have a dedicated worktree management tab or built-in commands for creating, listing, or removing worktrees. Worktree support has been a requested feature in the GitUI GitHub repository, but it has not yet been implemented as a first-class feature.

That said, GitUI works correctly when launched inside an existing worktree directory. It will detect the repository, show the correct branch, and let you stage, commit, and push as usual. The limitation is that you cannot create, switch between, or remove worktrees from within the GitUI interface itself.

# GitUI works inside any worktree — just launch it from the worktree directory

# First, create a worktree using the CLI
git worktree add ../feature-branch feature/my-feature

# Then open GitUI inside that worktree
cd ../feature-branch
gitui

# GitUI will show the correct branch and working tree state

How to Work with Worktrees Alongside GitUI

While GitUI cannot manage worktrees directly, you can combine it with the Git CLI for a productive workflow. The approach is simple: use the command line for worktree operations and GitUI for everything else.

Recommended Workflow

Use a terminal multiplexer such as tmux or your terminal's tab feature to run a separate GitUI instance in each worktree. This gives you full GitUI functionality within each worktree while managing the worktrees themselves from the shell.

# 1. Create your worktrees from the CLI
git worktree add ../project-hotfix hotfix/urgent-fix
git worktree add ../project-feature feature/new-ui

# 2. Open a GitUI instance in each worktree (e.g., in separate tmux panes)

# Pane 1 — main worktree
cd /path/to/project
gitui

# Pane 2 — hotfix worktree
cd ../project-hotfix
gitui

# Pane 3 — feature worktree
cd ../project-feature
gitui

# 3. Manage worktrees from the shell when needed
git worktree list
git worktree remove ../project-hotfix

Shell Alias for Quick Access

Create a shell function that lists your worktrees, lets you pick one, and opens GitUI inside it:

# Add to your ~/.bashrc or ~/.zshrc

# Fuzzy-pick a worktree and open GitUI in it
gw() {
  local wt
  wt=$(git worktree list --porcelain \
    | grep '^worktree ' \
    | sed 's/worktree //' \
    | fzf --prompt="Select worktree> ")
  [ -n "$wt" ] && (cd "$wt" && gitui)
}

# Usage: just type 'gw' to pick a worktree and launch GitUI

GitUI vs Lazygit for Worktree Management

If worktree management is central to your workflow, the two most popular terminal Git UIs differ significantly in their support:

Lazygit has first-class worktree support with a dedicated tab for creating, switching, and removing worktrees. If worktree management from within the TUI is important to you, see our Lazygit worktree guide for a full walkthrough. GitUI remains an excellent choice if you prefer its speed and are comfortable managing worktrees from the command line.

Tips and Workarounds

• Use tmux or Zellij: Run a separate GitUI instance per worktree in different panes. This gives you visual separation and the ability to switch contexts instantly with a keybinding.
• Pair with fzf: Use the shell function shown above to fuzzy-select a worktree and launch GitUI in one command.
• Keep the main worktree clean: Use your main worktree only for stable branches. Create separate worktrees for feature work, bug fixes, and experiments.
• Watch for shared state: Remember that all worktrees share the same .git directory. Stashes and the reflog are shared across worktrees. Commits pushed from one worktree are visible in all others.
• GitUI respects gitdir: When you open GitUI in a linked worktree, it correctly follows the .git file pointer back to the main repository. You do not need any special configuration.
• Track the feature request:GitUI's worktree support is tracked on GitHub. Consider adding a thumbs-up to the relevant issue to signal demand for native worktree management features.

GitUI Setup and Configuration

GitUI is configured via a key_bindings.ron file for keybindings and a theme.ron file for theming. The config directory is ~/.config/gitui/ on Linux/macOS.

# GitUI key bindings file: ~/.config/gitui/key_bindings.ron
# Example custom keybindings (RON format)
(
    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: "")),

    stash_open: Some(( code: Char('l'), modifiers: "")),
    open_options: Some(( code: Char('o'), modifiers: "")),
)

Since GitUI does not have built-in worktree keybindings, you can complement it with shell aliases or scripts for worktree operations and keep GitUI focused on staging, committing, and browsing.