Skip to content
Published on

モダン Git ツール 2026 — Git 2.46+ / lazygit / gitui / gh CLI / jj (Jujutsu) / Sapling (Meta) / GitButler / magit / vim-fugitive 深掘りガイド

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

1. 2026 年のモダン Git ツールマップ — CLI / TUI / GUI / エディタの 4 分類

Git エコシステムがここまで複雑になった理由

Linus Torvalds が 2005 年に Git を作ったとき、それは単純な分散バージョン管理システムでした。コマンドは git、データは .git ディレクトリ、UI は端末 1 行だけです。2026 年に入ったいま、Git を取り巻くツール群は 4 つの大きな陣営に分かれています。

分類代表ツール利用者プロファイル
CLIgit, gh, glab, tea標準ユーザー、CI/CD、自動化
TUIlazygit, gitui, tig端末中心の開発者、SSH 環境
GUIFork, Sublime Merge, GitKraken, GitButler, Tower視覚的なワークフローを好む
エディタ統合magit (Emacs), vim-fugitive (Vim), VS Code Git特定の IDE / エディタに依存する人
新しいモデルjj (Jujutsu), SaplingGit の次世代を試す層

なぜ新しいツールが出続けるのか

Git は非常に強力ですが、同時に非常に難しいです。痛みは大きく 2 種類あります。

1 つ目は概念的な難しさです。Git のインデックス (staging area)、detached HEAD、rebase の衝突解決、サブモジュールなどは、初学者を一貫して苦しめます。Toss のあるシニアエンジニアが「Git を 10 年使っても git reset --hard と git reset --soft の違いを暗記して使うのではなく、毎回検索する」と言ったのは、半分だけ冗談です。

2 つ目はワークフローの変化です。モノレポの増加で 1 つの PR に変更が膨らみ、大規模チームでレビューキューが滞り、1 人で同時に複数の機能を進める状況も日常になりました。Git の設計時には想定されなかったシナリオです。

そのため 2026 年のツールは「単にきれいな UI」を超えて、Git のデータモデルを再解釈したり (jj、Sapling)、新しいワークフローを強制したり (GitButler の仮想ブランチ、Graphite のスタック PR)、頻出コマンドを 1 画面に圧縮したり (lazygit、gitui) しています。

本ガイドの構成

このガイドは 18 章で 2026 年時点の主要 Git ツールを網羅します。各ツールは次の 4 つの軸で一貫して説明します。

  1. どんな問題を解くか
  2. どう動くか (データモデルまたは UX の観点)
  3. 誰が使うか (実企業の事例)
  4. いつ使うべきでないか

2. Git 2.46-2.50 — コアの段階的進化

主要変更のサマリ

2024 年 8 月の Git 2.46 から 2025 年中頃の 2.50 まで、Git コアは大規模なリデザインではなく累積的な改善で進化しました。

バージョンリリース主な変更
2.462024-08git config サブコマンド導入 (get/set/unset)、reftable バックエンドの安定化
2.472024-10デフォルトブランチ表示の整理、patch モード改善
2.482025-01reftable のデフォルトオプション公開、sparse-checkout 性能改善
2.492025-03name-rev 出力形式の統一、fetch.pruneTags の安定化
2.502025-06バグ修正、sideband プロトコルメッセージの整理

ポイントは大きな新機能ではなく、reftable (新しい参照保存バックエンド)、sparse-checkout、partial clone、commit-graph といったインフラがより安定して高速になっていくことです。

reftable — 巨大リポジトリ向け ref バックエンド

伝統的に Git は ref (ブランチ、タグ) を .git/refs/ 配下のファイルとして保存します。シンプルですが、ブランチが数万あるモノレポではディレクトリ走査が遅くなります。

reftable は Google の JGit で最初に実装された形式で、ref を 1 つの圧縮バイナリファイルに保存します。2.46 から段階的に安定化し、2026 年では次のように有効化できます。

