💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

1. The 2026 Modern Git Tool Map — CLI / TUI / GUI / Editor

Why the Git ecosystem grew so complex

When Linus Torvalds created Git in 2005, it was a simple distributed version control system. The command was git, the data lived in .git, and the UI was a single terminal line. By 2026, the Git ecosystem has fragmented into four major camps.

| Category | Representative tools | User profile |

| --- | --- | --- |

| CLI | git, gh, glab, tea | Standard users, CI/CD, automation |

| TUI | lazygit, gitui, tig | Terminal-centric developers, SSH workflows |

| GUI | Fork, Sublime Merge, GitKraken, GitButler, Tower | Visual workflow preference |

| Editor integration | magit (Emacs), vim-fugitive (Vim), VS Code Git | Users tied to a specific IDE |

| New models | jj (Jujutsu), Sapling | Experiments on the next generation of Git |

Why do new tools keep appearing

Git is extremely powerful, but also extremely hard. There are two distinct kinds of pain.

First, **conceptual complexity**. Git's index (staging area), detached HEAD, rebase conflicts, submodules — these consistently frustrate newcomers. A senior engineer at Toss once said, "I have used Git for 10 years and I still google git reset --hard vs git reset --soft every time." That was only half a joke.

Second, **workflow shifts**. The rise of monorepos brings huge PRs, large teams create review queues, and developers regularly work on multiple features at once. Many of these scenarios were not part of Git's original assumptions.

So the 2026 tools have evolved beyond "prettier UI." They reinterpret Git's data model (jj, Sapling), enforce new workflows (GitButler's virtual branches, Graphite's stacked PRs), or compress frequent commands into one screen (lazygit, gitui).

How this guide is organized

This guide covers every major 2026 Git tool across 18 chapters. For each tool, we keep the same four-part structure.

1. What problem does it solve

2. How it works (data model or UX)

3. Who uses it (real company adoption)

4. When you should not use it

2. Git 2.46-2.50 — Incremental Core Evolution

Major changes summary

From Git 2.46 (August 2024) through 2.50 (mid 2025), the Git core evolved through accumulation rather than dramatic redesign.

| Version | Release | Key changes |

| --- | --- | --- |

| 2.46 | 2024-08 | New git config subcommands (get/set/unset), reftable backend stabilization |

| 2.47 | 2024-10 | Default-branch messaging cleanup, patch-mode improvements |

| 2.48 | 2025-01 | reftable as a default option exposed, sparse-checkout perf improvements |

| 2.49 | 2025-03 | name-rev output format unification, fetch.pruneTags stabilization |

| 2.50 | 2025-06 | Various bug fixes, sideband protocol message cleanup |

The point is not a single big feature. Instead, infrastructure like **reftable** (new reference storage backend), **sparse-checkout**, **partial clone**, and **commit-graph** is being polished to be more stable and faster.

reftable — A ref backend for huge repos

Traditionally, Git stores refs (branches, tags) as files under .git/refs/. Simple, but slow when you have tens of thousands of branches in a monorepo.

reftable, first implemented in Google's JGit, stores refs in a single compressed binary file. It has been stabilizing since 2.46, and in 2026 you enable it like this.

git init --ref-format=reftable myrepo

For huge repos like Chromium or Android, commands such as git fetch and git branch become dozens of times faster.

sparse-checkout and partial clone

Two core monorepo features.

git clone --filter=blob:none --sparse https://github.com/org/monorepo.git

cd monorepo

git sparse-checkout set apps/frontend libs/shared

This combination does two things.

- partial clone (--filter=blob:none) — do not download file contents up front; fetch on demand

- sparse-checkout — only check out the two listed directories into the working tree

Together you can clone a 100GB repo in 5 minutes and keep only the directories you actually look at on disk. Microsoft, Google, and Meta all use this internally.

Other commonly used new features

- git switch / git restore — present since 2.23, but in 2026 they are the standard over git checkout. switch is for branches, restore is for files.

- git maintenance — background GC and auto fetch managed without cron.

- git column — auto-columns the output of git branch and git tag.

- git range-diff — compares two series of commits (great for diffing before/after a rebase).

3. lazygit (Jesse Duffield) — The TUI Standard

What it solves

