Install lazygit with apt on Ubuntu or Debian and you get a build nine minor releases behind upstream on Ubuntu 26.04, and sixteen behind on Debian 13. That’s old enough that the keybindings in current guides no longer match your screen, so the prebuilt binary from GitHub releases is the one to use there and on Fedora. Arch and Homebrew track upstream within days.
The gap matters now because the 0.66 line removed the separate staging panel, and delta needs a newer release to keep rendering in the new diff view. We cover the binary install, the Ubuntu snap and PPA traps, Fedora’s COPR, pacman and brew, then hunk staging, the new key map and the delta fix. Every Linux install and staging step below was run on Ubuntu 26.04 in October 2026 against lazygit 0.66.2, with Ubuntu 24.04, Debian 13, Fedora 45 and Arch package checks in containers on the same box, while the macOS steps follow Homebrew’s formula.
Install the Latest lazygit on Any Distro
Our binary route asks the GitHub releases API for the newest tag, so the same block installs whatever is current the day you run it and never needs editing when upstream ships. It also picks the right archive for x86_64 or ARM64 (64-bit Raspberry Pi OS, Graviton, Ampere) from uname -m. All you need is curl, tar and Git itself:
LAZYGIT_VERSION=$(curl -s "https://api.github.com/repos/jesseduffield/lazygit/releases/latest" | grep -Po '"tag_name": *"v\K[^"]*')
echo "Installing lazygit ${LAZYGIT_VERSION}"
ARCH=$(uname -m); [ "$ARCH" = "aarch64" ] && ARCH=arm64
curl -sLo lazygit.tar.gz "https://github.com/jesseduffield/lazygit/releases/download/v${LAZYGIT_VERSION}/lazygit_${LAZYGIT_VERSION}_linux_${ARCH}.tar.gz"
tar xf lazygit.tar.gz lazygit
sudo install lazygit -D -t /usr/local/bin/
rm -f lazygit lazygit.tar.gzWatch the echo line. The unauthenticated GitHub API allows 60 requests an hour per IP, so on a shared NAT or a busy CI runner it can come back empty, and then the download URL is missing its version, curl saves a 404 page instead of a tarball, and tar fails. If it prints Installing lazygit with nothing after it, wait or run it from another network. Then confirm which binary your shell finds:
lazygit --version
type -a lazygitOn the lab box the version line reports build source=binaryRelease, which separates it from the Ubuntu and Debian packages:
commit=63ab89fff478854deb4a35ef8902676b3cc5ca72, build date=2026-10-16T09:27:30Z, build source=binaryRelease, version=0.66.2, os=linux, arch=amd64, git version=2.53.0
lazygit is /usr/local/bin/lazygitThe Ubuntu, Debian, snap and COPR builds we tested print an empty commit and build source=unknown, so on those systems that field tells you which copy is running. Arch’s package and Homebrew set it at build time, so there it reads binaryRelease or Homebrew. Because /usr/local/bin comes before /usr/bin in the default PATH, the binary also wins over an apt copy installed later.
Install lazygit on Ubuntu 26.04 and 24.04
Ubuntu 26.04 carries lazygit in universe, so sudo apt install lazygit works without any third-party repository. Check what that would give you before you take it:
apt policy lazygitOn our lab server the candidate predates the staging rework.
lazygit:
Installed: (none)
Candidate: 0.57.0+ds1-1
Version table:
0.57.0+ds1-1 500
500 http://archive.ubuntu.com/ubuntu resolute/universe amd64 PackagesThat package works, but it is frozen for the life of the LTS, so it will never get in-diff staging, dark and light themes or the stacked-branch push. We ran both on the same server, archive candidate and binary side by side.
Ubuntu 24.04 has no package at all, and apt install lazygit stops with E: Unable to locate package lazygit. On 24.04 the binary from the previous section is the only maintained option, which is also what we would run on 26.04 if you want the workflow described further down.
Snap looks like a shortcut and is not one. The lazygit snap is published by a community packager, not upstream, and its stable channel has not moved since April 2022. It installs fine, but the binary reports version=unversioned, which tells you nobody is maintaining the build:
snap info lazygitStable and edge both point at the same four-year-old revision.
name: lazygit
summary: simple terminal UI for git commands
publisher: Daniel Jensen (danto7)
license: MIT
latest/stable: 0.34 2022-04-13 (25) 46.7MB -
latest/edge: 0.34 2022-04-13 (25) 46.7MB -If you already installed it, sudo snap remove --purge lazygit clears it before you switch to the binary. Leaving it is harmless, since /snap/bin sits at the end of the default PATH, but type -a lazygit would then list two copies and confuse the next person debugging it.
Error: “does not have a Release file” from the PPA
Plenty of older tutorials still say to add ppa:lazygit-team/release. On 26.04 add-apt-repository prints a 404 from its own refresh but still exits 0, and every apt update after that keeps failing, because the PPA never published anything for current Ubuntu releases:
Err:6 https://ppa.launchpadcontent.net/lazygit-team/release/ubuntu resolute Release
404 Not Found [IP: 185.125.189.187 443]
Reading package lists...
E: The repository 'https://ppa.launchpadcontent.net/lazygit-team/release/ubuntu resolute Release' does not have a Release file.Remove the dead source so apt stops failing, then use the binary:
sudo add-apt-repository -r -y ppa:lazygit-team/release
sudo apt updateAfter the removal, apt update finishes on the archive mirrors alone and /etc/apt/sources.list.d/ is back to just ubuntu.sources.
Install lazygit on Debian, Fedora and Arch Linux
Debian 13 ships lazygit in main, and sudo apt install lazygit works the same way as on Ubuntu. It is an even older build than Ubuntu’s, so on Debian the binary is the better choice for the same reasons.
Fedora has no lazygit in its official repositories, and dnf install lazygit on Fedora 45 fails with No match for argument: lazygit. Two COPRs fill the gap, and only one of them is current. The dejan/lazygit COPR had a native fc45 build of the latest release when we tested, so enable that one:
sudo dnf copr enable -y dejan/lazygit
sudo dnf install -y lazygit
lazygit --versiondnf pulls the package straight from the COPR, and the version matches upstream.
lazygit x86_64 0:0.66.2-1.fc45 copr:copr.fedorainfracloud.org:dejan:lazygit 22.8 MiB
Complete!
commit=, build date=, build source=unknown, version=0.66.2, os=linux, arch=amd64, git version=Skip atim/lazygit, which most older guides point to. Its newest build is still an fc43 package from the 0.47 line, so on Fedora 45 it installs a release from February 2025. A COPR is a third-party build service, so read the guide to COPR repositories on Fedora if you want to know how to audit or remove one later.
Arch is the easy one. The extra repository had the current release packaged, so pacman is all you need:
sudo pacman -S lazygitEach source below was checked on 24 October 2026 against the upstream release.
| Distro | Source | Version you get | Verdict |
|---|---|---|---|
| Any distro | GitHub binary | 0.66.2 | Current, use this |
| Ubuntu 26.04 | universe (apt) | 0.57.0 | Works, no in-diff staging |
| Ubuntu 24.04 | none | n/a | Binary only |
| Ubuntu (any) | snap | 0.34 (2022) | Abandoned, avoid |
| Debian 13 | main (apt) | 0.50.0 | Works, old |
| Fedora 45 | COPR dejan/lazygit | 0.66.2 | Current |
| Fedora 45 | COPR atim/lazygit | 0.47.2 | Stale, avoid |
| Arch | extra (pacman) | 0.66.2 | Current |
| macOS | Homebrew | 0.66.2 | Current |
Rolling sources (Arch, Homebrew, an active COPR) track upstream, while anything frozen at release time falls behind within months. If your distro is in the second group, the binary is less work than chasing a third-party repo.
Install lazygit on macOS with Homebrew
Homebrew’s formula tracks upstream releases, so on a Mac the install is one command:
brew install lazygitHomebrew updates itself before installing by default, so this can pull other upgrades along; the Homebrew auto-update guide shows how to switch that off. The one macOS difference worth knowing is the config path, ~/Library/Application Support/lazygit/config.yml, rather than ~/.config/lazygit/config.yml on Linux. Every config example in the rest of this guide uses the Linux path.
Open a Repository and Learn the Panels
lazygit works on the repository in your current directory, so change into one and start it:
cd ~/inventory-api
lazygitA one-time welcome popup appears on first launch, and Enter dismisses it. Behind it, the left column stacks five panels (Status, Files, Branches, Commits, Stash), and the main view on the right shows the diff or log for whatever is selected. In this lab repo one new file is staged and two files carry unstaged edits:
Number keys 1 to 5 jump straight to a panel, and Tab cycles through them. Up/Down or j/k move inside a panel, Left/Right or h/l switch panels, and ? opens the keybindings that apply where you are, which is the quickest way to learn the tool because the list changes per panel. Watch the Command log at the bottom right: it prints the exact Git command behind every keypress, so the first time you press Space on the / root row of the Files tree you’ll see git add -- . and know you just staged everything, not one file.
Stage Hunks and Lines in the Diff View
Since the 0.66 line there is no separate staging panel. Pressing Enter on a file in the Files panel now focuses the main diff view itself, puts a selection on the first hunk, and lets you stage from there with the diff renderer you configured. The old panel was limited to one file and always showed git’s raw diff, so this is a real improvement, but it also means every guide written before October 2026 describes keys that no longer exist.
A partial commit takes five keys, in this order.
- Select the file in the Files panel and press
Enter - Move between hunks with
LeftandRight, or between files withnandN - Press
ato switch to line-by-line selection when a hunk mixes changes - Press
Spaceto stage the hunk or lines - Press
cto commit straight from the diff view
In the lab, app.py had three unrelated hunks: a new MAX_ITEMS constant, a change to the health endpoint and a debug flag on app.run(). One Space on the first hunk moved only the constant into Staged changes, and the Files panel flipped the file to MM (partly staged):
Watch the Command log to see how it works. lazygit writes the selected hunk to a patch file and runs git apply --cached on it, so the result is identical to git add -p without the prompt loop. Tab jumps to the Staged pane, where Space unstages instead, and d discards the selected unstaged hunk (on a staged one it unstages), which matters because discarded work cannot be brought back with z. Pressing ? while the diff is focused lists the full key map for the view:
Two keys in that menu replace whole workflows from the old panel. Ctrl+g opens a list of every file in the diff so you can jump to one without leaving the view, and e opens your editor on the selected line, which beats hunting for the line number by hand. Esc takes you back to the Files panel when you are done.
lazygit Keybindings Worth Memorizing
These come from the keybinding menus of the tested release, cross-checked against the official keybindings reference. The same key often does different things per panel, so the panel column matters:
| Key | Panel | Action |
|---|---|---|
Enter | Files | Focus the file’s diff for hunk staging |
Space | Files / diff view | Stage or unstage the file / hunk / lines |
Left / Right | diff view | Previous / next hunk |
n / N | diff view | Next / previous file |
a | diff view | Toggle line-by-line selection |
Ctrl+g | diff view | Jump to a file in the diff |
c / A | Files | Commit / amend last commit |
p / P | global | Pull / push |
f | Branches | Fast-forward the selected branch |
s / f | Commits | Squash / fixup into the commit below |
Ctrl+j / Ctrl+k | Commits | Move commit down / up |
e | Commits | Start an interactive rebase here |
z / Z | global | Undo / redo via the reflog |
| | global | Cycle configured diff renderers |
: | global | Run a shell command |
? | global | Keybindings for the current panel |
Merge conflicts keep their own map: open the conflicted file, use Space to pick a hunk, b to keep both, and z to undo a resolution you regret. The f key on a branch learned a new trick in this line. It always fast-forwarded a branch that was only behind, and now when someone else rebased a branch you track, lazygit shows its divergence in a dimmer yellow and f fast-forwards that too, without a checkout. For the branching habits that make lazygit’s rebase tools pay off, the walkthrough on building features on a branch without touching main pairs well with this table, and the GitHub CLI cheat sheet covers the pull request side (o on a branch opens one from inside lazygit).
Fix delta and diff-so-fancy Rendering
In-diff staging needs to know which file and line each rendered row belongs to. With git’s raw diff lazygit works that out itself, but a renderer like delta rewrites the output, so lazygit relies on the renderer emitting OSC 1717 line metadata. Both delta and diff-so-fancy shipped it in early October 2026, while difftastic support exists only as an unmerged pull request you would have to build yourself. You need one of these renderer versions.
- delta 0.20.0 or newer
- diff-so-fancy 1.4.14 or newer
- difftastic built from the OSC 1717 pull request
Older renderers still work in the side panels, so the upgrade only matters once you stage from the diff. The renderer goes in the diffRenderers list, which replaced the old pagers list in the 0.64 line. Create the config directory and open the file:
mkdir -p ~/.config/lazygit
vim ~/.config/lazygit/config.ymlWe used exactly this config in the lab, where the {{colorScheme}} template passes dark or light from lazygit’s terminal detection to delta:
git:
diffRenderers:
- command: delta --{{colorScheme}} --paging=neverAdd more entries under diffRenderers if you want to switch between renderers, and | cycles through them inside lazygit. Save the file and restart lazygit so the new renderer is picked up.
delta rendering vanishes in the focused diff
With Ubuntu 26.04’s packaged git-delta, which is 0.18.2, nothing errors out. The Files panel preview renders with delta’s boxed hunk headers, but the moment you press Enter to stage, the main view drops back to plain diff --git output. Staging still works in that raw view, so the only symptom is that your renderer seems to vanish. diff-so-fancy older than 1.4.14 behaves the same way. Check the version first:
delta --versionAnything below 0.20.0 needs replacing. The Ubuntu 26.04 archive only carries the older build, so install upstream’s .deb, which picks the latest tag the same way the lazygit block does. The block downloads the amd64 package; on an ARM64 machine replace amd64 with arm64 in the file name:
DV=$(curl -s https://api.github.com/repos/dandavison/delta/releases/latest | grep -Po '"tag_name": *"\K[^"]*')
curl -sLo delta.deb "https://github.com/dandavison/delta/releases/download/${DV}/git-delta_${DV}_amd64.deb"
sudo dpkg -i delta.deb
rm -f delta.deb
delta --versiondpkg replaces the archive build in place, and the version check confirms it.
delta 0.20.1Restart lazygit after the upgrade. With delta 0.20.1 the focused diff keeps delta’s rendering, and Right then Space staged the second hunk of app.py exactly as it does with the raw diff:
On macOS, brew upgrade git-delta diff-so-fancy already gets both to versions that emit the metadata. On Arch, both packages were already new enough when we checked, and Fedora’s package metadata showed git-delta 0.20.1 in the Fedora 44 updates and rawhide, so a normal system update covers delta there. Fedora’s diff-so-fancy package was still older than 1.4.14, so diff-so-fancy users on Fedora need upstream’s release until the package catches up. Either way, check delta --version before blaming lazygit.
Keep lazygit Updated
Upstream tags a release every few weeks, and how you update depends on how you installed. Packages ride your normal system upgrades: sudo pacman -Syu on Arch, sudo dnf upgrade with the COPR enabled, brew upgrade lazygit on a Mac. A binary install has no package manager watching it, so re-run the block from the first section whenever you want the newest release, and it overwrites /usr/local/bin/lazygit in place. Read the release notes before a minor bump, because 0.66 showed that a single release can retire a panel you use every day. If lazygit is how you got comfortable with rebases and want the theory behind them, the Git books worth reading go deeper than any key map.