git init --ref-format=reftable myrepo

Chromium や Android のような巨大リポジトリでは、git fetch や git branch が数十倍速くなります。

sparse-checkout と partial clone

モノレポ時代の 2 大機能です。

git clone --filter=blob:none --sparse https://github.com/org/monorepo.git
cd monorepo
git sparse-checkout set apps/frontend libs/shared

これは次を実行します。

  • partial clone (--filter=blob:none) — 最初はファイル内容を取らず、必要なときに取得
  • sparse-checkout — 作業ツリーには 2 つのディレクトリだけをチェックアウト

この組み合わせで 100GB のリポジトリを 5 分以内にクローンし、自分が見るディレクトリだけをディスクに置けます。Microsoft、Google、Meta が内部で活用しています。

よく使われるその他の新機能

  • git switch / git restore — 2.23 から存在しますが、2026 年では git checkout より標準になりました。switch はブランチ変更、restore はファイル復元です。
  • git maintenance — cron なしで GC と auto fetch を管理。
  • git column — git branch と git tag の出力を自動でカラム化。
  • git range-diff — 2 つのブランチシリーズの差分を比較 (rebase 前後の確認に便利)。

3. lazygit (Jesse Duffield) — TUI 標準

何を解くか

lazygit は Jesse Duffield が 2018 年頃に始めた Go 製ターミナル UI Git クライアントです。2026 年現在、端末環境で Git を扱うときの事実上の標準です。

従来の Git CLI は「いま自分が何をしているか」を一目で把握しにくいです。git status、git log、git diff、git branch を個別に走らせないと全体像が見えません。lazygit はこれらをすべて 1 画面に同時に表示します。

画面構成

lazygit を起動すると 5 つのパネルが現れます。

+--------------+------------------+
| Status       | Files            |
+--------------+------------------+
| Branches     | Commits          |
+--------------+ Diff             |
| Stash        |                  |
+--------------+------------------+
  • Status — 現在のブランチ、リモートとの同期状況
  • Files — 変更されたファイル (ステージ可能)
  • Branches — ローカル/リモートのブランチ
  • Commits — 直近のコミット (カーソル操作可能)
  • Stash — 一時保存した変更
  • Diff — 選択中のアイテムの差分

キーバインド

キー動作
spaceファイルをステージ / 解除
cコミット (メッセージ入力ダイアログ)
Ppush
ppull
sstash
rインタラクティブ rebase を開始
zundo (直前の操作を取り消し)
?ヘルプ

特に r (インタラクティブ rebase) が強力です。素の Git では git rebase -i HEAD~5 を入力し、テキストエディタで pick/squash/edit を手書きする必要があります。lazygit ではコミットを選び s で squash、e で edit、d で drop です。

設定ファイル

~/.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

paging.pager に delta を指定すると、diff がカラフルに表示されます。

誰が使うか

Toss、カカオ、メルカリ — SSH でサーバーに入って作業するインフラ / プラットフォームエンジニアの多くが lazygit を既定の道具にしています。VS Code のような GUI エディタを使う人も、大規模なインタラクティブ rebase が必要なときには lazygit を立ち上げます。

限界

  • 非常に大きなリポジトリ (100 万コミット超) では起動時間が長くなります
  • Windows 端末で一部の色やユニコードが崩れることがあります
  • マウスはあまり効きません (TUI の性質)

4. gitui — Rust 製の TUI 代替

lazygit との違い

gitui は Stephan Dilly による Rust 製 TUI Git クライアントです。2020 年に初公開されました。lazygit に似た 5 パネル UI を持ちます。最大の違いは 2 点です。

項目lazygitgitui
言語GoRust
バックエンドgit CLI を呼ぶgitoxide / libgit2 を直接利用
起動速度普通非常に速い
メモリ普通少ない
インタラクティブ rebase強力基本機能のみ