lazygit is a Go-based terminal UI Git client started by Jesse Duffield around 2018. In 2026, it is effectively the standard tool for Git in the terminal.

Plain Git CLI does not show "what am I doing right now" at a glance. You have to run git status, git log, git diff, git branch separately to piece together the full picture. lazygit displays all of them in a single screen.

Screen layout

When you launch lazygit you see five panels.

+--------------+------------------+

| Status | Files |

+--------------+------------------+

| Branches | Commits |

+--------------+ Diff |

| Stash | |

+--------------+------------------+

- Status — current branch and remote sync state

- Files — changed files (stageable)

- Branches — local and remote branches

- Commits — recent commits (cursor navigable)

- Stash — temporarily stored changes

- Diff — the diff of the currently selected item

Key bindings

| Key | Action |

| --- | --- |

| space | Stage/unstage a file |

| c | Commit (opens a message dialog) |

| P | Push |

| p | Pull |

| s | Stash |

| r | Start an interactive rebase |

| z | Undo previous action |

| ? | Help |

The r (interactive rebase) is especially powerful. In plain Git you run git rebase -i HEAD~5 and then type pick/squash/edit by hand in a text editor. In lazygit you select a commit and press s for squash, e for edit, d for drop.

Config file

Settings live in ~/.config/lazygit/config.yml.

gui:

showFileTree: true

showRandomTip: false

language: en

git:

autoFetch: true

paging:

colorArg: always

pager: delta --paging=never

commit:

signOff: true

keybinding:

universal:

quit: q

Setting paging.pager to delta gives you colorful, side-by-side diffs.

Who uses it

Toss, Kakao, Mercari — many infra and platform engineers who SSH into servers default to lazygit. Even GUI-editor users (VS Code, JetBrains) often pop open lazygit when they need a big interactive rebase.

Limits

- Startup time grows on very large repos (1M+ commits)

- Some colors and Unicode glyphs glitch on Windows terminals

- Mouse support is limited (typical for TUI)

4. gitui — The Rust TUI Alternative

Differences from lazygit

gitui is a Rust-based TUI Git client created by Stephan Dilly, first released in 2020. It has a 5-panel layout similar to lazygit. The two biggest differences:

| Item | lazygit | gitui |

| --- | --- | --- |

| Language | Go | Rust |

| Backend | Shells out to git CLI | Uses gitoxide / libgit2 directly |

| Startup speed | Normal | Very fast |

| Memory | Normal | Low |

| Interactive rebase | Powerful | Basic only |

The core selling point of gitui is **speed**. Instead of forking out to the git CLI, it reads .git directly through native Rust libraries, so even huge repos feel instant.

Keybindings

Similar to lazygit but slightly different.

| Key | Action |

| --- | --- |

| 1-5 | Switch panels |

| s | Stage |

| u | Unstage |

| c | Commit |

| t | Tag |

| g | Log |

| h | Help |

Who uses it

Linux kernel developers, the Rust community, and people who simply do not need lazygit's interactive-rebase machinery. There is an interview where some Mercari infra engineers say they prefer gitui for the light footprint.

When to skip it

- You frequently need complex interactive rebases (lazygit wins)

- You need deep integration with hooks, submodules, and LFS

5. gh CLI (GitHub) + glab (GitLab) + tea CLI (Gitea)

The rise of hosting CLIs

Git itself is decentralized, but virtually every team uses a central host like GitHub, GitLab, or Gitea. Yet for years, creating a PR, reviewing, and triaging issues all had to happen in the web UI. So each host shipped an official CLI.

| --- | --- | --- | --- |

| gh | GitHub | Go | brew install gh |

| tea | Gitea | Go | brew install tea |

gh CLI core commands

Create a PR (from the current branch)

gh pr create --title "feat: add user search" --body "Closes #123"

List PRs

gh pr list --author "@me" --state open

Check out a PR locally

gh pr checkout 456

Review a PR

gh pr review 456 --approve

Create an issue

gh issue create --title "Bug in login" --label bug

View GitHub Actions runs

gh run list

gh run view 12345 --log

The gh pr checkout 456 command is especially handy. It is equivalent to the following.

git fetch origin pull/456/head:pr-456

git switch pr-456

