Stackit - stacked PR workflow を軽量 CLI で管理する
多くの team は「small PR の方が review しやすい」と知っています。ただ、実際にそれを続けるのは簡単ではありません。1 つの feature を 3 つ、4 つの branch に分けると、parent / child の関係、rebase の順番、PR base、すでに merge された下位 branch、今の修正をどの commit に amend すべきかが、すべて頭の中の状態になります。Graphite のような tool は stacked changes の価値を示していますが、すべての team が review flow を重い platform に移したいわけではありません。
今日紹介する getstackit/stackit は、より local Git に近い選択肢です。Go 製の CLI で、stacked changes を管理します。小さな branch を stack tree として扱い、parent / child relationship を追跡し、restack、stack 単位の PR submission、merge、cleanup、branch state の確認を助けます。
公開時点の GitHub page では、約 31 stars、1 fork。主な言語は Go、license は MIT です。Repository は 2025-12-14 に作成され、現在も高い頻度で更新されています。Release page では最新 version が v0.19.1、公開日は 2026-06-13 です。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| Repository | getstackit/stackit |
| 位置づけ | Git stacked changes / stacked PR CLI |
| Stars | 約 31 |
| Forks | 1 |
| 主な言語 | Go |
| License | MIT |
| Latest version | v0.19.1 |
stack を branch tree として扱う
Stackit の README は、stacked diffs を開発 model として説明しています。大きな feature を複数の小さな branch に分け、それぞれを focused PR にする考え方です。単純な場合は、API change、implementation、UI、test が一本の chain になります。複雑な場合は、途中の branch から複数の child branch が分かれます。
これは普通に feature branch をいくつか作るだけではありません。Stacked workflow の難しさは branch 作成ではなく、関係を維持し続けることです。今の branch の parent はどれか、どの child を rebase する必要があるか、どの PR がどの base を向くべきか、下位 PR が merge された後に上位 branch をどう同期するか。Stackit はこれらを明示し、stackit log で現在の stack tree を表示できます。parent / children で現在位置も確認できます。
大きな変更をよく分割する人にとって、この visualization と metadata layer は重要です。減らしているのは Git command の数だけではなく、branch state が頭の中でずれていく cost です。
create、sync、submit まで covered
README の getting started はわかりやすいです。
stackit init
stackit create add-api -m "feat: add base api"
stackit create add-logic -m "feat: implement logic"
stackit log
stackit submitstackit init は trunk branch を検出し、repository に stack metadata を準備します。stackit create は現在の branch の上に新しい branch を作ります。stackit log は tree を表示し、stackit submit は stack 全体を GitHub に push して PR を作成または更新し、上位 PR が正しい下位 branch を base にするよう扱います。
長く stack を保つと壊れやすい部分も cover しています。
restack: parent が変わった後、child branch を付け直す。sync: trunk と同期し、merge 済み branch を cleanup する。merge: stack の順番で merge する、または single atomic PR にまとめる。absorb: 現在の変更を stack 内の適切な commit に吸収する。lock/freeze: 重要な branch を誤変更から守る。
これらを合わせると、Git の上に「change sequence management」の layer を足す tool になります。Git を置き換えるのではなく、多 branch review で忘れやすい関係を記録します。
v0.19.1 は submit と get の performance を改善
Latest release の v0.19.1 は、project が実用面を磨いているかを見る材料になります。この version の中心は派手な新機能ではなく、submit と get path の N+1 call を減らすことです。
Release notes では、submit が stack 全体を 1 回の git push で送るようになり、PR information は 1 回の GraphQL query で取得し、remote ref、PR content、empty-branch validation を batch 化したと説明されています。get も取得済み metadata から parent を導き、GitHub を serial に crawl する処理を避けます。
これは Stackit が実際の stacked workflow の performance issue に向き合っていることを示しています。Demo のように branch が 2、3 個だけなら逐次 query でも問題になりません。しかし stack が大きくなり、PR 数が増え、CI と remote state を同期するようになると、batching が体験に効いてきます。
agent integration も面白い側面
Stackit には stackit agent install があります。Claude Code、Codex、Cursor 向けの integration file を生成できます。README に挙がっている skill には、stack-status、stack-create、stack-submit、stack-sync、stack-restack、stack-absorb、stack-fix、stack-describe があります。
この設計は自然です。Stacked PR workflow は coding agent と相性がよい領域です。Agent は current stack state を読み、PR description を整理し、特定 layer の test を直し、修正を正しい commit に吸収できます。ただし、agent が stack structure を理解していることが前提です。そうでないと、違う branch で変更したり、base を壊したり、review しにくい mixed change を作りやすくなります。
Stack operation を専用 agent skill にする方が、AGENTS.md に数段落の約束を書くより安定します。Agent に task-oriented な入口を渡せるからです。
向いている場面
Stackit が向いているのは、「large PR は重すぎるが、small PR の管理も面倒」と感じている team や個人です。典型的には次のような場面です。
- Feature を API、implementation、UI、test、migration などの reviewable layer に分けられる。
- Review cycle が長く、下位 PR の merge を待たずに上位作業を進めたい。
- GitHub PR review flow は維持しつつ、新しい code review platform へ全面移行したくない。
- Codex、Claude Code、Cursor を使っていて、agent に branch stack を理解させたい。
すべての repository に必要な tool ではありません。Team が短命な feature branch に慣れていて、毎日すぐ merge できるなら、stacked workflow は余計に感じるかもしれません。Stackit の価値は、複雑な変更と review delay があるときに出ます。その圧力がなければ、追加の branch structure は process 感を増やすだけです。
まとめ
getstackit/stackit は early stage ですが、方向性のはっきりした Git tool です。Stacked changes の core relationship を local CLI に落とし込み、tree-shaped branches、automatic restack、stack 単位の PR submission、merge cleanup、branch protection、worktree、agent integration を扱います。
GitHub review で複数 layer の大きな feature を扱っていて、すべてを 1 つの PR に押し込みたくないなら、Stackit は見る価値があります。解いているのは「code をどう書くか」ではありません。「関連する変更の集合を、review 可能で、同期可能で、agent に渡せる形に保つにはどうするか」です。