gitui の本質は速さです。git CLI を fork/exec せず、Rust ネイティブのライブラリで直接 .git を読み取るので、巨大リポジトリでもほぼ瞬時に応答します。

キーバインド

lazygit に似ていますが少し違います。

キー動作
1-5パネル移動
sステージ
u解除
cコミット
tタグ
gログ
hヘルプ

誰が使うか

Linux カーネル開発者、Rust コミュニティ、そして単純に lazygit のインタラクティブ rebase が不要な人たち。メルカリの一部インフラエンジニアが軽量さゆえに gitui を好むというインタビューがあります。

使わない方が良いとき

  • 複雑なインタラクティブ rebase が頻繁に必要な場合 (lazygit が優勢)
  • フック、サブモジュール、LFS 統合が深く必要な場合

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

ホスティング CLI の登場

Git 自体は分散型ですが、現実にはほぼすべてのチームが GitHub、GitLab、Gitea などの中央ホスティングを使います。それなのに PR 作成、レビュー、Issue 管理がすべて Web に偏っていたのが長らく不便でした。そこで各ホスティングから公式 CLI が登場しました。

ツールホスティング言語インストール
ghGitHubGobrew install gh
glabGitLabGobrew install glab
teaGiteaGobrew install tea

gh CLI の主要コマンド

# 現在のブランチから PR 作成
gh pr create --title "feat: add user search" --body "Closes #123"

# PR 一覧
gh pr list --author "@me" --state open

# PR をローカルにチェックアウト
gh pr checkout 456

# PR レビュー
gh pr review 456 --approve

# Issue 作成
gh issue create --title "Bug in login" --label bug

# GitHub Actions の実行確認
gh run list
gh run view 12345 --log

特に gh pr checkout 456 が便利です。これは次と等価です。

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

PR をローカルで検証するときの必須コマンドです。

gh API — 汎用 GitHub API 呼び出し

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

これは PR コメントを JSON で取得します。OWNER と REPO は実際の値に置換してください。

glab — GitLab 版

GitLab は組み込み CI/CD が GitHub より豊富なので、glab には追加コマンドがあります。

glab ci view              # 現在のパイプラインを可視化
glab ci status            # 実行状況
glab ci trace             # ライブログ
glab snippet create file.py

tea — Gitea

Gitea は GitHub / GitLab の自己ホスト版代替で、社内閉域網で多用されます。

tea login add --url https://gitea.example.com
tea issue create --title "..." --description "..."
tea pulls list

韓国 / 日本の事例

  • Toss — GitHub Enterprise + gh CLI を積極利用
  • カカオ — 一部チームは GitLab + glab
  • メルカリ — GitHub + gh CLI が標準

6. jj (Jujutsu, Google) — Git 互換の新モデル

誰が作ったか

jj (Jujutsu) は Google の Martin von Zweigbergk が始めた新しいバージョン管理システムです。2020 年初頭に公開され、Google 内部でも一部運用されています。最大の特徴は Git 互換であることです。jj で作ったリポジトリは GitHub に push でき、既存の Git リポジトリは jj で扱えます。

Git との主要差

jj は Git のデータモデルを次のように再解釈します。

概念Gitjj
作業ツリー変更明示的に stage / commit自動で working copy commit に蓄積
ブランチ強調される (HEAD 位置)弱化される (任意)
衝突即時解決必須保存状態として保持可能
履歴編集rebase, amend, resetすべての変更が等しく編集可能
識別子40 文字 SHAchange ID + commit ID

Working copy as commit

jj の最も衝撃的な違いは作業ツリー自体がコミットであることです。

Git: ファイル編集 → git add → git commit jj: ファイル編集 → 自動で現在の working copy commit が更新される

# 既存 Git リポで jj を初期化
jj git init --colocate

# 変更状況を表示 (git status 相当)
jj status

# 新しい変更を作る (git commit -m とは異なる)
jj new -m "WIP: trying new approach"