A must-have when reviewing a PR locally.

gh API — generalized GitHub API calls

gh api repos/OWNER/REPO/pulls/123/comments

The above pulls PR comments as JSON. Replace OWNER and REPO with the actual values.

glab — GitLab edition

GitLab has richer built-in CI/CD than GitHub, so glab adds extra commands.

glab ci view # Visualize the current pipeline

glab ci status # Run status

glab ci trace # Live logs

glab snippet create file.py

tea — Gitea

Gitea is a self-hostable alternative to GitHub/GitLab, often used inside corporate firewalls.

tea login add --url https://gitea.example.com

tea issue create --title "..." --description "..."

tea pulls list

Korea/Japan adoption

- Toss — GitHub Enterprise + heavy gh CLI usage

- Kakao — some teams on GitLab + glab

- Mercari — GitHub + gh CLI is the standard

6. jj (Jujutsu, Google) — A Git-Compatible New Model

Who made it

jj (Jujutsu) is a new version control system started by Martin von Zweigbergk at Google. It went public in early 2020 and is in partial use inside Google. The killer property is being **Git-compatible** — a jj repo can be pushed to GitHub, and an existing Git repo can be opened with jj.

Core differences vs Git

jj reinterprets Git's data model in several ways.

| Concept | Git | jj |

| --- | --- | --- |

| Working tree changes | Explicit stage/commit | Auto-accumulated into a working-copy commit |

| Branches | Emphasized (HEAD position) | De-emphasized (optional) |

| Conflicts | Must be resolved immediately | Can persist as saved state |

| History editing | rebase, amend, reset | Every change is equally editable |

| Identifier | 40-char SHA | change ID + commit ID |

Working copy as commit

jj's most jarring difference: **the working tree itself is a commit**.

In Git you edit a file, run git add, then git commit. In jj you edit a file and the current working-copy commit is automatically updated.

Initialize jj in an existing Git repo

jj git init --colocate

See changes (like git status)

jj status

Create a new change (NOT the same as git commit -m)

jj new -m "WIP: trying new approach"

Modify the change's message

jj describe -m "feat: add user authentication"

Log

jj log

Change ID — Decoupled from commit ID

In Git, git commit --amend or rebase changes the SHA, breaking any external references.

In jj every change has a **change ID** (permanent) and a **commit ID** (snapshot). Amend or rebase, and the change ID stays put while the commit ID rolls over.

jj log

@ kzqp 0a1b2c3 main | feat: user search

o mnop 4d5e6f7 fix: login bug

o qrst 8g9h0i1 initial commit

kzqp is the change ID. 0a1b2c3 is the commit ID.

Deferring conflicts

A Git rebase halts when it hits a conflict. jj instead **stores conflicts as state** — the rebase finishes, and you resolve the conflicts later at your leisure.

Who uses it

- Some teams inside Google

- Parts of the Rust community

- Early adopters curious about the next generation of Git

When to skip it

- Your team is comfortably entrenched in Git (cognitive load)

- You need deep GUI/TUI integration (jj integrations are still thin)

- You need absolute production stability (still pre-1.0)

7. Sapling (Meta) — Mercurial-Based In-House

Background

Meta (then Facebook) decided Git could not handle its giant monorepo (hundreds of millions of lines), and for a long time used an internal tool built on Mercurial. In November 2022 they open sourced it as **Sapling**.

Differences from Git

Sapling layers Meta's extensions on top of Mercurial UX.

| Item | Git | Sapling |

| --- | --- | --- |

| Base | Own model | Mercurial variant |

| Branch model | Explicit branches | Anonymous branches |

| Index | Has staging area | None |

| Large repos | Slow | Fast (EdenFS virtual filesystem) |

| GitHub integration | Native | sl pr command |

The sl command

Sapling's CLI is sl.

sl clone https://github.com/facebook/sapling

cd sapling

sl status

sl commit -m "feat: ..."

sl push

sl pr submit # Create GitHub PRs

sl pr submit is particularly interesting — it automatically splits your current stack of commits into a series of linked GitHub PRs. Five commits become five chained PRs (stacked PRs).

EdenFS

The differentiator is EdenFS, a virtual file system. A clone does not download every file; files are fetched lazily on access. You can effectively "clone" a 100GB repo in a minute.

