SYNOPSIS
--------
[verse]
-'git rebase' [-i | --interactive] [-v | --verbose] [-m | --merge]
- [-s <strategy> | --strategy=<strategy>] [--no-verify]
- [-C<n>] [ --whitespace=<option>] [-p | --preserve-merges]
- [--onto <newbase>] <upstream> [<branch>]
+'git rebase' [-i | --interactive] [options] [--onto <newbase>]
+ <upstream> [<branch>]
+'git rebase' [-i | --interactive] [options] --onto <newbase>
+ --root [<branch>]
+
'git rebase' --continue | --skip | --abort
DESCRIPTION
All changes made by commits in the current branch but that are not
in <upstream> are saved to a temporary area. This is the same set
-of commits that would be shown by `git log <upstream>..HEAD`.
+of commits that would be shown by `git log <upstream>..HEAD` (or
+`git log HEAD`, if --root is specified).
The current branch is reset to <upstream>, or <newbase> if the
--onto option was supplied. This has the exact same effect as
git rebase --abort
+CONFIGURATION
+-------------
+
+rebase.stat::
+ Whether to show a diffstat of what changed upstream since the last
+ rebase. False by default.
+
OPTIONS
-------
<newbase>::
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; can be supplied more than
- once to specify them in the order they should be tried.
- If there is no `-s` option, a built-in list of strategies
- is used instead ('git-merge-recursive' when merging a single
- head, 'git-merge-octopus' otherwise). This implies --merge.
+ 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.
+
+-q::
+--quiet::
+ Be quiet. Implies --no-stat.
-v::
--verbose::
- Display a diffstat of what changed upstream since the last rebase.
+ 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 linkgit:githooks[5].
context exist they all must match. By default no context is
ever ignored.
---whitespace=<nowarn|warn|error|error-all|strip>::
- This flag is passed to the 'git-apply' program
+-f::
+--force-rebase::
+ Force the rebase even if the current branch is a descendant
+ of the commit you are rebasing onto. Normally the command will
+ exit with the message "Current branch is up to date" in such a
+ situation.
+
+--ignore-whitespace::
+--whitespace=<option>::
+ These flag are passed to the 'git-apply' program
(see linkgit: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 linkgit:git-am[1]).
-i::
--interactive::
--preserve-merges::
Instead of ignoring merges, try to recreate them.
+--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.
+
include::merge-strategies.txt[]
NOTES
the files and/or the commit message, amend the commit, and continue
rebasing.
+If you just want to edit the commit message for a commit, replace the
+command "pick" with the command "reword".
+
If you want to fold two or more commits into one, replace the command
"pick" with "squash" for the second and subsequent commit. If the
commits had different authors, it will attribute the squashed commit to
the author of the first commit.
-In both cases, or when a "pick" does not succeed (because of merge
-errors), the loop will stop to let you fix things, and you can continue
-the loop with `git rebase --continue`.
+'git-rebase' will stop when "pick" has been replaced with "edit" or
+when a command fails due to merge errors. When you are done editing
+and/or resolving conflicts you can continue with `git rebase --continue`.
For example, if you want to reorder the last 5 commits, such that what
was HEAD~4 becomes the new HEAD. To achieve that, you would call