# 変更メッセージの修正
jj describe -m "feat: add user authentication"

# ログ
jj log

Change ID — commit ID から分離

Git では git commit --amend や rebase をすると SHA が変わり、外部からの参照が壊れます。

jj ではすべての変更に change ID (永続) と commit ID (スナップショット) があります。amend、rebase をしても change ID は保たれ、commit ID だけが変わります。

jj log
@ kzqp 0a1b2c3 main | feat: user search
o mnop 4d5e6f7 fix: login bug
o qrst 8g9h0i1 initial commit

kzqp が change ID、0a1b2c3 が commit ID です。

衝突を後回しにする

Git の rebase は衝突で停止します。jj は衝突を保存された状態のまま保持します。rebase を最後まで進めてから、後で衝突だけを解決できます。

誰が使うか

  • Google 内部の一部チーム
  • Rust コミュニティの一部
  • 「Git の次世代」を試したいアーリーアダプター

使わない方が良いとき

  • チーム全体が Git に習熟している場合 (認知負荷)
  • Git GUI / TUI 統合が必須な場合 (jj 連携はまだ薄い)
  • 絶対的な安定性が必要な本番環境 (まだ 1.0 未満)

7. Sapling (Meta) — Mercurial ベースの社内ツール

背景

Meta (旧 Facebook) は数億行規模の巨大モノレポのため Git の性能が不足と判断し、長年 Mercurial をベースとした社内ツールを使ってきました。2022 年 11 月、それを Sapling として OSS 化しました。

Git との違い

Sapling は Mercurial UX に Meta の拡張を載せた仕組みです。

項目GitSapling
ベース独自モデルMercurial 変種
ブランチモデル明示ブランチ匿名ブランチ
インデックスstaging area ありなし
巨大リポジトリ遅い高速 (EdenFS 仮想ファイルシステム)
GitHub 連携ネイティブsl pr コマンド

sl コマンド

Sapling の CLI は sl です。

sl clone https://github.com/facebook/sapling
cd sapling
sl status
sl commit -m "feat: ..."
sl push
sl pr submit       # GitHub PR を作成

sl pr submit が興味深く、現在のコミットスタックを GitHub PR の連続に自動分割します。5 コミットあれば 5 つの連結 PR が生成されます (Stacked PRs)。

EdenFS

差別化点は EdenFS という仮想ファイルシステムです。クローン時に全ファイルを取らず、アクセス時に遅延取得します。100GB のリポジトリを 1 分で「クローン」できます。

誰が使うか

  • Meta 内部 (メインツール)
  • 一部の巨大モノレポ運営
  • 「Git 以外の選択肢」を試す層

限界

  • GitHub 以外のホスティングとの連携が薄い
  • 学習曲線 (Mercurial 風コマンドを新たに覚える必要)

8. GitButler — Tauri 仮想ブランチ GUI

何を解くか

GitButler は GitHub 共同創業者であり「Pro Git」著者の Scott Chacon が 2023 年に始めた新しい Git GUI です。Tauri (Rust + WebView) で作られ、最大の特徴は仮想ブランチ (Virtual Branches) です。

仮想ブランチの考え方

伝統的な Git ワークフローで複数機能を同時開発するには、次のいずれかを選ぶことになります。

  1. 1 ブランチで作業し、コミット時に分割 (難しい)
  2. stash → 別ブランチへ switch → 作業 → 戻る (面倒)
  3. worktree で複数ディレクトリ運用 (ディスク消費)

GitButler は 4 つ目の道を提案します。1 つの作業ツリー内で複数の仮想ブランチが同時に存在します。ファイル変更をドラッグしてどの仮想ブランチに属するか決め、各仮想ブランチは独立して PR として push できます。

画面

GitButler GUI はおおよそ次のように見えます。

