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