1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
\r
2 "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
\r
3 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
\r
5 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
\r
6 <meta name="generator" content="AsciiDoc 7.0.1" />
\r
7 <style type="text/css">
\r
9 p, li, dt, dd, div, pre, h1, h2, h3, h4, h5, h6 {
\r
11 border: 1px solid red;
\r
16 margin: 1em 5% 1em 5%;
\r
20 a:visited { color: fuchsia; }
\r
34 h1, h2, h3, h4, h5, h6 {
\r
36 font-family: sans-serif;
\r
38 margin-bottom: 0.5em;
\r
43 border-bottom: 2px solid silver;
\r
46 border-bottom: 2px solid silver;
\r
56 border: 1px solid silver;
\r
61 margin-bottom: 0.5em;
\r
71 font-family: sans-serif;
\r
78 font-family: sans-serif;
\r
82 font-family: sans-serif;
\r
84 border-top: 2px solid silver;
\r
90 padding-bottom: 0.5em;
\r
94 padding-bottom: 0.5em;
\r
98 div.tableblock, div.imageblock, div.exampleblock, div.verseblock,
\r
99 div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock,
\r
100 div.admonitionblock {
\r
103 margin-bottom: 1.5em;
\r
105 div.admonitionblock {
\r
107 margin-bottom: 2.5em;
\r
110 div.content { /* Block element content. */
\r
114 /* Block element titles. */
\r
115 div.title, caption.title {
\r
116 font-family: sans-serif;
\r
120 margin-bottom: 0.5em;
\r
126 td div.title:first-child {
\r
129 div.content div.title:first-child {
\r
132 div.content + div.title {
\r
136 div.sidebarblock > div.content {
\r
137 background: #ffffee;
\r
138 border: 1px solid silver;
\r
142 div.listingblock > div.content {
\r
143 border: 1px solid silver;
\r
144 background: #f4f4f4;
\r
148 div.quoteblock > div.content {
\r
149 padding-left: 2.0em;
\r
151 div.quoteblock .attribution {
\r
155 div.admonitionblock .icon {
\r
156 vertical-align: top;
\r
159 text-decoration: underline;
\r
161 padding-right: 0.5em;
\r
163 div.admonitionblock td.content {
\r
164 padding-left: 0.5em;
\r
165 border-left: 2px solid silver;
\r
168 div.exampleblock > div.content {
\r
169 border-left: 2px solid silver;
\r
173 div.verseblock div.content {
\r
177 div.imageblock div.content { padding-left: 0; }
\r
178 div.imageblock img { border: 1px solid silver; }
\r
179 span.image img { border-style: none; }
\r
183 margin-bottom: 0.8em;
\r
188 font-style: italic;
\r
190 dd > *:first-child {
\r
195 list-style-position: outside;
\r
198 list-style-type: lower-alpha;
\r
201 div.tableblock > table {
\r
202 border-color: #527bbd;
\r
206 font-family: sans-serif;
\r
215 margin-bottom: 0.8em;
\r
218 vertical-align: top;
\r
219 font-style: italic;
\r
220 padding-right: 0.8em;
\r
223 vertical-align: top;
\r
227 div#footer-badges { display: none; }
\r
229 include::./stylesheets/xhtml11-manpage.css[]
\r
230 /* Workarounds for IE6's broken and incomplete CSS2. */
\r
232 div.sidebar-content {
\r
233 background: #ffffee;
\r
234 border: 1px solid silver;
\r
237 div.sidebar-title, div.image-title {
\r
238 font-family: sans-serif;
\r
241 margin-bottom: 0.5em;
\r
244 div.listingblock div.content {
\r
245 border: 1px solid silver;
\r
246 background: #f4f4f4;
\r
250 div.quoteblock-content {
\r
251 padding-left: 2.0em;
\r
254 div.exampleblock-content {
\r
255 border-left: 2px solid silver;
\r
256 padding-left: 0.5em;
\r
259 <title>git-merge(1)</title>
\r
264 git-merge(1) Manual Page
\r
267 <div class="sectionbody">
\r
269 Grand Unified Merge Driver
\r
274 <div class="sectionbody">
\r
275 <p><em>git-merge</em> [-n] [--no-commit] [-s <strategy>]… <msg> <head> <remote> <remote>…</p>
\r
277 <h2>DESCRIPTION</h2>
\r
278 <div class="sectionbody">
\r
279 <p>This is the top-level user interface to the merge machinery
\r
280 which drives multiple merge strategy scripts.</p>
\r
283 <div class="sectionbody">
\r
290 Do not show diffstat at the end of the merge.
\r
298 Perform the merge but pretend the merge failed and do
\r
299 not autocommit, to give the user a chance to inspect and
\r
300 further tweak the merge result before committing.
\r
304 -s <strategy>, --strategy=<strategy>
\r
308 Use the given merge strategy; can be supplied more than
\r
309 once to specify them in the order they should be tried.
\r
310 If there is no <tt>-s</tt> option, a built-in list of strategies
\r
311 is used instead (<tt>git-merge-recursive</tt> when merging a single
\r
312 head, <tt>git-merge-octopus</tt> otherwise).
\r
320 The commit message to be used for the merge commit (in case
\r
321 it is created). The <tt>git-fmt-merge-msg</tt> script can be used
\r
322 to give a good default for automated <tt>git-merge</tt> invocations.
\r
330 our branch head commit.
\r
338 other branch head merged into our branch. You need at
\r
339 least one <remote>. Specifying more than one <remote>
\r
340 obviously means you are trying an Octopus.
\r
345 <h2>MERGE STRATEGIES</h2>
\r
346 <div class="sectionbody">
\r
353 This can only resolve two heads (i.e. the current branch
\r
354 and another branch you pulled from) using 3-way merge
\r
355 algorithm. It tries to carefully detect criss-cross
\r
356 merge ambiguities and is considered generally safe and
\r
365 This can only resolve two heads using 3-way merge
\r
366 algorithm. When there are more than one common
\r
367 ancestors that can be used for 3-way merge, it creates a
\r
368 merged tree of the common ancestors and uses that as
\r
369 the reference tree for the 3-way merge. This has been
\r
370 reported to result in fewer merge conflicts without
\r
371 causing mis-merges by tests done on actual merge commits
\r
372 taken from Linux 2.6 kernel development history.
\r
373 Additionally this can detect and handle merges involving
\r
374 renames. This is the default merge strategy when
\r
375 pulling or merging one branch.
\r
383 This resolves more than two-head case, but refuses to do
\r
384 complex merge that needs manual resolution. It is
\r
385 primarily meant to be used for bundling topic branch
\r
386 heads together. This is the default merge strategy when
\r
387 pulling or merging more than one branches.
\r
395 This resolves any number of heads, but the result of the
\r
396 merge is always the current branch head. It is meant to
\r
397 be used to supersede old development history of side
\r
402 <p>If you tried a merge which resulted in a complex conflicts and
\r
403 would want to start over, you can recover with
\r
404 <a href="git-reset.html">git-reset(1)</a>.</p>
\r
406 <h2>HOW MERGE WORKS</h2>
\r
407 <div class="sectionbody">
\r
408 <p>A merge is always between the current <tt>HEAD</tt> and one or more
\r
409 remote branch heads, and the index file must exactly match the
\r
410 tree of <tt>HEAD</tt> commit (i.e. the contents of the last commit) when
\r
411 it happens. In other words, <tt>git-diff --cached HEAD</tt> must
\r
412 report no changes.</p>
\r
413 <div class="admonitionblock">
\r
416 <div class="title">Note</div>
\r
418 <td class="content">This is a bit of lie. In certain special cases, your index are
\r
419 allowed to be different from the tree of <tt>HEAD</tt> commit. The most
\r
420 notable case is when your <tt>HEAD</tt> commit is already ahead of what
\r
421 is being merged, in which case your index can have arbitrary
\r
422 difference from your <tt>HEAD</tt> commit. Otherwise, your index entries
\r
423 are allowed have differences from your <tt>HEAD</tt> commit that match
\r
424 the result of trivial merge (e.g. you received the same patch
\r
425 from external source to produce the same result as what you are
\r
426 merging). For example, if a path did not exist in the common
\r
427 ancestor and your head commit but exists in the tree you are
\r
428 merging into your repository, and if you already happen to have
\r
429 that path exactly in your index, the merge does not have to
\r
433 <p>Otherwise, merge will refuse to do any harm to your repository
\r
434 (that is, it may fetch the objects from remote, and it may even
\r
435 update the local branch used to keep track of the remote branch
\r
436 with <tt>git pull remote rbranch:lbranch</tt>, but your working tree,
\r
437 <tt>.git/HEAD</tt> pointer and index file are left intact).</p>
\r
438 <p>You may have local modifications in the working tree files. In
\r
439 other words, <tt>git-diff</tt> is allowed to report changes.
\r
440 However, the merge uses your working tree as the working area,
\r
441 and in order to prevent the merge operation from losing such
\r
442 changes, it makes sure that they do not interfere with the
\r
443 merge. Those complex tables in read-tree documentation define
\r
444 what it means for a path to "interfere with the merge". And if
\r
445 your local modifications interfere with the merge, again, it
\r
446 stops before touching anything.</p>
\r
447 <p>So in the above two "failed merge" case, you do not have to
\r
448 worry about lossage of data --- you simply were not ready to do
\r
449 a merge, so no merge happened at all. You may want to finish
\r
450 whatever you were in the middle of doing, and retry the same
\r
451 pull after you are done and ready.</p>
\r
452 <p>When things cleanly merge, these things happen:</p>
\r
456 the results are updated both in the index file and in your
\r
462 index file is written out as a tree,
\r
467 the tree gets committed, and
\r
472 the <tt>HEAD</tt> pointer gets advanced.
\r
476 <p>Because of 2., we require that the original state of the index
\r
477 file to match exactly the current <tt>HEAD</tt> commit; otherwise we
\r
478 will write out your local changes already registered in your
\r
479 index file along with the merge result, which is not good.
\r
480 Because 1. involves only the paths different between your
\r
481 branch and the remote branch you are pulling from during the
\r
482 merge (which is typically a fraction of the whole tree), you can
\r
483 have local modifications in your working tree as long as they do
\r
484 not overlap with what the merge updates.</p>
\r
485 <p>When there are conflicts, these things happen:</p>
\r
489 <tt>HEAD</tt> stays the same.
\r
494 Cleanly merged paths are updated both in the index file and
\r
495 in your working tree.
\r
500 For conflicting paths, the index file records up to three
\r
501 versions; stage1 stores the version from the common ancestor,
\r
502 stage2 from <tt>HEAD</tt>, and stage3 from the remote branch (you
\r
503 can inspect the stages with <tt>git-ls-files -u</tt>). The working
\r
504 tree files have the result of "merge" program; i.e. 3-way
\r
505 merge result with familiar conflict markers <tt><<< === >>></tt>.
\r
510 No other changes are done. In particular, the local
\r
511 modifications you had before you started merge will stay the
\r
512 same and the index entries for them stay as they were,
\r
513 i.e. matching <tt>HEAD</tt>.
\r
517 <p>After seeing a conflict, you can do two things:</p>
\r
521 Decide not to merge. The only clean-up you need are to reset
\r
522 the index file to the <tt>HEAD</tt> commit to reverse 2. and to clean
\r
523 up working tree changes made by 2. and 3.; <tt>git-reset</tt> can
\r
529 Resolve the conflicts. <tt>git-diff</tt> would report only the
\r
530 conflicting paths because of the above 2. and 3.. Edit the
\r
531 working tree files into a desirable shape, <tt>git-update-index</tt>
\r
532 them, to make the index file contain what the merge result
\r
533 should be, and run <tt>git-commit</tt> to commit the result.
\r
539 <div class="sectionbody">
\r
540 <p><a href="git-fmt-merge-msg.html">git-fmt-merge-msg(1)</a>, <a href="git-pull.html">git-pull(1)</a></p>
\r
543 <div class="sectionbody">
\r
544 <p>Written by Junio C Hamano <junkio@cox.net></p>
\r
546 <h2>Documentation</h2>
\r
547 <div class="sectionbody">
\r
548 <p>Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.</p>
\r
551 <div class="sectionbody">
\r
552 <p>Part of the <a href="git.html">git(7)</a> suite</p>
\r
555 <div id="footer-text">
\r
556 Last updated 27-Dec-2005 00:16:22 PDT
\r