+-----------------+ +-----------+ +-----------+
| 変更ファイル     | | 仮想 A    | | 仮想 B    |
| - file1.ts      | | + file1.ts | | + file3.ts |
| - file2.ts      | | + file2.ts | |            |
| - file3.ts      | |            | |            |
+-----------------+ +-----------+ +-----------+

各ファイルをドラッグして所属ブランチを決めます。

誰が使うか

  • 複数機能を同時に進める個人開発者
  • 頻繁にコンテキストスイッチするフルスタック開発者
  • 大きな PR を小さな単位に分けたい人

限界

  • チームワークフローへの深い統合は弱い
  • レビュアー視点では結局通常の PR に見える
  • Git の本質を隠しすぎるという批判もある

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

4 大デスクトップ GUI 比較

ツール価格プラットフォーム特徴
Fork約 $50 (買い切り)Mac, Win軽快で高速、conflict resolver が優秀
Sublime Merge$99 (買い切り)Mac, Win, LinuxSublime Text チーム製、非常に高速
GitKraken$60-100/年 (サブスク)Mac, Win, Linux派手な UI、チーム協業機能
GitHub Desktop無料Mac, WinGitHub 親和、基本機能のみ

Fork

Mac ユーザーに最も人気の GUI です。起動 1 秒未満、グラフ表示も鮮やか、インタラクティブ rebase をドラッグ&ドロップで行えます。conflict resolver が特に優れています。

Sublime Merge

Sublime Text を作った Jon Skinner のチームの作品です。圧倒的な速度が魅力で、大きなリポジトリでも滑らかです。CLI とほぼ 1 対 1 で対応するので、Git の内部を理解した人に向きます。

GitKraken

UI が最も派手です。ブランチグラフ、GitFlow 可視化、Issue Board 連携などがあります。欠点は重さとサブスク課金です。

GitHub Desktop

GitHub の公式デスクトップクライアントです。最もシンプルで初心者に向きます。インタラクティブ rebase や cherry-pick のような高度機能は弱いです。

誰が何を使うか

  • Fork — Mac 使用のシニア開発者、デザイナー協業環境
  • Sublime Merge — Linux + Sublime Text ユーザー
  • GitKraken — チーム協業を重視する企業 (グラフを共有)
  • GitHub Desktop — 初学者、非開発者 (PM、デザイナー)

10. Tower / SmartGit — その他の GUI

Tower

Tower はドイツの fournova GmbH が作る Mac / Win GUI で、2010 年から続いています。洗練された UI、Git との深い統合、学習ガイドが強みです。価格は約 $69/年です。

特徴:

  • Git の全コマンドを視覚的にマッピング
  • PR ワークフローを直接サポート (GitHub、GitLab、Bitbucket)
  • 学習ガイド (Git 入門者向けのステップ別チュートリアル)
  • 衝突解決 UI が優秀

SmartGit

SmartGit はドイツの syntevo GmbH が作る Java ベースのクロスプラットフォーム GUI です。Windows / macOS / Linux で同じ操作感を提供し、Git 機能の網羅性が高いです。

特徴:

  • Mercurial と Subversion にも対応
  • PR ワークフロー
  • 強力なマージツール内蔵
  • 非商用利用は無料

誰が使うか

  • Tower — Mac のデザイン会社、初学者 + シニア混合チーム
  • SmartGit — Windows 中心の企業、Java 開発チーム

11. magit (Emacs) — Git の魔法

紹介

magit は Jonas Bernoulli が 2008 年に始めた Emacs 用 Git インターフェースです。「Git を真に理解したいなら magit を使え」と言われるほど強力です。

中核の哲学は次のとおりです。

  1. Git の全コマンドをキー操作で公開
  2. 各画面で可能な動作をすべて popup で表示
  3. 最頻動作はワンキーで実行

画面例

Emacs で M-x magit-status を実行すると次のように表示されます。

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)

s でステージ、c でコミット popup が開きます。

コミット popup

c を押すと次のような popup が現れます。

