名称NAME
git-merge - 将两个或多个开发历史联系在一起
概要SYNOPSIS
git merge [-n] [--stat] [--no-commit] [--squash] [--[no-]edit]
[--no-verify] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]]
[--[no-]allow-unrelated-histories]
[--[no-]rerere-autoupdate] [-m <msg>] [-F <file>] [<commit>…]
git merge (--continue | --abort | --quit)描述DESCRIPTION
将命名提交中的更改（自其历史记录与当前分支分开以来的时间）合并到当前分支中。 git pull 使用此命令来合并另一个存储库中的更改，并且可以手动使用它来将一个分支中的更改合并到另一个分支中。
假设存在以下历史记录，并且当前分支为“ master”：
A---B---C topic
/
D---E---F---G master
然后，“git merge topic”将在topic 分支上所做的更改重放在master之上，因为它与master在commit E岔开，直到其当前commit C，并将结果记录在新提交中，并带有名称 两个父提交和一个来自用户描述更改的日志消息。
A---B---C topic
/ \
D---E---F---G---H master
第二种语法（“git merge --abort”）只能在合并导致冲突后运行。
git merge --abort 将中止合并过程并尝试重建合并前状态。 但是，如果合并开始时有未提交的更改（特别是在合并开始后进一步修改了这些更改），则git merge --abort 在某些情况下将无法重建原始（合并前）更改。因此，
警告：不建议对重要的未提交的更改进行git merge：可能的话，它可能使你处于在发生冲突的情况下很难退出的状态。
第三种语法（"git merge --continue"）只能在合并导致冲突后运行。
选项OPTIONS
--commit
--no-commit
执行合并并提交结果。 此选项可用于覆盖--no-commit。
使用--no-commit可以在创建一个合并提交（merge commit）之前执行合并并停止，从而使用户有机会在提交之前检查并进一步调整合并结果。
请注意，快进更新不会创建一个合并提交，因此无法通过--no-commit停止这些合并。 因此，如果要确保合并命令不会更改或更新分支，请使用--no-ff和--no-commit。
--edit -e
--no-edit
在提交成功的合并之前，调用编辑器以进一步编辑自动生成的合并消息，以便用户可以解释并证明合并的合理性。
--no-edit选项可用于接受自动生成的消息（通常不建议这样做）。
如果要在命令行中使用-m选项提供草稿消息，并希望在编辑器中对其进行编辑，则--edit（或-e）选项仍然有用。
Older scripts may depend on the historical behaviour of not allowing the user to edit the merge log message. They will see an editor opened when they run git merge. To make it easier to adjust such scripts to the updated behaviour, the environment variable GIT_MERGE_AUTOEDIT can be set to noat the beginning of them.
--cleanup=<mode>
This option determines how the merge message will be cleaned up before committing. See git-commit[1]for more details. In addition, if the <mode> is given a value of scissors, scissors will be appended to MERGE_MSG before being passed on to the commit machinery in the case of a merge conflict.
--ff
--no-ff
--ff-only
Specifies how a merge is handled when the merged-in history is already a descendant of the current history. --ff is the default unless merging an annotated (and possibly signed) tag that is not stored in its natural place in the refs/tags/ hierarchy, in which case --no-ff is assumed.
With --ff, when possible resolve the merge as a fast-forward (only update the branch pointer to match the merged branch; do not create a merge commit). When not possible (when the merged-in history is not a descendant of the current history), create a merge commit.
With --no-ff, create a merge commit in all cases, even when the merge could instead be resolved as a fast-forward.
With --ff-only, resolve the merge as a fast-forward when possible. When not possible, refuse to merge and exit with a non-zero status.
-S[<keyid>]
--gpg-sign[=<keyid>]
GPG-sign the resulting merge commit. The keyid argument is optional and defaults to the committer identity; if specified, it must be stuck to the option without a space.
--log[=<n>]
--no-log
In addition to branch names, populate the log message with one-line descriptions from at most <n> actual commits that are being merged. See also git-fmt-merge-msg[1].
With --no-log do not list one-line descriptions from the actual commits being merged.
--signoff
--no-signoff
Add Signed-off-by line by the committer at the end of the commit log message. The meaning of a signoff depends on the project, but it typically certifies that committer has the rights to submit this work under the same license and agrees to a Developer Certificate of Origin (see http://developercertificate.org/ for more information).
With --no-signoff do not add a Signed-off-by line.
--stat
-n
--no-stat
在合并结束时显示diffstat。 diffstat也由配置选项merge.stat控制。
使用-n或--no-stat在合并结束时不显示diffstat。
--squash
--no-squash
Produce the working tree and index state as if a real merge happened (except for the merge information), but do not actually make a commit, move the HEAD, or record $GIT_DIR/MERGE_HEAD (to cause the next git commit command to create a merge commit). This allows you to create a single commit on top of the current branch whose effect is the same as merging another branch (or more in case of an octopus).
With --no-squash perform the merge and commit the result. This option can be used to override --squash.
With --squash, --commit is not allowed, and will fail.
--no-verify
This option bypasses the pre-merge and commit-msg hooks. See also githooks[5].
-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-recursivewhen merging a single head, git merge-octopus otherwise).
-X <option>
--strategy-option=<option>
将指定的合并策略选项传递到合并策略。
--verify-signatures
--no-verify-signatures
Verify that the tip commit of the side branch being merged is signed with a valid key, i.e. a key that has a valid uid: in the default trust model, this means the signing key has been signed by a trusted key. If the tip commit of the side branch is not signed with a valid key, the merge is aborted.
--summary
--no-summary
Synonyms to --stat and --no-stat; these are deprecated and will be removed in the future.
-q
--quiet
Operate quietly. Implies --no-progress.
-v
--verbose
Be verbose.
--progress
--no-progress
Turn progress on/off explicitly. If neither is specified, progress is shown if standard error is connected to a terminal. Note that not all merge strategies may support progress reporting.
--allow-unrelated-histories
By default, git merge command refuses to merge histories that do not share a common ancestor. This option can be used to override this safety when merging histories of two projects that started their lives independently. As that is a very rare occasion, no configuration variable to enable this by default exists and will not be added.
-m <msg>
设置要用于合并提交的提交消息（如果创建了一个）。
如果指定了--log，则将被合并的提交的简短日志附加到指定的消息中。
The git fmt-merge-msg command can be used to give a good default for automated git mergeinvocations. The automated message can include the branch description.
-F <file>
--file=<file>
Read the commit message to be used for the merge commit (in case one is created).
If --log is specified, a shortlog of the commits being merged will be appended to the specified message.
--rerere-autoupdate
--no-rerere-autoupdate
Allow the rerere mechanism to update the index with the result of auto-conflict resolution if possible.
--overwrite-ignore
--no-overwrite-ignore
Silently overwrite ignored files from the merge result. This is the default behavior. Use --no-overwrite-ignore to abort.
--abort
中止当前的冲突解决过程，并尝试重构合并前状态。
如果合并开始时存在未提交的工作树更改，则git merge --abort在某些情况下将无法重构这些更改。 因此，建议始终在运行git merge之前提交commit或存储stash更改。
git merge --abort 等效于MERGE_HEAD存在时的git reset --merge。
--quit
Forget about the current merge in progress. Leave the index and the working tree as-is.
--continue
由于冲突而停止git合并后，您可以通过运行git merge --continue结束合并（请参见下面的“如何解决冲突”部分）。
<commit>…
提交（通常是其他分支的head提交）以合并到我们的分支中。 指定多个提交将与两个以上的父级创建一个合并（最好称为章鱼合并(八达通合并)）。
如果没有从命令行给出提交，则合并当前分支配置的作为其上游的远程跟踪分支。 另请参见本手册页的“配置”部分。
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.
