SYNOPSIS
--------
-'git-rebase' [--onto <newbase>] <upstream> [<branch>]
+'git-rebase' [--merge] [--onto <newbase>] <upstream> [<branch>]
-'git-rebase' --continue
-
-'git-rebase' --abort
+'git-rebase' --continue | --skip | --abort
DESCRIPTION
-----------
It is possible that a merge failure will prevent this process from being
completely automatic. You will have to resolve any such merge failure
-and run `git rebase --continue`. If you can not resolve the merge
-failure, running `git rebase --abort` will restore the original <branch>
-and remove the working files found in the .dotest directory.
+and run `git rebase --continue`. Another option is to bypass the commit
+that caused the merge failure with `git rebase --skip`. To restore the
+original <branch> and remove the .dotest working files, use the command
+`git rebase --abort` instead.
Note that if <branch> is not specified on the command line, the currently
checked out branch is used.
--abort::
Restore the original branch and abort the rebase operation.
+--skip::
+ Restart the rebasing process by skipping the current patch.
+ This does not work with the --merge option.
+
+--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.
+
+-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.
+
+include::merge-strategies.txt[]
+
NOTES
-----
When you rebase a branch, you are changing its history in a way that