Commit
 -a Stage all modified
 -e Allow empty
 -v Show diff
 -n No verify

 c Commit
 e Extend
 w Reword
 a Amend
 f Fixup

オプションをトグルし、最後にもう一度 c を押すと実行されます。

誰が使うか

  • Emacs ユーザー (当然)
  • 関数型プログラミングコミュニティ (Clojure、Haskell、Lisp)
  • 「キーボードだけですべてを操作したい」シニア開発者

限界

  • Emacs の習熟が前提
  • ここで紹介する中で最も急な学習曲線

12. vim-fugitive (Vim) — Vim の Git 標準

紹介

vim-fugitive は Tim Pope が 2009 年に作った Vim 用 Git プラグインです。Vim ユーザーならほぼ全員が使っています。

主要コマンド

Vim 内から次のように使います。

:Git status           " git status 出力
:Git add %            " 現在のファイルをステージ
:Git commit           " コミットメッセージ入力バッファを開く
:Git push
:Git blame            " 現在ファイルの blame ビュー
:Gdiffsplit           " 現在ファイルの diff を分割
:GBrowse              " GitHub / GitLab で現在行を開く

特に :Git blame と :Gdiffsplit が強力です。blame ビューでカーソルを合わせて enter を押すと、そのコミットの diff が新ウィンドウで開きます。

vim-rhubarb

vim-fugitive と一緒によく使うのが vim-rhubarb (同じく Tim Pope 作) で、GitHub 連携を追加します。:GBrowse で現在行を GitHub URL で開けます。

誰が使うか

  • Vim / Neovim ユーザー
  • キーボード中心の開発者
  • SSH でサーバー作業が多い人

13. git-cliff (Rust) — changelog 生成

紹介

git-cliff は Orhun Parmaksız による Rust 製 changelog 生成ツールです。コミットメッセージを解析して CHANGELOG.md を自動生成します。

仕組み

git-cliff は次を前提とします。

  1. コミットメッセージが Conventional Commits 形式 (feat:、fix:、chore: など)
  2. タグが SemVer 形式 (v1.2.3)

この前提のもと、タグ間のコミットを分類して changelog を作ります。

使い方

# インストール
brew install git-cliff

# すべてのタグの changelog を生成
git cliff -o CHANGELOG.md

# 次のリリース用の changelog
git cliff --unreleased --tag v1.2.0

設定

cliff.toml に設定します。

