If <branch> is specified, git rebase will perform an automatic git checkout <branch> before doing
anything else. Otherwise it remains on the current branch.

If <upstream> is not specified, the upstream configured in branch.<name>.remote and branch.<name>.merge
options will be used; see git-config(1) for details. If you are currently not on any branch or if the
current branch does not have a configured upstream, the rebase will abort.

--continue
    Restart the rebasing process after having resolved a merge conflict.

--abort
    Abort the rebase operation and reset HEAD to the original branch. If <branch> was provided when the
    rebase operation was started, then HEAD will be reset to <branch>. Otherwise HEAD will be reset to
    where it was when the rebase operation was started.

--skip
    Restart the rebasing process by skipping the current patch.

-m, --merge
    Use merging strategies to rebase. When the recursive (default) merge strategy is used, this allows
    rebase to be aware of renames on the upstream side.

    Note that a rebase merge works by replaying each commit from the working branch on top of the
    <upstream> branch. Because of this, when a merge conflict happens, the side reported as ours is the
    so-far rebased series, starting with <upstream>, and theirs is the working branch. In other words,
    the sides are swapped.

-s <strategy>, --strategy=<strategy>
    Use the given merge strategy. If there is no -s option git merge-recursive is used instead. This
    implies --merge.

    Because git rebase replays each commit from the working branch on top of the <upstream> branch using
    the given strategy, using the ours strategy simply discards all patches from the <branch>, which
    makes little sense.

-X <strategy-option>, --strategy-option=<strategy-option>
    Pass the <strategy-option> through to the merge strategy. This implies --merge and, if no strategy
    has been specified, -s recursive. Note the reversal of ours and theirs as noted in above for the -m
    option.

-q, --quiet
    Be quiet. Implies --no-stat.

-v, --verbose
    Be verbose. Implies --stat.

--stat
    Show a diffstat of what changed upstream since the last rebase. The diffstat is also controlled by
    the configuration option rebase.stat.

-n, --no-stat
    Do not show a diffstat as part of the rebase process.

--no-verify
    This option bypasses the pre-rebase hook. See also githooks(5).

--verify
    Allows the pre-rebase hook to run, which is the default. This option can be used to override
    --no-verify. See also githooks(5).

-C<n>
    Ensure at least <n> lines of surrounding context match before and after each change. When fewer lines
    of surrounding context exist they all must match. By default no context is ever ignored.

-f, --force-rebase
    Force the rebase even if the current branch is a descendant of the commit you are rebasing onto.
    Normally non-interactive rebase will exit with the message "Current branch is up to date" in such a
    situation. Incompatible with the --interactive option.

    You may find this (or --no-ff with an interactive rebase) helpful after reverting a topic branch
    merge, as this option recreates the topic branch with fresh commits so it can be remerged
    successfully without needing to "revert the reversion" (see the revert-a-faulty-merge How-To[1] for
    details).

--ignore-whitespace, --whitespace=<option>
    These flag are passed to the git apply program (see git-apply(1)) that applies the patch.
    Incompatible with the --interactive option.

--committer-date-is-author-date, --ignore-date
    These flags are passed to git am to easily change the dates of the rebased commits (see git-am(1)).
    Incompatible with the --interactive option.

-i, --interactive
    Make a list of the commits which are about to be rebased. Let the user edit that list before
    rebasing. This mode can also be used to split commits (see SPLITTING COMMITS below).

-p, --preserve-merges
    Instead of ignoring merges, try to recreate them.

    This uses the --interactive machinery internally, but combining it with the --interactive option
    explicitly is generally not a good idea unless you know what you are doing (see BUGS below).

--root
    Rebase all commits reachable from <branch>, instead of limiting them with an <upstream>. This allows
    you to rebase the root commit(s) on a branch. Must be used with --onto, and will skip changes already
    contained in <newbase> (instead of <upstream>). When used together with --preserve-merges, all root
    commits will be rewritten to have <newbase> as parent instead.

--autosquash, --no-autosquash
    When the commit log message begins with "squash! ..." (or "fixup! ..."), and there is a commit whose
    title begins with the same ..., automatically modify the todo list of rebase -i so that the commit
    marked for squashing comes right after the commit to be modified, and change the action of the moved
    commit from pick to squash (or fixup).

    This option is only valid when the --interactive option is used.

    If the --autosquash option is enabled by default using the configuration variable rebase.autosquash,
    this option can be used to override and disable this setting.

--no-ff
    With --interactive, cherry-pick all rebased commits instead of fast-forwarding over the unchanged
    ones. This ensures that the entire history of the rebased branch is composed of new commits.