Who uses it

- Meta, internally (the main tool)

- Some teams running giant monorepos

- People testing "alternatives to Git"

Limits

- Limited integration with non-GitHub hosts

- Learning curve (you have to learn new, Mercurial-style commands)

8. GitButler — Tauri-Based Virtual Branch GUI

What it solves

GitButler is a new Git GUI started in 2023 by Scott Chacon, co-founder of GitHub and author of "Pro Git." Built on Tauri (Rust + webview), its standout feature is **virtual branches**.

The virtual branch concept

In a traditional Git workflow, when you want to work on multiple features at once you choose one of these:

1. Work on one branch and split the changes at commit time (hard)

2. Stash, switch branch, work, switch back (annoying)

3. Use worktrees for multiple working directories (disk hungry)

GitButler offers a fourth path. **Multiple virtual branches live inside a single working tree at the same time.** You drag file changes between virtual branches, and each branch can be pushed independently as its own PR.

The view

GitButler's GUI looks roughly like this.

+-----------------+ +-----------+ +-----------+

+-----------------+ +-----------+ +-----------+

You drag each file into the branch it belongs to.

Who uses it

- Solo developers juggling multiple features

- Full-stack developers who context-switch often

- People who want to split a big PR into smaller units

Limits

- Not deeply integrated into team workflows

- For reviewers it still just looks like a regular PR

- Some critics say it hides too much of Git's essence

9. Fork / Sublime Merge / GitKraken / GitHub Desktop — GUI

Four desktop GUIs compared

| --- | --- | --- | --- |

Fork

The most popular GUI for Mac users. Starts in under a second, has good graph visualization, and lets you do interactive rebase via drag and drop. The conflict resolver is especially good.

Sublime Merge

Built by Jon Skinner's team at Sublime HQ. Its main selling point is overwhelming speed — even huge repos feel smooth. It maps closely to CLI commands, which suits people who understand Git internals.

GitKraken

The flashiest UI of the bunch. Branch graphs, GitFlow visualization, Issue Board integration. Downsides: heavy and subscription-priced.

GitHub Desktop

GitHub's official client. The simplest of the four and great for newcomers. Lacks advanced features like interactive rebase or cherry-pick.

Who picks what

- Fork — senior Mac developers, designer collaboration setups

- Sublime Merge — Linux and Sublime Text users

- GitKraken — companies that value team-wide collaboration (shared visual graphs)

- GitHub Desktop — beginners, non-developers (PMs, designers)

10. Tower / SmartGit — The Other GUIs

Tower

Tower is a Mac/Windows GUI from Germany's fournova GmbH, around since 2010. Its strengths are a polished UI, deep Git integration, and great guides for learners. Roughly $69/year.

Highlights:

- Visual mapping for every Git command

- Direct pull-request workflow support (GitHub, GitLab, Bitbucket)

- Learning guides (step-by-step tutorials for Git beginners)

- Excellent conflict resolution UI

SmartGit

SmartGit is a Java-based, cross-platform GUI from Germany's syntevo GmbH. It works identically on Windows, macOS, and Linux, with very deep Git feature coverage.

Highlights:

- Supports Mercurial and Subversion as well

- Pull-request workflows

- Powerful built-in merge tool

- Free for non-commercial use

Who uses what

- Tower — design agencies on Mac, mixed beginner-senior teams

- SmartGit — Windows-centric enterprises, Java shops

11. magit (Emacs) — Git Magic

Introduction

magit is an Emacs Git interface started by Jonas Bernoulli in 2008. Many people say "you only truly understand Git after you use magit" — that powerful.

The core philosophy:

1. Expose every Git command as a key sequence

2. Show every possible action on a given screen as a popup

3. Make the most common action a single keypress

Sample screen

Running M-x magit-status in Emacs produces something like:

Head: main feat: add user search

Push: origin/main

Unstaged changes (3)

modified src/components/Search.tsx

modified src/lib/api.ts

new file src/utils/debounce.ts

Recent commits

abc1234 main feat: add user search (45 minutes ago)

def5678 fix: login bug (2 hours ago)

Pressing s stages a file, c opens the commit popup.

Commit popup