[changelog]
header = "# Changelog\n"
body = """
## [v_version] - v_date

[GROUP_LOOP]
### group_name
[COMMIT_LOOP]
- commit_msg
[END_LOOP]
[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"},
]

誰が使うか

  • Rust プロジェクト (Cargo と親和)
  • Conventional Commits を厳格に守るチーム
  • リリース自動化を進めたいチーム

semantic-release との比較

semantic-release (JS エコシステム) は changelog 生成 + バージョン決定 + npm publish までを自動化します。git-cliff は changelog 生成に集中します。

14. nbdime / git-lfs / git-annex / git-filter-repo — その他のユーティリティ

nbdime — Jupyter ノートブックの diff

Jupyter ノートブック (.ipynb) は JSON 形式なので、通常の git diff では読めません。nbdime は人間が読める diff / merge UI を提供します。

pip install nbdime
nbdime config-git --enable --global

git diff notebook.ipynb   # nbdime が自動で動作する

git-lfs — 大きなファイル

100MB を超えるファイルを Git に直接入れるとリポジトリが急速に肥大化します。Git LFS (Large File Storage) は大きなファイルを別ストアに置き、.git にはポインタだけを残します。

git lfs install
git lfs track "*.psd"
git add .gitattributes
git add design.psd
git commit -m "design files"

git-annex

git-annex はさらに極端な大規模ファイル管理ツールです。ファイル内容を複数のストア (S3、rsync、USB など) に分散し、Git はメタデータだけを追跡します。科学データや動画のような巨大ファイル向きです。

git-filter-repo — 履歴書き換え

かつては git filter-branch で履歴を書き換えていましたが、非常に遅く危険でした。git-filter-repo (Elijah Newren 作) は安全で高速な代替です。

# 履歴から特定ファイルを完全除去
git filter-repo --path secrets.env --invert-paths

# 特定のパスだけを残す
git filter-repo --path src/

# メールアドレスを書き換える
git filter-repo --email-callback 'return email.replace(b"@old.com", b"@new.com")'

認証情報漏洩後の整理やモノレポ分割で必須です。

15. フック — pre-commit / husky / lefthook / commitlint / Conventional Commits / semantic-release

Git フックの限界

Git 自体には .git/hooks にシェルスクリプトを置くと自動実行されるフック機構があります。問題は 2 つです。

  1. .git/hooks はリポジトリに含まれない (各人が手動でインストール)
  2. シェルスクリプトだけで複雑なロジックを書きづらい

そこでフックフレームワークが生まれました。

pre-commit (Python)

pre-commit は Anthony Sottile による Python 製フレームワークです。.pre-commit-config.yaml にフックを宣言し、pre-commit install が .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 は JavaScript エコシステム向けのフックツールです。package.json と統合します。

npm install --save-dev husky
npx husky init

これで .husky/pre-commit スクリプトが作られ、npm run lint のようなコマンドを書き込めます。

lefthook (Go)

lefthook は Evil Martians による Go 製フックツールです。husky より高速で、並列実行をサポートします。

pre-commit:
  parallel: true
  commands:
    lint:
      glob: "*.{js,ts}"
      run: npx eslint staged_files
    test:
      run: npm test

commitlint + Conventional Commits

Conventional Commits はコミットメッセージ形式を標準化した仕様です。

feat: add user search
fix: handle null in login
chore: bump deps
docs: update README
refactor!: rename API endpoint

commitlint は commit-msg フックでメッセージがこの仕様に従うか検証します。

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

semantic-release

semantic-release はコミットメッセージを解析して次を自動化します。

  1. 次のバージョン決定 (feat → minor、fix → patch、BREAKING → major)
  2. CHANGELOG.md の生成
  3. Git タグ作成
  4. npm パッケージ publish
  5. GitHub Release 作成

CI でメインブランチに push されるたびに走らせれば、人がバージョンを決める必要はなくなります。

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

大きな PR vs 小さな PR

レビュー効率のために PR は小さく保つべきですが、1 つの機能が大きすぎて小さな PR に分割すると依存関係が生じます (PR-2 が PR-1 を base にする)。

伝統的な GitHub PR UX はこのような依存 PR をうまく扱えません。PR-1 がマージされると PR-2 の base を更新する必要があり、PR-1 にレビューが付くと PR-2 まで rebase が必要になります。

Stacked PR ツール

ツールアプローチ
Graphite (CLI: gt)GitHub PR スタックを管理する外部ツール
Sapling (sl)スタックが第一級、sl pr submit で自動生成
jjchange ID により rebase 後も識別子が保持される
GitButler仮想ブランチで視覚的にスタック化

Graphite (gt)

Graphite は Tomas Reimers が作った会社およびツールです。CLI は gt です。

gt create -m "feat: part 1"
# コード作成、自動でステージ / コミット
gt create -m "feat: part 2"
# さらにコード作成
gt submit         # スタック全体を GitHub PR として push

PR-2 は自動で PR-1 を base に持ち、PR-1 がマージされると PR-2 の base が自動でメインへ移ります。

誰が使うか

  • Meta、Google のような大企業 (Sapling / jj)
  • 速く動くスタートアップ (Graphite)
  • 1 人フルスタック開発 (GitButler)

17. 韓国 / 日本 — Toss / カカオ / メルカリの Git ワークフロー

Toss

Toss は GitHub Enterprise をメインホスティングとして使います。中核ワークフローは次のとおりです。

  1. main ブランチは保護 (PR + 2 名承認 + CI 通過必須)
  2. feature ブランチは短命 (通常 2-3 日)
  3. Squash merge が既定 (履歴の単純化)
  4. PR テンプレートに「チェックリスト」を必須化 (デプロイ影響、ロールバック可否、モニタリング)
  5. CI は GitHub Actions + 自社ビルドシステム

ツール利用:

  • シニアバックエンド — lazygit + gh CLI を主に使用
  • フロントエンド — VS Code Git + gh CLI
  • 一部 SRE — vim-fugitive

カカオ

カカオは事業部により異なりますが、概ね GitHub Enterprise または社内 GitLab を使います。カカオペイ / バンクは GitHub 寄り、カカオ広告 / 検索は GitLab 寄りの傾向があります。

特徴:

  • Trunk-based development が増加 (main へ小さな PR を直接マージ)
  • リリースブランチは決まった時点でのみ作成
  • 韓国語コミットメッセージ許容 (PR タイトルは明瞭に)
  • pre-commit フックで lint と secret 検査

メルカリ

メルカリは日本企業ですが社内公用語が英語で、GitHub をホスティングに使います。

特徴:

  • Conventional Commits を厳格運用 (commitlint + husky)
  • semantic-release で自動バージョン管理
  • マイクロサービスが多くモノレポ + マルチレポ混合
  • PR レビュー SLA を KPI 化 (24 時間以内に初回レビュー)
  • 一部チームで Sapling を試験導入中

日韓共通のトレンド

  1. シニアの間で lazygit / Sublime Merge が急速に広がる
  2. gh CLI は PR レビューに必須
  3. pre-commit + commitlint が事実上の標準
  4. Stacked PR はまだアーリーアダプター層のみ

18. 誰が何を選ぶべきか — 初学者 / TUI 派 / モノレポ / 大規模チーム

初学者

  • GUI — GitHub Desktop (最もシンプル、無料)
  • CLI — git + gh CLI
  • 学習 — Tower のガイド、Pro Git 本、magit ではなく普通のツールから

端末 / SSH 中心ユーザー

  • メイン — lazygit
  • 速度優先 — gitui
  • 補助 — gh CLI、vim-fugitive (Vim 編集時)

モノレポ運用者

  • Git 本体 — sparse-checkout + partial clone 必須
  • 代替試用 — Sapling、jj
  • 大きなファイル — git-lfs、git-annex
  • 履歴整理 — git-filter-repo

大規模チーム / 企業ワークフロー

  • ホスティング — GitHub Enterprise + gh CLI
  • フック — pre-commit + commitlint
  • リリース — semantic-release または git-cliff
  • PR スタック — Graphite または Sapling

1 人 / 少人数フルスタック

  • GUI — Fork (Mac) または Sublime Merge (クロスプラットフォーム)
  • 仮想ブランチ — GitButler は試す価値あり
  • changelog — git-cliff

Emacs / Vim ユーザー

  • Emacs — magit (事実上必須)
  • Vim — vim-fugitive + vim-rhubarb

次世代を試したい層

  • jj — Git 互換なので段階的に導入可能
  • Sapling — 巨大モノレポで真価
  • GitButler — 1 人フルスタック向き

最後のアドバイス

ツールはあくまでツールであり、Git 自体の理解が最も重要です。どのツールを使うにしても、次の概念は頭に入れておく必要があります。

  1. コミット = スナップショット + 親参照
  2. ブランチ = コミットを指すポインタ
  3. HEAD = 現在の作業位置のポインタ
  4. インデックス (staging area) = 次のコミットを準備するスペース
  5. push / pull / fetch が何を移動させるか

これを知らずに lazygit / magit / Sapling を使うと、いずれどこかで詰まります。

19. 参考 / References

Discuss on Twitter • View on GitHub