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

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

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

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

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

| 分類 | 代表ツール | 利用者プロファイル |

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

| CLI | git, gh, glab, tea | 標準ユーザー、CI/CD、自動化 |

| TUI | lazygit, gitui, tig | 端末中心の開発者、SSH 環境 |

| GUI | Fork, Sublime Merge, GitKraken, GitButler, Tower | 視覚的なワークフローを好む |

| エディタ統合 | magit (Emacs), vim-fugitive (Vim), VS Code Git | 特定の IDE / エディタに依存する人 |

| 新しいモデル | jj (Jujutsu), Sapling | Git の次世代を試す層 |

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

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.46 | 2024-08 | git config サブコマンド導入 (get/set/unset)、reftable バックエンドの安定化 |

| 2.47 | 2024-10 | デフォルトブランチ表示の整理、patch モード改善 |

| 2.48 | 2025-01 | reftable のデフォルトオプション公開、sparse-checkout 性能改善 |

| 2.49 | 2025-03 | name-rev 出力形式の統一、fetch.pruneTags の安定化 |

| 2.50 | 2025-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 | コミット (メッセージ入力ダイアログ) |

| P | push |

| p | pull |

| s | stash |

| r | インタラクティブ rebase を開始 |

| z | undo (直前の操作を取り消し) |

| ? | ヘルプ |

特に 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 点です。

| 項目 | lazygit | gitui |

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

| 言語 | Go | Rust |

| バックエンド | 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 が登場しました。

| ツール | ホスティング | 言語 | インストール |

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

| gh | GitHub | Go | brew install gh |

| tea | Gitea | Go | brew 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 のデータモデルを次のように再解釈します。

| 概念 | Git | jj |

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

| 作業ツリー変更 | 明示的に stage / commit | 自動で working copy commit に蓄積 |

| ブランチ | 強調される (HEAD 位置) | 弱化される (任意) |

| 衝突 | 即時解決必須 | 保存状態として保持可能 |

| 履歴編集 | rebase, amend, reset | すべての変更が等しく編集可能 |

| 識別子 | 40 文字 SHA | change 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 の拡張を載せた仕組みです。

| 項目 | Git | Sapling |

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

| ベース | 独自モデル | 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 |

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

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

誰が使うか

- 複数機能を同時に進める個人開発者

- 頻繁にコンテキストスイッチするフルスタック開発者

- 大きな PR を小さな単位に分けたい人

限界

- チームワークフローへの深い統合は弱い

- レビュアー視点では結局通常の PR に見える

- Git の本質を隠しすぎるという批判もある

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

4 大デスクトップ GUI 比較

| ツール | 価格 | プラットフォーム | 特徴 |

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

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]

"""

[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 で自動生成 |

| jj | change 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

- Git 公式ドキュメント: https://git-scm.com/doc

- Git 2.46 リリースノート: 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 本 (Scott Chacon): https://git-scm.com/book/en/v2