| blob | b758d5556caaeeb0a439d67c46100e5fa0d34cd4 |
1 git-merge(1)
2 ============
4 NAME
5 ----
6 git-merge - Join two or more development histories together
9 SYNOPSIS
10 --------
11 [verse]
12 'git merge' [-n] [--stat] [--no-commit] [--squash] [--[no-]edit]
13 [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]]
14 [--[no-]allow-unrelated-histories]
15 [--[no-]rerere-autoupdate] [-m <msg>] [<commit>...]
16 'git merge' <msg> HEAD <commit>...
17 'git merge' --abort
19 DESCRIPTION
20 -----------
21 Incorporates changes from the named commits (since the time their
22 histories diverged from the current branch) into the current
23 branch. This command is used by 'git pull' to incorporate changes
24 from another repository and can be used by hand to merge changes
25 from one branch into another.
27 Assume the following history exists and the current branch is
28 "`master`":
30 ------------
31 A---B---C topic
32 /
33 D---E---F---G master
34 ------------
36 Then "`git merge topic`" will replay the changes made on the
37 `topic` branch since it diverged from `master` (i.e., `E`) until
38 its current commit (`C`) on top of `master`, and record the result
39 in a new commit along with the names of the two parent commits and
40 a log message from the user describing the changes.
42 ------------
43 A---B---C topic
44 / \
45 D---E---F---G---H master
46 ------------
48 The second syntax (<msg> `HEAD` <commit>...) is supported for
49 historical reasons. Do not use it from the command line or in
50 new scripts. It is the same as `git merge -m <msg> <commit>...`.
52 The third syntax ("`git merge --abort`") can only be run after the
53 merge has resulted in conflicts. 'git merge --abort' will abort the
54 merge process and try to reconstruct the pre-merge state. However,
55 if there were uncommitted changes when the merge started (and
56 especially if those changes were further modified after the merge
57 was started), 'git merge --abort' will in some cases be unable to
58 reconstruct the original (pre-merge) changes. Therefore:
60 *Warning*: Running 'git merge' with non-trivial uncommitted changes is
61 discouraged: while possible, it may leave you in a state that is hard to
62 back out of in the case of a conflict.
65 OPTIONS
66 -------
67 include::merge-options.txt[]
69 -S[<keyid>]::
70 --gpg-sign[=<keyid>]::
71 GPG-sign the resulting merge commit. The `keyid` argument is
72 optional and defaults to the committer identity; if specified,
73 it must be stuck to the option without a space.
75 -m <msg>::
76 Set the commit message to be used for the merge commit (in
77 case one is created).
78 +
79 If `--log` is specified, a shortlog of the commits being merged
80 will be appended to the specified message.
81 +
82 The 'git fmt-merge-msg' command can be
83 used to give a good default for automated 'git merge'
84 invocations. The automated message can include the branch description.
86 --[no-]rerere-autoupdate::
87 Allow the rerere mechanism to update the index with the
88 result of auto-conflict resolution if possible.
90 --abort::
91 Abort the current conflict resolution process, and
92 try to reconstruct the pre-merge state.
93 +
94 If there were uncommitted worktree changes present when the merge
95 started, 'git merge --abort' will in some cases be unable to
96 reconstruct these changes. It is therefore recommended to always
97 commit or stash your changes before running 'git merge'.
98 +
99 'git merge --abort' is equivalent to 'git reset --merge' when
100 `MERGE_HEAD` is present.
102 <commit>...::
103 Commits, usually other branch heads, to merge into our branch.
104 Specifying more than one commit will create a merge with
105 more than two parents (affectionately called an Octopus merge).
106 +
107 If no commit is given from the command line, merge the remote-tracking
108 branches that the current branch is configured to use as its upstream.
109 See also the configuration section of this manual page.
110 +
111 When `FETCH_HEAD` (and no other commit) is specified, the branches
112 recorded in the `.git/FETCH_HEAD` file by the previous invocation
113 of `git fetch` for merging are merged to the current branch.
116 PRE-MERGE CHECKS
117 ----------------
119 Before applying outside changes, you should get your own work in
120 good shape and committed locally, so it will not be clobbered if
121 there are conflicts. See also linkgit:git-stash[1].
122 'git pull' and 'git merge' will stop without doing anything when
123 local uncommitted changes overlap with files that 'git pull'/'git
124 merge' may need to update.
126 To avoid recording unrelated changes in the merge commit,
127 'git pull' and 'git merge' will also abort if there are any changes
128 registered in the index relative to the `HEAD` commit. (One
129 exception is when the changed index entries are in the state that
130 would result from the merge already.)
132 If all named commits are already ancestors of `HEAD`, 'git merge'
133 will exit early with the message "Already up-to-date."
135 FAST-FORWARD MERGE
136 ------------------
138 Often the current branch head is an ancestor of the named commit.
139 This is the most common case especially when invoked from 'git
140 pull': you are tracking an upstream repository, you have committed
141 no local changes, and now you want to update to a newer upstream
142 revision. In this case, a new commit is not needed to store the
143 combined history; instead, the `HEAD` (along with the index) is
144 updated to point at the named commit, without creating an extra
145 merge commit.
147 This behavior can be suppressed with the `--no-ff` option.
149 TRUE MERGE
150 ----------
152 Except in a fast-forward merge (see above), the branches to be
153 merged must be tied together by a merge commit that has both of them
154 as its parents.
156 A merged version reconciling the changes from all branches to be
157 merged is committed, and your `HEAD`, index, and working tree are
158 updated to it. It is possible to have modifications in the working
159 tree as long as they do not overlap; the update will preserve them.
161 When it is not obvious how to reconcile the changes, the following
162 happens:
164 1. The `HEAD` pointer stays the same.
165 2. The `MERGE_HEAD` ref is set to point to the other branch head.
166 3. Paths that merged cleanly are updated both in the index file and
167 in your working tree.
168 4. For conflicting paths, the index file records up to three
169 versions: stage 1 stores the version from the common ancestor,
170 stage 2 from `HEAD`, and stage 3 from `MERGE_HEAD` (you
171 can inspect the stages with `git ls-files -u`). The working
172 tree files contain the result of the "merge" program; i.e. 3-way
173 merge results with familiar conflict markers `<<<` `===` `>>>`.
174 5. No other changes are made. In particular, the local
175 modifications you had before you started merge will stay the
176 same and the index entries for them stay as they were,
177 i.e. matching `HEAD`.
179 If you tried a merge which resulted in complex conflicts and
180 want to start over, you can recover with `git merge --abort`.
182 MERGING TAG
183 -----------
185 When merging an annotated (and possibly signed) tag, Git always
186 creates a merge commit even if a fast-forward merge is possible, and
187 the commit message template is prepared with the tag message.
188 Additionally, if the tag is signed, the signature check is reported
189 as a comment in the message template. See also linkgit:git-tag[1].
191 When you want to just integrate with the work leading to the commit
192 that happens to be tagged, e.g. synchronizing with an upstream
193 release point, you may not want to make an unnecessary merge commit.
195 In such a case, you can "unwrap" the tag yourself before feeding it
196 to `git merge`, or pass `--ff-only` when you do not have any work on
197 your own. e.g.
199 ----
200 git fetch origin
201 git merge v1.2.3^0
202 git merge --ff-only v1.2.3
203 ----
206 HOW CONFLICTS ARE PRESENTED
207 ---------------------------
209 During a merge, the working tree files are updated to reflect the result
210 of the merge. Among the changes made to the common ancestor's version,
211 non-overlapping ones (that is, you changed an area of the file while the
212 other side left that area intact, or vice versa) are incorporated in the
213 final result verbatim. When both sides made changes to the same area,
214 however, Git cannot randomly pick one side over the other, and asks you to
215 resolve it by leaving what both sides did to that area.
217 By default, Git uses the same style as the one used by the "merge" program
218 from the RCS suite to present such a conflicted hunk, like this:
220 ------------
221 Here are lines that are either unchanged from the common
222 ancestor, or cleanly resolved because only one side changed.
223 <<<<<<< yours:sample.txt
224 Conflict resolution is hard;
225 let's go shopping.
226 =======
227 Git makes conflict resolution easy.
228 >>>>>>> theirs:sample.txt
229 And here is another line that is cleanly resolved or unmodified.
230 ------------
232 The area where a pair of conflicting changes happened is marked with markers
233 `<<<<<<<`, `=======`, and `>>>>>>>`. The part before the `=======`
234 is typically your side, and the part afterwards is typically their side.
236 The default format does not show what the original said in the conflicting
237 area. You cannot tell how many lines are deleted and replaced with
238 Barbie's remark on your side. The only thing you can tell is that your
239 side wants to say it is hard and you'd prefer to go shopping, while the
240 other side wants to claim it is easy.
242 An alternative style can be used by setting the "merge.conflictStyle"
243 configuration variable to "diff3". In "diff3" style, the above conflict
244 may look like this:
246 ------------
247 Here are lines that are either unchanged from the common
248 ancestor, or cleanly resolved because only one side changed.
249 <<<<<<< yours:sample.txt
250 Conflict resolution is hard;
251 let's go shopping.
252 |||||||
253 Conflict resolution is hard.
254 =======
255 Git makes conflict resolution easy.
256 >>>>>>> theirs:sample.txt
257 And here is another line that is cleanly resolved or unmodified.
258 ------------
260 In addition to the `<<<<<<<`, `=======`, and `>>>>>>>` markers, it uses
261 another `|||||||` marker that is followed by the original text. You can
262 tell that the original just stated a fact, and your side simply gave in to
263 that statement and gave up, while the other side tried to have a more
264 positive attitude. You can sometimes come up with a better resolution by
265 viewing the original.
268 HOW TO RESOLVE CONFLICTS
269 ------------------------
271 After seeing a conflict, you can do two things:
273 * Decide not to merge. The only clean-ups you need are to reset
274 the index file to the `HEAD` commit to reverse 2. and to clean
275 up working tree changes made by 2. and 3.; `git merge --abort`
276 can be used for this.
278 * Resolve the conflicts. Git will mark the conflicts in
279 the working tree. Edit the files into shape and
280 'git add' them to the index. Use 'git commit' to seal the deal.
282 You can work through the conflict with a number of tools:
284 * Use a mergetool. `git mergetool` to launch a graphical
285 mergetool which will work you through the merge.
287 * Look at the diffs. `git diff` will show a three-way diff,
288 highlighting changes from both the `HEAD` and `MERGE_HEAD`
289 versions.
291 * Look at the diffs from each branch. `git log --merge -p <path>`
292 will show diffs first for the `HEAD` version and then the
293 `MERGE_HEAD` version.
295 * Look at the originals. `git show :1:filename` shows the
296 common ancestor, `git show :2:filename` shows the `HEAD`
297 version, and `git show :3:filename` shows the `MERGE_HEAD`
298 version.
301 EXAMPLES
302 --------
304 * Merge branches `fixes` and `enhancements` on top of
305 the current branch, making an octopus merge:
306 +
307 ------------------------------------------------
308 $ git merge fixes enhancements
309 ------------------------------------------------
311 * Merge branch `obsolete` into the current branch, using `ours`
312 merge strategy:
313 +
314 ------------------------------------------------
315 $ git merge -s ours obsolete
316 ------------------------------------------------
318 * Merge branch `maint` into the current branch, but do not make
319 a new commit automatically:
320 +
321 ------------------------------------------------
322 $ git merge --no-commit maint
323 ------------------------------------------------
324 +
325 This can be used when you want to include further changes to the
326 merge, or want to write your own merge commit message.
327 +
328 You should refrain from abusing this option to sneak substantial
329 changes into a merge commit. Small fixups like bumping
330 release/version name would be acceptable.
333 include::merge-strategies.txt[]
335 CONFIGURATION
336 -------------
337 include::merge-config.txt[]
339 branch.<name>.mergeOptions::
340 Sets default options for merging into branch <name>. The syntax and
341 supported options are the same as those of 'git merge', but option
342 values containing whitespace characters are currently not supported.
344 SEE ALSO
345 --------
346 linkgit:git-fmt-merge-msg[1], linkgit:git-pull[1],
347 linkgit:gitattributes[5],
348 linkgit:git-reset[1],
349 linkgit:git-diff[1], linkgit:git-ls-files[1],
350 linkgit:git-add[1], linkgit:git-rm[1],
351 linkgit:git-mergetool[1]
353 GIT
354 ---
355 Part of the linkgit:git[1] suite