diff` to locate
the markers (<<<<<<) and make edits to resolve the conflict.  For each
file you edit, you need to tell Git that the conflict has been resolved,
typically this would be done with


    git add <filename>


After resolving the conflict manually and updating the index with the
desired resolution, you can continue the rebasing process with


    git rebase --continue


Alternatively, you can undo the 'git rebase' with


    git rebase --abort

MODE OPTIONS
------------

The options in this section cannot be used with any other option,
including not with each other:

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

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

--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.

--quit::
	Abort the rebase operation but `HEAD` is not reset back to the
	original branch. The index and working tree are also left
	unchanged as a result. If a temporary stash entry was created
	using `--autostash`, it will be saved to the stash list.

--edit-todo::
	Edit the todo list during an interactive rebase.

--show-current-patch::
	Show the current patch in an interactive rebase or when rebase
	is stopped because of conflicts. This is the equivalent of
	`git show REBASE_HEAD`.

OPTIONS
-------
--onto <newbase>::
	Starting point at which to create the new commits. If the
	`--onto` option is not specified, the starting point is
	`<upstream>`.  May be any valid commit, and not just an
	existing branch name.
+
As a special case, you may use "A\...B" as a shortcut for the
merge base of A and B if there is exactly one merge base. You can
leave out at most one of A and B, in which case it defaults to HEAD.

--keep-base::
	Set the starting point at which to create the new commits to the
	merge base of `<upstream>` and `<branch>`. Running
	`git rebase --keep-base <upstream> <branch>` is equivalent to
	running
	`git rebase --reapply-cherry-picks --no-fork-point --onto <upstream>...<branch> <upstream> <branch>`.
+
This option is useful in the case where one is developing a feature on
top of an upstream branch. While the feature is being worked on, the
upstream branch may advance and it may not be the best idea to keep
rebasing on top of the upstream but to keep the base commit as-is. As
the base commit is unchanged this option implies `--reapply-cherry-picks`
to avoid losing commits.
+
Although both this option and `--fork-point` find the merge base between
`<upstream>` and `<branch>`, this option uses the merge base as the _starting
point_ on which new commits will be created, whereas `--fork-point` uses
the merge base to determine the _set of commits_ which will be rebased.
+
See also INCOMPATIBLE OPTIONS below.

<upstream>::
	Upstream branch to compare against.  May be any valid commit,
	not just an existing branch name. Defaults to the configured
	upstream for the current branch.

<branch>::
	Working branch; defaults to `HEAD`.

--apply::
	Use applying strategies to rebase (calling `git-am`
	internally).  This option may become a no-op in the future
	once the merge backend handles everything the apply one does.
+
See also INCOMPATIBLE OPTIONS below.

--empty=(drop|keep|stop)::
	How to handle commits that are not empty to start and are not
	clean cherry-picks of any upstream commit, but which become
	empty after rebasing (because they contain a subset of already
	upstream changes):
+
--
`drop`;;
	The commit will be dropped. This is the default behavior.
`keep`;;
	The commit will be kept. This option is implied when `--exec` is
	specified unless `-i`/`--interactive` is also specified.
`stop`;;
`ask`;;
	The rebase will halt when the commit is applied, allowing you to
	choose whether to drop it, edit files more, or just commit the empty