`--no-overwrite-ignore`::
	Silently overwrite ignored files from the merge result. This
	is the default behavior. Use `--no-overwrite-ignore` to abort.

`--abort`::
	Abort the current conflict resolution process, and
	try to reconstruct the pre-merge state. If an autostash entry is
	present, apply it to the worktree.
+
If there were uncommitted worktree changes present when the merge
started, `git merge --abort` will in some cases be unable to
reconstruct these changes. It is therefore recommended to always
commit or stash your changes before running `git merge`.
+
`git merge --abort` is equivalent to `git reset --merge` when
`MERGE_HEAD` is present unless `MERGE_AUTOSTASH` is also present in
which case `git merge --abort` applies the stash entry to the worktree
whereas `git reset --merge` will save the stashed changes in the stash
list.

`--quit`::
	Forget about the current merge in progress. Leave the index
	and the working tree as-is. If `MERGE_AUTOSTASH` is present, the
	stash entry will be saved to the stash list.

`--continue`::
	After a `git merge` stops due to conflicts you can conclude the
	merge by running `git merge --continue` (see "HOW TO RESOLVE
	CONFLICTS" section below).

`<commit>...`::
	Commits, usually other branch heads, to merge into our branch.
	Specifying more than one commit will create a merge with
	more than two parents (affectionately called an Octopus merge).
+
If no commit is given from the command line, merge the remote-tracking
branches that the current branch is configured to use as its upstream.
See also the configuration section of this manual page.
+
When `FETCH_HEAD` (and no other commit) is specified, the branches
recorded in the `.git/FETCH_HEAD` file by the previous invocation
of `git fetch` for merging are merged to the current branch.


PRE-MERGE CHECKS
----------------

Before applying outside changes, you should get your own work in
good shape and committed locally, so it will not be clobbered if
there are conflicts.  See also linkgit:git-stash[1].
`git pull` and `git merge` will stop without doing anything when
local uncommitted changes overlap with files that `git pull`/`git
merge` may need to update.

To avoid recording unrelated changes in the merge commit,
`git pull` and `git merge` will also abort if there are any changes
registered in the index relative to the `HEAD` commit.  (Special
narrow exceptions to this rule may exist depending on which merge
strategy is in use, but generally, the index must match `HEAD`.)

If all named commits are already ancestors of `HEAD`, `git merge`
will exit early with the message "Already up to date."

FAST-FORWARD MERGE
------------------

Often the current branch head is an ancestor of the named commit.
This is the most common case especially when invoked from `git
pull`: you are tracking an upstream repository, you have committed
no local changes, and now you want to update to a newer upstream
revision.  In this case, a new commit is not needed to store the
combined history; instead, the `HEAD` (along with the index) is
updated to point at the named commit, without creating an extra
merge commit.

This behavior can be suppressed with the `--no-ff` option.

TRUE MERGE
----------

Except in a fast-forward merge (see above), the branches to be
merged must be tied together by a merge commit that has both of them
as its parents.

A merged version reconciling the changes from all branches to be
merged is committed, and your `HEAD`, index, and working tree are
updated to it.  It is possible to have modifications in the working
tree as long as they do not overlap; the update will preserve them.

When it is not obvious how to reconcile the changes, the following
happens:

1. The `HEAD` pointer stays the same.
2. The `MERGE_HEAD` ref is set to point to the other branch head.
3. Paths that merged cleanly are updated both in the index file and
   in your working tree.
4. For conflicting paths, the index file records up to three
   versions: stage 1 stores