We’ve all been there: you’re working on Feature A, but you need to make a small change to a shared utility first. You create a pull request (PR) for the utility change, but now it’s blocked waiting for review. Meanwhile, Feature A is also waiting, and you can’t merge it until the utility PR is approved. Before you know it, you’ve got multiple PRs in various states of review, and keeping track of dependencies becomes a nightmare. I recently started using Aviator on a client project. I’ve found it to be a pretty interesting tool for those who work on big teams and prioritize small PRs.
I recently started using Aviator on a client project, and I’ve found it to be a pretty interesting tool for those who work on big teams and prioritize small PRs.
The Challenge of Managing Dependent PRs
On large teams, especially those that value small, focused PRs, traditional Git workflows don’t handle dependencies well. You either end up with massive PRs that are hard to review, or you’re constantly rebasing and managing complex branch relationships manually. It’s not fun.
You may call it a skill issue, but I call it annoying overhead. Sure, you could manually rebase yourself and track which PR depends on which. But that’s not what I want to spend my time or energy on.
How Aviator Simplifies Stacked PRs
Aviator is a CLI tool that handles the heavy lifting of managing branching relationships. Instead of manually tracking which PR depends on which and constantly rebasing, Aviator manages it all for you.
The workflow is straightforward. Create your first PR, then use av branch to create a new branch that builds on top of it. The second PR automatically targets the first PR branch, not main, so reviewers can see incremental changes and you can get both PRs reviewed in parallel.
What happens when someone has feedback on the parent PR? You make the changes, commit to that branch, and Aviator automatically handles updating the child PRs. No need to manually rebase each dependent branch. Aviator keeps everything in sync.
When the first PR gets merged, Aviator’s av sync command is where the real magic happens. It automatically rebases your remaining branches on top of the updated main, updates PR targets, and makes the git history of PRs a lot cleaner. No more manual rebasing. Aviator handles all the branching relationship management, keeping your git history clean and your PRs properly targeted.
Real-World Impact
This approach has accelerated review cycles on large teams. With stacked PRs, multiple reviewers can work on different parts of your feature simultaneously, and you can keep PRs small and focused without the manual overhead of managing branch dependencies.
A few tips I’ve picked up:
- Keep your stacks shallow when possible (2-4 PRs is usually the sweet spot)
- Use descriptive branch names
- Run
av treeregularly to visualize your current stack. - Make sure reviewers understand that PRs are stacked. Children PRs can be opened as drafts, making it clear alongside a note which PRs are dependent on others before merging.
While stacked PRs aren’t for every team or every situation, there’s no denying that tools like Aviator are capable for alleviating pain common on large fast moving teams. Aviator handles the heavy lifting of managing branching relationships, making it easy to maintain a workflow of small, focused PRs.
If you’re working on a team that values small PRs and parallel reviews, Aviator is worth adding to your toolkit.
Give it a try on your next feature, I hope it saves you time.