After c you get a popup like:

Commit

-a Stage all modified

-e Allow empty

-v Show diff

-n No verify

c Commit

e Extend

w Reword

a Amend

f Fixup

You toggle options and press c again to commit.

Who uses it

- Emacs users (naturally)

- Functional programming communities (Clojure, Haskell, Lisp)

- Senior developers who want to do everything from the keyboard

Limits

- Requires Emacs proficiency first

- Steepest learning curve of any tool here

12. vim-fugitive (Vim) — The Vim Git Standard

Introduction

vim-fugitive is a Vim Git plugin made by Tim Pope in 2009. Practically every Vim user has it installed.

Core commands

You drive it from inside Vim.

:Git status " git status output

:Git add % " Stage the current file

:Git commit " Open a commit message buffer

:Git push

:Git blame " Blame view of the current file

:Gdiffsplit " Diff the current file in a split

:GBrowse " Open the current line on GitHub/GitLab

:Git blame and :Gdiffsplit are particularly strong. From a blame view you hover on a line, press enter, and the diff of that commit opens in a new window.

vim-rhubarb

Frequently paired with vim-fugitive (also by Tim Pope) is vim-rhubarb, which adds GitHub integration. :GBrowse opens the current line on GitHub.

Who uses it

- Vim/Neovim users

- Keyboard-centric developers

- People who spend lots of time SSHed into servers

13. git-cliff (Rust) — Changelog Generator

Introduction

git-cliff is a Rust-based changelog generator by Orhun Parmaksız. It scans your commits to auto-build CHANGELOG.md.

How it works

git-cliff assumes:

1. Commit messages follow Conventional Commits (feat:, fix:, chore:, etc.)

2. Tags follow SemVer (v1.2.3)

Given those, it groups commits between tags into a structured changelog.

Usage

Install

brew install git-cliff

Generate changelog for all tags

git cliff -o CHANGELOG.md

Changelog for the next release

git cliff --unreleased --tag v1.2.0

Configuration

Configuration lives in cliff.toml.

[changelog]

header = "# Changelog\n"

body = """

[v_version] - v_date

[GROUP_LOOP]

group

[COMMIT_LOOP]

- commit_msg

[END_LOOP]

"""

[git]

conventional_commits = true

filter_unconventional = true

commit_parsers = [

{ message = "^feat", group = "Features"},

{ message = "^fix", group = "Bug Fixes"},

{ message = "^doc", group = "Documentation"},

{ message = "^perf", group = "Performance"},

{ message = "^refactor", group = "Refactor"},

]

Who uses it

- Rust projects (Cargo friendly)

- Teams that strictly follow Conventional Commits

- Teams pushing release automation

vs. semantic-release

semantic-release (JS ecosystem) automates changelog + version bump + npm publish. git-cliff focuses purely on changelog generation.

14. nbdime / git-lfs / git-annex / git-filter-repo — Other Utilities

nbdime — Jupyter notebook diff

Jupyter notebooks (.ipynb) are JSON, which makes plain git diff unreadable. nbdime presents human-readable diff/merge UIs.

pip install nbdime

nbdime config-git --enable --global

git diff notebook.ipynb # Now nbdime kicks in automatically

git-lfs — Large files

Files larger than 100MB committed directly to Git bloat the repo. Git LFS (Large File Storage) keeps large files in a separate store and leaves only pointers in .git.

git lfs install

git lfs track "*.psd"

git add .gitattributes

git add design.psd

git commit -m "design files"

git-annex

git-annex is a more extreme large-file management tool. It distributes file contents across multiple stores (S3, rsync, USB drives) and Git only tracks metadata. Great for scientific data and video — truly huge files.

git-filter-repo — Rewriting history

In the past you used git filter-branch to rewrite history, but it was slow and dangerous. git-filter-repo (by Elijah Newren) is the safe, fast replacement.

Completely remove a file from history

git filter-repo --path secrets.env --invert-paths

Keep only one path

git filter-repo --path src/

Rewrite email addresses

git filter-repo --email-callback 'return email.replace(b"@old.com", b"@new.com")'

Essential for cleaning up credential leaks and splitting monorepos.

15. Hooks — pre-commit / husky / lefthook / commitlint / Conventional Commits / semantic-release

