Git Rebase Options and Behavioral Differences

", the remainder of the title is taken as a commit specifier, which matches a previous commit if it matches the title or the hash of that commit. If no commit matches fully, matches of the specifier with the start of commit titles are considered. + In the rebase todo list, the actions of squash, fixup and amend commits are changed from `pick` to `squash`, `fixup` or `fixup -C`, respectively, and they are moved right after the commit they modify. The `--interactive` option can be used to review and edit the todo list before proceeding. + The recommended way to create commits with squash markers is by using the `--squash`, `--fixup`, `--fixup=amend:` or `--fixup=reword:` options of linkgit:git-commit[1], which take the target commit as an argument and automatically fill in the title of the new commit from that. + Setting configuration variable `rebase.autoSquash` to true enables auto-squashing by default for interactive rebase. The `--no-autosquash` option can be used to override that setting. + See also INCOMPATIBLE OPTIONS below. --autostash:: --no-autostash:: Automatically create a temporary stash entry before the operation begins, and apply it after the operation ends. This means that you can run rebase on a dirty worktree. However, use with care: the final stash application after a successful rebase might result in non-trivial conflicts. --reschedule-failed-exec:: --no-reschedule-failed-exec:: Automatically reschedule `exec` commands that failed. This only makes sense in interactive mode (or when an `--exec` option was provided). + This option applies once a rebase is started. It is preserved for the whole rebase based on, in order, the command line option provided to the initial `git rebase`, the `rebase.rescheduleFailedExec` configuration (see linkgit:git-config[1] or "CONFIGURATION" below), or it defaults to false. + Recording this option for the whole rebase is a convenience feature. Otherwise an explicit `--no-reschedule-failed-exec` at the start would be overridden by the presence of a `rebase.rescheduleFailedExec=true` configuration when `git rebase --continue` is invoked. Currently, you cannot pass `--[no-]reschedule-failed-exec` to `git rebase --continue`. --update-refs:: --no-update-refs:: Automatically force-update any branches that point to commits that are being rebased. Any branches that are checked out in a worktree are not updated in this way. + If the configuration variable `rebase.updateRefs` is set, then this option can be used to override and disable this setting. + See also INCOMPATIBLE OPTIONS below. INCOMPATIBLE OPTIONS -------------------- The following options: * --apply * --whitespace * -C are incompatible with the following options: * --merge * --strategy * --strategy-option * --autosquash * --rebase-merges * --interactive * --exec * --no-keep-empty * --empty= * --[no-]reapply-cherry-picks when used without --keep-base * --update-refs * --root when used without --onto In addition, the following pairs of options are incompatible: * --keep-base and --onto * --keep-base and --root * --fork-point and --root BEHAVIORAL DIFFERENCES ----------------------- `git rebase` has two primary backends: 'apply' and 'merge'. (The 'apply' backend used to be known as the 'am' backend, but the name led to confusion as it looks like a verb instead of a noun. Also, the 'merge' backend used to be known as the interactive backend, but it is now used for non-interactive cases as well. Both were renamed based on lower-level functionality that underpinned each.) There are some subtle differences in how these two backends behave: Empty commits ~~~~~~~~~~~~~ The 'apply' backend unfortunately drops intentionally empty commits, i.e. commits that started empty, though these are rare in practice. It also drops commits that become empty and has no option for controlling this behavior. The 'merge' backend keeps intentionally empty commits by default (though with `-i` they are

The git rebase command has various options, including --autostash, --reschedule-failed-exec, and --update-refs, which allow for customizing the rebasing process, and it also has behavioral differences between its 'apply' and 'merge' backends, including how they handle empty commits and other edge cases, with some options being incompatible with each other.