Comment by apsurd
14 hours ago
OT: Your visual on "stacked PRs" instantly made me understand what a stacked PR is. Thank you!
I had read about them before but for whatever reason it never clicked.
Turns out I already work like this, but I use commits as "PRs in the stack" and I constantly try to keep them up to date and ordered by rebasing, which is a pain.
Given my new insight with the way you displayed it, I had a chat with chatGPT and feel good about giving it a try:
1. 2-3 branches based on a main feature branch
2. can rebase base branch with same frequency, just don't overdo it, conflicts should be base-isolated.
3. You're doing it wrong if conflicts cascade deeply and often
4. Yes merge order matters, but tools can help and generally the isolation is the important piece
If you’re interested in exploring tooling around stacked PRs, I wrote git-spice (https://abhinav.github.io/git-spice/) a while ago. It’s free and open-source, no strings attached.
If you're rebasing a lot, definitely set up rerere (reuse recorded solution) - it improves things enormously.
Do make sure you know how to reset the cache, in case you did a bad conflict resolution because it will keep biting you. Besides that caveat it's a must.
Isn’t this just “Gitflow”?
https://www.atlassian.com/git/tutorials/comparing-workflows/...
After a quick read it seems like gitflow is intended to model a release cycle. It uses branches to coordinate and log releases.
Stacking is meant to make development of non-trivial features more manageable and more likely to enter main safer and faster.
it's specific to each developer's workflow and wouldn't necessarily produce artifacts once merged into main (as gitflow seems to intentionally have a stance on)
Please don’t use git-flow. Every time I see it, it looks like an over-engineer’s wet dream.
Can you say more as to why? The concept is not complex and in our situation at least provides a lot of benefits.
2 replies →