{"slug": "ayo-github-quietly-killed-the-unreviewable-mega-pr", "title": "Ayo GitHub Quietly Killed the Unreviewable Mega-PR", "summary": "GitHub has quietly introduced support for stacked pull requests, enabling developers to break large changes into chains of smaller, dependent PRs. The feature automatically recognizes stacks when PRs are opened against other PR branches instead of the main branch, and displays a banner with a preview and progress badges. An engineer demonstrated the workflow using plain git and the gh CLI, noting that no special tool is required.", "body_md": "If you've ever opened a PR with 47 changed files and a diff so long GitHub just gives up and shows you \"Load Diff\" seventeen times, this one's for you.\n\nGitHub quietly shipped what might be the biggest pull request update in years, and it's aimed squarely at that problem.\n\nLet's talk about stacked pull requests.\n\nBig PRs are where good reviews go to die.\n\nNobody reads a 2000 line diff carefully.\n\nSome folks reach for AI code review tools like [LiveReview](https://hexmos.com/livereview/) to take the edge off, and honestly that helps, but even the best reviewer (human or model) does a better job on a tight, focused diff than on a 2000 line wall.\n\nSmaller inputs, better reviews. That's true no matter who's doing the reviewing.\n\nStacked PRs are GitHub's answer: break one massive change into a chain of small, dependent PRs, where each one only reviews the diff it actually introduces, not everything below it.\n\nThe rule is simple. You need two or more PRs in the same repo where:\n\n`main`\n\n)`main`\n\nThat's it. That's the whole trick.\n\nFoundational stuff (schemas, shared types) goes at the bottom.\n\nStuff that depends on it (API routes, UI) goes higher up the chain.\n\nAnd here's the part that surprised me: if you just do this manually with plain git, by opening PR #11 against the branch for PR #10 instead of against `main`\n\n, GitHub now recognizes that as a stack automatically.\n\nNo special tool required.\n\nIt just notices the base branches form a chain and lights up a banner.\n\nStacking isn't a git concept at all, it's purely a GitHub UI concept layered on top of branches you were already making.\n\nEnough theory. I built a real stack in one of my own repos ([peektea](https://github.com/lovestaco/peektea), a terminal file browser I maintain), using a harmless scratch file so nothing real got touched.\n\nHere's the actual terminal session, copy pasted, warts and all.\n\nFirst I tried to be fancy and use the CLI extension:\n\n``` bash\n$ gh stack --help\nunknown command \"stack\" for \"gh\"\n```\n\nYeah. Turns out `gh stack`\n\nneeds a CLI extension or a newer `gh`\n\nversion than the one sitting in my `$PATH`\n\n, and mine's from a Ubuntu apt repo that hasn't heard about this feature yet.\n\nSoftware, everyone.\n\nSo I did it the \"old school\" way the docs mention, plain git branches, chained base to base, no extension needed.\n\nWhich, from git's point of view, gives you exactly what git always gives you: three branches sitting on top of each other like tired commuters on a train.\n\nNothing special yet. This is just branches.\n\nThe magic happens once you push them and open the PRs with the right bases:\n\n``` bash\n$ git push -u origin stack/01-setup-database stack/02-api-endpoints stack/03-setup-frontend\n\n$ gh pr create --base master --head stack/01-setup-database \\\n    --title \"demo: setup database layer\"\nhttps://github.com/lovestaco/peektea/pull/10\n\n$ gh pr create --base stack/01-setup-database --head stack/02-api-endpoints \\\n    --title \"demo: add api endpoints\"\nhttps://github.com/lovestaco/peektea/pull/11\n\n$ gh pr create --base stack/02-api-endpoints --head stack/03-setup-frontend \\\n    --title \"demo: setup frontend\"\nhttps://github.com/lovestaco/peektea/pull/12\n```\n\nNotice the `--base`\n\non PR #11 is `stack/01-setup-database`\n\n, not `master`\n\n.\n\nThat one flag is the entire secret sauce.\n\nThis is the bit that got me. I expected to have to manually flip some setting somewhere.\n\nInstead, the second I opened the top PR of the chain, GitHub just showed a banner: \"This pull request can be stacked with other pull requests,\" with a \"Preview stack\" button sitting right there.\n\nClicking it pops up a little preview that walks the whole chain, top PR down to `main`\n\n, correctly ordered, correctly linked, with zero config from me beyond opening PRs against the right base branches.\n\nHit \"Create stack\" and every PR in the list picks up a tiny progress badge, `1/3`\n\n, `2/3`\n\n, `3/3`\n\n, right there in the pull request list, so you can see at a glance how deep any given PR sits in its stack without opening a single one.\n\nAccording to [GitHub's own docs on stacked pull requests](https://docs.github.com/en/pull-requests/get-started/about-stacked-prs), once you're happy with the whole chain there's a \"merge stack\" action that walks down and merges every PR in order in one go, no manual rebasing between each merge.\n\nI didn't actually pull that trigger on my demo repo (closing four browser tabs is enough chaos for one blog post), but the docs and the UI both point at it being one button for what used to be N sequential merges plus N rebases.\n\nHere's roughly what that flow looks like end to end, CLI or manual, doesn't matter which:\n\nKind of, and this is worth being honest about. You could always open a PR against another PR's branch.\n\nThat's not new, that's just git plus GitHub's base branch dropdown, and people have been daisy chaining branches like this for a decade.\n\nWhat's new is that GitHub now understands the relationship, tracks it as a first class object (mine got assigned its own stack ID the moment I hit \"Create stack\"), shows progress across the whole list view, and gives you one merge action instead of a manual merge-then-rebase-then-merge dance for every layer.\n\nSo no, git itself didn't get a new stacked PR primitive.\n\nGitHub's UI did.\n\nIf you clone the repo and look at the branches, there is genuinely nothing different about them from any other feature branch.\n\nThe \"stack\" only exists as metadata GitHub keeps on its side.\n\nHere's the part that got me more excited than a database migration screen usually gets me.\n\nThink about what claude does when you point it at a big task and let it run for a few hours unattended.\n\nHistorically you get one of two bad outcomes: either it hands you back one enormous PR that's basically unreviewable, or it opens a dozen totally disconnected PRs that don't tell you which one depends on which.\n\nStacked PRs give agents a third option: build the feature the way a careful human would, in reviewable layers, and let the dependency chain itself communicate the order.\n\nSchema first, then the API that needs the schema, then the UI that needs the API. You review it the same way the agent built it.\n\nNo more choosing between \"one unreviewable 3000 line PR\" and \"twelve PRs with no visible relationship to each other.\"\n\nThe stack is the changelog of how the agent actually thought through the problem.\n\nIf your team already splits work into small PRs by hand and just eats the rebase pain, yes, obviously, this removes the pain and keeps the habit.\n\nIf your team is currently a \"one PR per feature, no matter how big\" shop, stacked PRs are a nice on ramp, because you get to keep working the way you already do (branch off the previous branch) while GitHub handles the bookkeeping you used to do in your head.\n\nIt's still labeled as a newer feature in GitHub's docs, so expect some rough edges (my `gh`\n\nCLI didn't even know the command existed yet), but the web UI side of it worked exactly as advertised the first time I tried it, no config, no opt in flag, just open PRs with the right base branches and watch GitHub connect the dots.\n\nGo forth and stack responsibly. And maybe update your `gh`\n\nCLI before you try the extension route, unlike me.\n\nAI agents write code fast. They also silently remove logic, change behavior, and introduce bugs — without telling you. You often find out in production.\n\ngit-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.\n\nAny feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.\n\n⭐ Star it on GitHub:\n\n| [🇩🇰 Dansk](https://github.com/HexmosTech/git-lrc/readme/README.da.md) | [🇪🇸 Español](https://github.com/HexmosTech/git-lrc/readme/README.es.md) | [🇮🇷 Farsi](https://github.com/HexmosTech/git-lrc/readme/README.fa.md) | [🇫🇮 Suomi](https://github.com/HexmosTech/git-lrc/readme/README.fi.md) | [🇯🇵 日本語](https://github.com/HexmosTech/git-lrc/readme/README.ja.md) | [🇳🇴 Norsk](https://github.com/HexmosTech/git-lrc/readme/README.nn.md) | [🇵🇹 Português](https://github.com/HexmosTech/git-lrc/readme/README.pt.md) | [🇷🇺 Русский](https://github.com/HexmosTech/git-lrc/readme/README.ru.md) | [🇦🇱 Shqip](https://github.com/HexmosTech/git-lrc/readme/README.sq.md) | [🇨🇳 中文](https://github.com/HexmosTech/git-lrc/readme/README.zh.md) | [🇮🇳 हिन्दी](https://github.com/HexmosTech/git-lrc/readme/README.hi.md) |\n\nGenAI today is a **race car without brakes**. It accelerates fast -- you describe something, and large blocks of code appear instantly. But AI agents *silently break things*: they remove logic, relax constraints, introduce expensive cloud calls, leak credentials, and change behavior -- without telling you. You often find out in production.\n\n** git-lrc is your braking system.** It hooks into\n\n`git commit`\n\nand runs an AI review on every diff In short, git-lrc helps **Prevent Outages, Breaches, and Technical Debt Before They Happen**\n\n**At a glance:** [10 risk categories](https://github.com/HexmosTech/git-lrc#what-git-lrc-checks-for) · [100+ failure patterns tracked](https://github.com/HexmosTech/git-lrc#what-git-lrc-checks-for) · every commit…", "url": "https://wpnews.pro/news/ayo-github-quietly-killed-the-unreviewable-mega-pr", "canonical_source": "https://dev.to/lovestaco/ayo-github-quietly-killed-the-unreviewable-mega-pr-3868", "published_at": "2026-08-10 18:19:38+00:00", "updated_at": "2026-08-10 18:48:59.028145+00:00", "lang": "en", "topics": ["developer-tools"], "entities": ["GitHub", "LiveReview", "peektea", "lovestaco"], "alternates": {"html": "https://wpnews.pro/news/ayo-github-quietly-killed-the-unreviewable-mega-pr", "markdown": "https://wpnews.pro/news/ayo-github-quietly-killed-the-unreviewable-mega-pr.md", "text": "https://wpnews.pro/news/ayo-github-quietly-killed-the-unreviewable-mega-pr.txt", "jsonld": "https://wpnews.pro/news/ayo-github-quietly-killed-the-unreviewable-mega-pr.jsonld"}}