Also see the git-rebase(1) manpage. For information on how to resolve conflicts that occur during rebases see the preceding section.
magit-rebase) ¶This transient prefix command binds the following suffix commands along with the appropriate infix arguments and displays them in a temporary buffer until a suffix is invoked.
When no rebase is in progress, then the transient features the following suffix commands.
Using one of these commands starts a rebase sequence. Git might then stop somewhere along the way, either because you told it to do so, or because applying a commit failed due to a conflict. When that happens, then the status buffer shows information about the rebase sequence which is in progress in a section similar to a log section. See Information About In-Progress Rebase.
For information about the upstream and the push-remote, see The Two Remotes.
magit-rebase-onto-pushremote) ¶This command rebases the current branch onto its push-remote.
With a prefix argument or when the push-remote is either not configured or unusable, then let the user first configure the push-remote.
magit-rebase-onto-upstream) ¶This command rebases the current branch onto its upstream branch.
With a prefix argument or when the upstream is either not configured or unusable, then let the user first configure the upstream.
magit-rebase-branch) ¶This command rebases the current branch onto a branch read in the minibuffer. All commits that are reachable from head but not from the selected branch TARGET are being rebased.
magit-rebase-subset) ¶This command starts a non-interactive rebase sequence to transfer
commits from START to HEAD onto NEWBASE. START has to be selected
from a list of recent commits.
By default Magit uses the --autostash argument, which causes
uncommitted changes to be stored in a stash before the rebase begins.
These changes are restored after the rebase completes and if possible
the stash is removed. If the stash does not apply cleanly, then the
stash is not removed. In case something goes wrong when resolving
the conflicts, this allows you to start over.
Even though one of the actions is dedicated to interactive rebases,
the transient also features the infix argument --interactive. This
can be used to turn one of the other, non-interactive rebase variants
into an interactive rebase.
For example if you want to clean up a feature branch and at the same
time rebase it onto master, then you could use r-iu. But we recommend
that you instead do that in two steps. First use ri to cleanup the
feature branch, and then in a second step ru to rebase it onto master.
That way if things turn out to be more complicated than you thought
and/or you make a mistake and have to start over, then you only have
to redo half the work.
Explicitly enabling --interactive won’t have an effect on the
following commands as they always use that argument anyway, even if it
is not enabled in the transient.
magit-rebase-interactive) ¶This command starts an interactive rebase sequence.
magit-rebase-autosquash) ¶This command combines squash and fixup commits with their intended targets.
magit-rebase-edit-commit) ¶This command starts an interactive rebase sequence that lets the user edit a single older commit.
magit-rebase-reword-commit) ¶This command starts an interactive rebase sequence that lets the user reword a single older commit.
magit-rebase-remove-commit) ¶This command removes a single older commit using rebase.
When a rebase is in progress, then the transient instead features the following suffix commands.
magit-rebase-continue) ¶This command restart the current rebasing operation.
In some cases this pops up a commit message buffer for you do edit. With a prefix argument the old message is reused as-is.
magit-rebase-skip) ¶This command skips the current commit and restarts the current rebase operation.
magit-rebase-edit) ¶This command lets the user edit the todo list of the current rebase operation.
magit-rebase-abort) ¶This command aborts the current rebase operation, restoring the original branch.