Limits of plain Git hooks

Git itself has a hook system that runs shell scripts under .git/hooks. Two problems.

1. .git/hooks is not part of the repo (each person has to install hooks)

2. Shell scripts make complex logic painful

That is why hook frameworks emerged.

pre-commit (Python)

pre-commit is a Python framework by Anthony Sottile. You declare hooks in .pre-commit-config.yaml and pre-commit install drops them into .git/hooks.

repos:

- repo: https://github.com/pre-commit/pre-commit-hooks

rev: v4.5.0

hooks:

- id: trailing-whitespace

- id: end-of-file-fixer

- id: check-yaml

- repo: https://github.com/psf/black

rev: 24.3.0

hooks:

- id: black

- repo: https://github.com/astral-sh/ruff-pre-commit

rev: v0.3.0

hooks:

- id: ruff

husky (JS)

husky is the JS-ecosystem equivalent. It integrates with package.json.

npm install --save-dev husky

npx husky init

This creates a .husky/pre-commit script that you can fill with commands like npm run lint.

lefthook (Go)

lefthook is a Go-based hook tool by Evil Martians. It is faster than husky and supports parallel execution.

pre-commit:

parallel: true

commands:

lint:

glob: "*.{js,ts}"

run: npx eslint files_here

test:

run: npm test

commitlint + Conventional Commits

Conventional Commits is a spec for standardized commit message format.

feat: add user search

fix: handle null in login

chore: bump deps

docs: update README

refactor!: rename API endpoint

commitlint runs from the commit-msg hook to check that messages match the spec.

npm install --save-dev @commitlint/cli @commitlint/config-conventional

semantic-release

semantic-release analyzes your commit messages to automate:

1. Picking the next version (feat → minor, fix → patch, BREAKING → major)

2. Generating CHANGELOG.md

3. Creating a Git tag

4. Publishing the npm package

5. Creating a GitHub Release

Run it on every push to the main branch in CI and no human ever has to decide a version.

16. Stacked PRs — jj / Graphite / Sapling / GitButler

The big-vs-small PR dilemma

For reviewability, PRs should be small. But when a feature is large and you split it into small PRs, dependencies appear (PR-2 depends on PR-1 as its base).

GitHub's traditional PR UX handles dependent PRs poorly. When PR-1 lands, PR-2's base must move. If review feedback lands on PR-1, you have to rebase PR-2 too.

Stacked PR tools

| Tool | Approach |

| --- | --- |

| Graphite (CLI: gt) | External tool that manages stacks of GitHub PRs |

| Sapling (sl) | Stacks are first-class, sl pr submit auto-creates them |

| jj | Change IDs preserve identifiers across rebases |

| GitButler | Visual stacks via virtual branches |

Graphite (gt)

Graphite is a company and tool by Tomas Reimers. The CLI is gt.

gt create -m "feat: part 1"

Edit code, auto staged/committed

gt create -m "feat: part 2"

More code

gt submit # Push the entire stack as GitHub PRs

PR-2 automatically has PR-1 as its base. When PR-1 merges, PR-2's base shifts to main automatically.

Who uses it

- Meta and Google (Sapling/jj)

- Fast-moving startups (Graphite)

- Solo full-stack work (GitButler)

17. Korea / Japan — Toss / Kakao / Mercari Git Workflows

Toss

Toss uses GitHub Enterprise as the main host. Core workflow:

1. main branch is protected (PR + 2 approvals + green CI required)

2. Feature branches are short-lived (typically 2-3 days)

3. Squash merge is the default (simpler history)

4. Mandatory PR template with a "checklist" (deployment impact, rollback plan, monitoring)

5. CI is GitHub Actions plus an in-house build system

Tool adoption:

- Senior backend — lazygit + gh CLI primarily

- Frontend — VS Code Git + gh CLI

- Some SRE — vim-fugitive

Kakao

Kakao varies by business unit but generally uses GitHub Enterprise or self-hosted GitLab. Kakao Pay/Bank lean GitHub, while Kakao Ads/Search lean GitLab.

Highlights:

- Trunk-based development is rising (small PRs merging straight into main)

- Release branches only cut at fixed points

