>>flexdi+(OP)
I'm a heavy user of git-spice: https://abhinav.github.io/git-spice (created by a former coworker) and can't really go back to a time without it. While still not nearly as good as Facebook's Phabricator, it's probably the best workflow for small, focused stacked PRs you can achieve in a Github / Gitlab based repository.

>>flexdi+(OP)
Jujutsu comes in handy here for the same usecase:

https://github.com/jj-vcs/jj

https://www.stavros.io/posts/switch-to-jujutsu-already-a-tut...

Also found https://github.com/gitbutlerapp/gitbutler

>>flexdi+(OP)
GitButler handles all of this pretty automatically, if you don't want to deal with the Git gymnastics needed here.

https://blog.gitbutler.com/stacked-branches-with-gitbutler

>>flexdi+(OP)
I believe the author would love stg: https://stacked-git.github.io/guides/tutorial/#patches

>>dimitr+TAe
Half my team switched to JJ this year, and I do find stacking PRs to be much more pleasant now. We had previously tried out Graphite but it didn't really stick.

I wrote up a little way to use JJ's revsets to make it easy to push an entire stack of branches in one command:

https://crabmusket.net/2025/jj-bough-a-useful-alias-for-stac...

>>jbjbjb+kAe
Sweet, looks like this is pretty new (2022).

Running a git command on one branch and multiple branches being affected is really unusual for me! This really does look like it is designed for just this problem, though. Simple overview: https://blog.hot-coffee.dev/en/blog/git_update_refs/

>>enbugg+mGe
I was reading this the other day when I came across this feature because I’m stacking PRs recently which I don’t usually do

https://andrewlock.net/working-with-stacked-branches-in-git-...

Another commenter posted this link which was a bit more succinct

https://blog.hot-coffee.dev/en/blog/git_update_refs/

There isn’t much to it though, you just go to the branch and run git rebase with the update refs flag.

>>swaits+JWe
For me, the answer is stgit. https://stacked-git.github.io/

>>flexdi+(OP)
I've settled on a workflow that reverses the situation. I simply commit all my work to the main branch and cherry pick commits into temporary feature branches only when submitting PRs.

This way I only need to worry about maintaining a single consistent lineage of commits. I've been using this workflow for about a year now and find it to be much easier than juggling and rebasing feature branches.

In case anyone's interested, I made a tool that automates this workflow. The worfklow and tool are described here: https://github.com/bjvanderweij/dflock/

>>flexdi+(OP)
Stacked commits is awesome, but it sucks that with git you need all these workarounds, and that the servers (GitHub etc) are not designed with that workflow in mind.

I left Google a few months back to work on another project. I missed the internal version control so much that I dropped that other project and am now focused http://twigg.vc It's very similar to what's used at Meta and Google. Atomic commits, linear history, auto rebase, code review compatible with stacked commits.

>>unshav+dhf
I more or less use the method described [here](https://steveklabnik.github.io/jujutsu-tutorial/advanced/sim...) for branches. One thing I do change is that I set the bookmark to an empty commit that serves as the head of each branch. When I am satisfied with a commit on head and want to move it to a branch I just `jj rebase -r @ -B branch`. When I want to create a new branch it's just `jj new -A main -B head` and `jj bookmark set branch_name -r @`

>>jhhh+JBf
https://ofcr.se/jujutsu-merge-workflow

With `jjui` this strategy takes only a few keystrokes to do operations like adding/removing parents from merge commits.

It's so nice to have like 4 parallel PRs in flight and then rebase all of them and all the other experimental branches you have on top onto main in 1 command.

Also, I cannot even stress to you how much first-class-conflicts is a game changer. Like seriously you do NOT understand how much better it is to not have to resolve conflicts immediately when rebasing and being able to come back and resolve them whenever you want. It cannot be overstated how much better this is than git.

Also, anonymous branches are SOOOO much better than git stashes.

>>unshav+dhf
"creating a commit would abandon the branch" is certainly something lost in translation. There are other reasons you may have not liked the UX, largely that if you create branches and then add a bunch of commits after it, the branch head doesn't automatically move by default. There is a config setting you can change if you prefer that, or the `jj tug` alias some people set up.

Auto-commit is still a thing, but you can regain the stuff you like with a workflow change, this is called the "squash workflow" and is very popular: https://steveklabnik.github.io/jujutsu-tutorial/real-world-w...

>>flexdi+(OP)
I feel that stacked PR in git should be common knowledge, however many of the documentations are scattered. I found stacked.dev but feels that its not exploring pure-git workflow that well. thats why I tried to collect all of those docs into a single website that's dedicated into that singular workflow. would love to get any feedback:

https://stacked-pr.github.io

(disclaimer: partly supported by AI, but most of the writing structure were made by hand)

>>wakawa+2Ch
This seems to be a common misconception, that many jj users don't understand Git. Most jj users I know were pretty good at Git as far as I can tell. Perhaps you'll find this recent video where Scott Chacon talks about Jujutsu interesting: https://www.youtube.com/watch?v=PsiXflgIC8Q. Scott is a GitHub cofounder, author of Pro Git, and now runs GitButler.

> I don't think making another tool entirely is the right solution.

I considered making the changes to Git but the changes I wanted to make would make the UX so different that it would basically mean introducing a whole parallel command set to Git. I figured it would take ages to get Git to that state, if I could sell the ideas to the Git community at all. By the way, the video above talks about an proposed `git history` series of commands inspired by Jujutsu (also see https://lore.kernel.org/git/20250819-b4-pks-history-builtin-...).

>>qff+hTh
It does via snapshot.auto-track https://docs.jj-vcs.dev/latest/config/#paths-to-automaticall...

>>martin+kCi
Hacker News doesn't support Markdown, but you can indent lines by two spaces to get it formatted like code: https://news.ycombinator.com/formatdoc