名称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 no
at 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.