Suraj Narwade’s Post

GitHub Stacked PRs Break large changes into small, reviewable pull requests that build on each other — with native GitHub support and the gh stack CLI.

GitHub is bringing stacked PRs natively into the platform — the ability to break large changes into a clean chain of small, focused, reviewable pull requests that build on each other. Stacked diffs aren’t new — they’ve been battle-tested for years at Google, Meta, and other FAANG companies. The real value is velocity: breaking big changes into small, incremental pieces that ship fast instead of getting stuck in one massive PR. This approach finally helps teams shake off those old SVN-era habits — giant monolithic diffs that were painful to review, full of conflicts, and slowed everything down. With stacked PRs, you keep momentum, get faster feedback, and land changes efficiently. You can create a chain where each PR targets the branch of the one below it. Everything merges smoothly into main, and reviewers get proper context without drowning in huge diffs. Graphite built some genuinely impressive stacked diff tooling, but I suspect most teams will lean toward GitHub’s built-in experience as it matures. We’ll see what creative open-source solutions the community builds to tidy up the workflow. What stands out: 🡆 A clean stack map in the GitHub PR UI for easy navigation between layers 🡆 Automatic cascading rebases — merge one and the rest of the stack updates intelligently 🡆 Full branch protection and CI enforcement on the final target branch 🡆 The new gh stack CLI that makes creating layers, pushing the entire stack, submitting all PRs at once, and handling rebases seamless 🡆A clean linear change history! No slop commits! That said, having to rely on an external CLI tool — unlike Gerrit’s more integrated approach — still feels a bit unfortunate. This feels like the end-to-end developer workflow finally coming together inside GitHub itself. For most teams already living in GitHub, the convenience and tight integration will be very hard to beat. This goes some way toward GitHub repairing the anti-patterns they have perpetuated — hopefully their next trick will be doing something to curb repo sprawl. ↳ https://lnkd.in/gYNeaK8T

I saw an article today about the death of pull requests. Recently GitHub rolled out the ability to disable pull requests, and the discussion suggested that teams might soon consist of agents, and no human code reviews needed. But wait, GitHub is also releasing soon stacked PRs - and stacks are popular in big tech for large projects. Pull requests are a collaborative tool, and now there are more options to fine tune it for your project. https://lnkd.in/gYxSPQeu

Recently, I’ve been exploring Stacked PRs — now supported natively on GitHub. Instead of pushing one big change, you break it into smaller pull requests that build on top of each other. Each PR stays focused, easier to understand, and quicker to review. It’s a simple shift, but it changes the workflow a lot: Smaller changes → faster reviews Better context → clearer feedback Early reviews → fewer surprises later Safer merges overall There’s a bit of overhead (rebasing and managing multiple branches), but for larger features, it feels like a much cleaner approach. If PRs in your team are constantly getting delayed, it might not be a people problem. It might just be how the work is structured. If you want to check it out: https://lnkd.in/dXMhPvyY #softwareengineering #github #pullrequest #codereview #developertips #webdevelopment

If you’ve ever rebased the same PR 5 times, this is for you. The problem is real, Big PRs? → No one really reviews them properly → “LGTM 👍” and move on Small PRs? → Constant rebasing → Conflicts every few hours → Context gets lost Every team I’ve worked with has struggled with this trade-off. And honestly, there’s never been a clean solution on GitHub. But now, seems the wait is over, GitHub is rolling out Stacked PRs (in preview). Instead of one giant PR, you can: - Break work into smaller logical pieces - Stack them on top of each other - Review them independently without losing context This is one of those features that sounds small…but fixes a daily frustration. Read More: https://lnkd.in/gc5s4wmJ #developer #stackPR #github #productivity #devEx

Your GitHub Actions Workflow is a Waste of Time. Stop treating your CI as a separate, fragile ecosystem that needs its own set of rules. Most developers waste hours debugging “it works on my machine” issues because their GitHub Actions workflows are trying to solve provisioning and caching problems that have already been solved in development. By shifting to self-hosted runners and leveraging environment managers like Devenv, you can achieve perfect parity between your local terminal and your CI, turning a complex YAML headache into a simple, lightning-fast 24-second feedback loop. Link in the comment.

Found the github Zen API, huge fan > curl https://api.github.com/zen Speak like a human. > curl https://api.github.com/zen Encourage flow. > curl https://api.github.com/zen Practicality beats purity.

🛠️GitHub launched gh skill, a new CLI command to manage agent skills What it lets you do: ▶️ discover and install skills from GitHub repositories ▶️ manage and update them from the CLI ▶️ publish your own skills ▶️ use the same skills across different agent hosts GitHub describes agent skills as portable instructions, scripts, and resources that can work across tools like GitHub Copilot, Claude Code, Cursor, Codex, and Gemini CLI Have you already tried it? #GitHub #GitHubCopilot #CLI #Agents #DeveloperTools

 GitHub's 'gh skill' CLI unleashed: Build, discover, install & share portable agent skills that supercharge Copilot, Claude Code and more. Thanks Silvia Rodenas Vaquero for sharing this!

Github is really creating some gravity in the AI Game, which is hard to resist. Will GH Copilot become - to the vast majority of engineers - what Word was for any office job in the Late 90s/early 2000s? #genai #sdlc #engineering #whereisclippy