- Korean-language commit messages are tolerated (but PR titles must be clear)

- pre-commit hooks for lint and secret scanning

Mercari

Mercari is Japan-based but uses English as the official company language, with GitHub as the host.

Highlights:

- Conventional Commits strictly enforced (commitlint + husky)

- semantic-release automates version management

- Mixed monorepo + multi-repo due to microservice density

- PR review SLA is a KPI (first review within 24 hours)

- Sapling is being trialed by some teams

Cross-region trends

1. lazygit / Sublime Merge spreading quickly among senior engineers

2. gh CLI is now essential for PR review

3. pre-commit + commitlint is effectively the default

4. Stacked PRs are still early-adopter territory

18. Who Should Pick What — Beginner / TUI Lover / Monorepo / Big Team

Beginners

- GUI — GitHub Desktop (simplest, free)

- CLI — git + gh CLI

- Learning — Tower's guides, the Pro Git book, plain tools before magit

Terminal / SSH-centric users

- Main — lazygit

- Speed first — gitui

- Support — gh CLI, vim-fugitive (when editing in Vim)

Monorepo operators

- Git itself — sparse-checkout + partial clone are essentials

- Alternatives to try — Sapling, jj

- Large files — git-lfs, git-annex

- History rewrites — git-filter-repo

Large teams / company workflows

- Hosting — GitHub Enterprise + gh CLI

- Hooks — pre-commit + commitlint

- Release — semantic-release or git-cliff

- PR stacks — Graphite or Sapling

Solo / small full-stack teams

- GUI — Fork (Mac) or Sublime Merge (cross-platform)

- Virtual branches — GitButler worth trying

- Changelog — git-cliff

Emacs / Vim users

- Emacs — magit (essentially mandatory)

- Vim — vim-fugitive + vim-rhubarb

People exploring the next generation

- jj — Git-compatible, so adoption can be incremental

- Sapling — shines in giant monorepos

- GitButler — best for solo full-stack work

Final advice

Tools are tools. Understanding Git itself matters most. No matter which tool you use, these mental models must stick.

1. Commit = snapshot + parent reference

2. Branch = pointer to a commit

3. HEAD = pointer to your current position

4. Index (staging area) = the scratchpad for the next commit

5. What push/pull/fetch actually move across machines

Without these, lazygit/magit/Sapling will eventually corner you somewhere.

19. References

- Git official docs: https://git-scm.com/doc

- Git 2.46 release notes: https://github.com/git/git/blob/master/Documentation/RelNotes/2.46.0.txt

- lazygit (Jesse Duffield): https://github.com/jesseduffield/lazygit

- gitui (Stephan Dilly): https://github.com/extrawurst/gitui

- gh CLI: https://cli.github.com/

- glab: https://gitlab.com/gitlab-org/cli

- tea CLI: https://gitea.com/gitea/tea

- jj (Jujutsu, Martin von Zweigbergk): https://github.com/jj-vcs/jj

- Sapling (Meta): https://sapling-scm.com/

- GitButler (Scott Chacon): https://gitbutler.com/

- Fork: https://git-fork.com/

- Sublime Merge: https://www.sublimemerge.com/

- GitKraken: https://www.gitkraken.com/

- GitHub Desktop: https://desktop.github.com/

- Tower: https://www.git-tower.com/

- SmartGit: https://www.syntevo.com/smartgit/

- magit (Jonas Bernoulli): https://magit.vc/

- vim-fugitive (Tim Pope): https://github.com/tpope/vim-fugitive

- git-cliff: https://git-cliff.org/

- nbdime: https://github.com/jupyter/nbdime

- Git LFS: https://git-lfs.com/

- git-annex: https://git-annex.branchable.com/

- git-filter-repo (Elijah Newren): https://github.com/newren/git-filter-repo

- pre-commit: https://pre-commit.com/

- husky: https://typicode.github.io/husky/

- lefthook (Evil Martians): https://github.com/evilmartians/lefthook

- commitlint: https://commitlint.js.org/

- Conventional Commits: https://www.conventionalcommits.org/

- semantic-release: https://semantic-release.gitbook.io/

- Graphite: https://graphite.dev/

- Pro Git book (Scott Chacon): https://git-scm.com/book/en/v2