git-merge.html - external/gitster/git-htmldocs - Git at Google

 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
  "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
 <meta name="generator" content="AsciiDoc 8.2.5" />
 <style type="text/css">
 /* Debug borders */
 p, li, dt, dd, div, pre, h1, h2, h3, h4, h5, h6 {
 /*
  border: 1px solid red;
 */
 }

 body {
  margin: 1em 5% 1em 5%;
 }

 a {
  color: blue;
  text-decoration: underline;
 }
 a:visited {
  color: fuchsia;
 }

 em {
  font-style: italic;
 }

 strong {
  font-weight: bold;
 }

 tt {
  color: navy;
 }

 h1, h2, h3, h4, h5, h6 {
  color: #527bbd;
  font-family: sans-serif;
  margin-top: 1.2em;
  margin-bottom: 0.5em;
  line-height: 1.3;
 }

 h1, h2, h3 {
  border-bottom: 2px solid silver;
 }
 h2 {
  padding-top: 0.5em;
 }
 h3 {
  float: left;
 }
 h3 + * {
  clear: left;
 }

 div.sectionbody {
  font-family: serif;
  margin-left: 0;
 }

 hr {
  border: 1px solid silver;
 }

 p {
  margin-top: 0.5em;
  margin-bottom: 0.5em;
 }

 pre {
  padding: 0;
  margin: 0;
 }

 span#author {
  color: #527bbd;
  font-family: sans-serif;
  font-weight: bold;
  font-size: 1.1em;
 }
 span#email {
 }
 span#revision {
  font-family: sans-serif;
 }

 div#footer {
  font-family: sans-serif;
  font-size: small;
  border-top: 2px solid silver;
  padding-top: 0.5em;
  margin-top: 4.0em;
 }
 div#footer-text {
  float: left;
  padding-bottom: 0.5em;
 }
 div#footer-badges {
  float: right;
  padding-bottom: 0.5em;
 }

 div#preamble,
 div.tableblock, div.imageblock, div.exampleblock, div.verseblock,
 div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock,
 div.admonitionblock {
  margin-right: 10%;
  margin-top: 1.5em;
  margin-bottom: 1.5em;
 }
 div.admonitionblock {
  margin-top: 2.5em;
  margin-bottom: 2.5em;
 }

 div.content { /* Block element content. */
  padding: 0;
 }

 /* Block element titles. */
 div.title, caption.title {
  font-family: sans-serif;
  font-weight: bold;
  text-align: left;
  margin-top: 1.0em;
  margin-bottom: 0.5em;
 }
 div.title + * {
  margin-top: 0;
 }

 td div.title:first-child {
  margin-top: 0.0em;
 }
 div.content div.title:first-child {
  margin-top: 0.0em;
 }
 div.content + div.title {
  margin-top: 0.0em;
 }

 div.sidebarblock > div.content {
  background: #ffffee;
  border: 1px solid silver;
  padding: 0.5em;
 }

 div.listingblock {
  margin-right: 0%;
 }
 div.listingblock > div.content {
  border: 1px solid silver;
  background: #f4f4f4;
  padding: 0.5em;
 }

 div.quoteblock > div.content {
  padding-left: 2.0em;
 }

 div.attribution {
  text-align: right;
 }
 div.verseblock + div.attribution {
  text-align: left;
 }

 div.admonitionblock .icon {
  vertical-align: top;
  font-size: 1.1em;
  font-weight: bold;
  text-decoration: underline;
  color: #527bbd;
  padding-right: 0.5em;
 }
 div.admonitionblock td.content {
  padding-left: 0.5em;
  border-left: 2px solid silver;
 }

 div.exampleblock > div.content {
  border-left: 2px solid silver;
  padding: 0.5em;
 }

 div.verseblock div.content {
  white-space: pre;
 }

 div.imageblock div.content { padding-left: 0; }
 div.imageblock img { border: 1px solid silver; }
 span.image img { border-style: none; }

 dl {
  margin-top: 0.8em;
  margin-bottom: 0.8em;
 }
 dt {
  margin-top: 0.5em;
  margin-bottom: 0;
  font-style: italic;
 }
 dd > *:first-child {
  margin-top: 0;
 }

 ul, ol {
  list-style-position: outside;
 }
 div.olist2 ol {
  list-style-type: lower-alpha;
 }

 div.tableblock > table {
  border: 3px solid #527bbd;
 }
 thead {
  font-family: sans-serif;
  font-weight: bold;
 }
 tfoot {
  font-weight: bold;
 }

 div.hlist {
  margin-top: 0.8em;
  margin-bottom: 0.8em;
 }
 div.hlist td {
  padding-bottom: 5px;
 }
 td.hlist1 {
  vertical-align: top;
  font-style: italic;
  padding-right: 0.8em;
 }
 td.hlist2 {
  vertical-align: top;
 }

 @media print {
  div#footer-badges { display: none; }
 }

 div#toctitle {
  color: #527bbd;
  font-family: sans-serif;
  font-size: 1.1em;
  font-weight: bold;
  margin-top: 1.0em;
  margin-bottom: 0.1em;
 }

 div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
  margin-top: 0;
  margin-bottom: 0;
 }
 div.toclevel2 {
  margin-left: 2em;
  font-size: 0.9em;
 }
 div.toclevel3 {
  margin-left: 4em;
  font-size: 0.9em;
 }
 div.toclevel4 {
  margin-left: 6em;
  font-size: 0.9em;
 }
 include1::./stylesheets/xhtml11-manpage.css[]
 /* Workarounds for IE6's broken and incomplete CSS2. */

 div.sidebar-content {
  background: #ffffee;
  border: 1px solid silver;
  padding: 0.5em;
 }
 div.sidebar-title, div.image-title {
  font-family: sans-serif;
  font-weight: bold;
  margin-top: 0.0em;
  margin-bottom: 0.5em;
 }

 div.listingblock div.content {
  border: 1px solid silver;
  background: #f4f4f4;
  padding: 0.5em;
 }

 div.quoteblock-content {
  padding-left: 2.0em;
 }

 div.exampleblock-content {
  border-left: 2px solid silver;
  padding-left: 0.5em;
 }

 /* IE6 sets dynamically generated links as visited. */
 div#toc a:visited { color: blue; }
 </style>
 <title>git-merge(1)</title>
 </head>
 <body>
 <div id="header">
 <h1>
 git-merge(1) Manual Page
 </h1>
 <h2>NAME</h2>
 <div class="sectionbody">
 <p>git-merge -
  Join two or more development histories together
 </p>
 </div>
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
 <div class="content"><em>git merge</em> [-n] [--stat] [--no-commit] [--squash] [-s &lt;strategy&gt;]&#8230;
  [-m &lt;msg&gt;] &lt;remote&gt; &lt;remote&gt;&#8230;
 <em>git merge</em> &lt;msg&gt; HEAD &lt;remote&gt;&#8230;</div></div>
 </div>
 <h2 id="_description">DESCRIPTION</h2>
 <div class="sectionbody">
 <div class="para"><p>This is the top-level interface to the merge machinery
 which drives multiple merge strategy scripts.</p></div>
 <div class="para"><p>The second syntax (&lt;msg&gt; <tt>HEAD</tt> &lt;remote&gt;) is supported for
 historical reasons. Do not use it from the command line or in
 new scripts. It is the same as <tt>git merge -m &lt;msg&gt; &lt;remote&gt;</tt>.</p></div>
 </div>
 <h2 id="_options">OPTIONS</h2>
 <div class="sectionbody">
 <div class="vlist"><dl>
 <dt>
 --stat
 </dt>
 <dd>
 <p>
  Show a diffstat at the end of the merge. The diffstat is also
  controlled by the configuration option merge.stat.
 </p>
 </dd>
 <dt>
 -n
 </dt>
 <dt>
 --no-stat
 </dt>
 <dd>
 <p>
  Do not show diffstat at the end of the merge.
 </p>
 </dd>
 <dt>
 --summary
 </dt>
 <dt>
 --no-summary
 </dt>
 <dd>
 <p>
  Synonyms to --stat and --no-stat; these are deprecated and will be
  removed in the future.
 </p>
 </dd>
 <dt>
 --log
 </dt>
 <dd>
 <p>
  In addition to branch names, populate the log message with
  one-line descriptions from the actual commits that are being
  merged.
 </p>
 </dd>
 <dt>
 --no-log
 </dt>
 <dd>
 <p>
  Do not list one-line descriptions from the actual commits being
  merged.
 </p>
 </dd>
 <dt>
 --no-commit
 </dt>
 <dd>
 <p>
  Perform the merge but pretend the merge failed and do
  not autocommit, to give the user a chance to inspect and
  further tweak the merge result before committing.
 </p>
 </dd>
 <dt>
 --commit
 </dt>
 <dd>
 <p>
  Perform the merge and commit the result. This option can
  be used to override --no-commit.
 </p>
 </dd>
 <dt>
 --squash
 </dt>
 <dd>
 <p>
  Produce the working tree and index state as if a real
  merge happened, but do not actually make a commit or
  move the <tt>HEAD</tt>, nor record <tt>$GIT_DIR/MERGE_HEAD</tt> to
  cause the next <tt>git commit</tt> 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).
 </p>
 </dd>
 <dt>
 --no-squash
 </dt>
 <dd>
 <p>
  Perform the merge and commit the result. This option can
  be used to override --squash.
 </p>
 </dd>
 <dt>
 --no-ff
 </dt>
 <dd>
 <p>
  Generate a merge commit even if the merge resolved as a
  fast-forward.
 </p>
 </dd>
 <dt>
 --ff
 </dt>
 <dd>
 <p>
  Do not generate a merge commit if the merge resolved as
  a fast-forward, only update the branch pointer. This is
  the default behavior of git-merge.
 </p>
 </dd>
 <dt>
 -s &lt;strategy&gt;
 </dt>
 <dt>
 --strategy=&lt;strategy&gt;
 </dt>
 <dd>
 <p>
  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 <tt>-s</tt> option, a built-in list of strategies
  is used instead (<em>git-merge-recursive</em> when merging a single
  head, <em>git-merge-octopus</em> otherwise).
 </p>
 </dd>
 <dt>
 -m &lt;msg&gt;
 </dt>
 <dd>
 <p>
  The commit message to be used for the merge commit (in case
  it is created). The <em>git-fmt-merge-msg</em> script can be used
  to give a good default for automated <em>git-merge</em> invocations.
 </p>
 </dd>
 <dt>
 &lt;remote&gt;&#8230;
 </dt>
 <dd>
 <p>
  Other branch heads to merge into our branch. You need at
  least one &lt;remote&gt;. Specifying more than one &lt;remote&gt;
  obviously means you are trying an Octopus.
 </p>
 </dd>
 </dl></div>
 </div>
 <h2 id="_merge_strategies">MERGE STRATEGIES</h2>
 <div class="sectionbody">
 <div class="vlist"><dl>
 <dt>
 resolve
 </dt>
 <dd>
 <p>
  This can only resolve two heads (i.e. the current branch
  and another branch you pulled from) using 3-way merge
  algorithm. It tries to carefully detect criss-cross
  merge ambiguities and is considered generally safe and
  fast.
 </p>
 </dd>
 <dt>
 recursive
 </dt>
 <dd>
 <p>
  This can only resolve two heads using 3-way merge
  algorithm. When there are more than one common
  ancestors that can be used for 3-way merge, it creates a
  merged tree of the common ancestors and uses that as
  the reference tree for the 3-way merge. This has been
  reported to result in fewer merge conflicts without
  causing mis-merges by tests done on actual merge commits
  taken from Linux 2.6 kernel development history.
  Additionally this can detect and handle merges involving
  renames. This is the default merge strategy when
  pulling or merging one branch.
 </p>
 </dd>
 <dt>
 octopus
 </dt>
 <dd>
 <p>
  This resolves more than two-head case, but refuses to do
  complex merge that needs manual resolution. It is
  primarily meant to be used for bundling topic branch
  heads together. This is the default merge strategy when
  pulling or merging more than one branches.
 </p>
 </dd>
 <dt>
 ours
 </dt>
 <dd>
 <p>
  This resolves any number of heads, but the result of the
  merge is always the current branch head. It is meant to
  be used to supersede old development history of side
  branches.
 </p>
 </dd>
 <dt>
 subtree
 </dt>
 <dd>
 <p>
  This is a modified recursive strategy. When merging trees A and
  B, if B corresponds to a subtree of A, B is first adjusted to
  match the tree structure of A, instead of reading the trees at
  the same level. This adjustment is also done to the common
  ancestor tree.
 </p>
 </dd>
 </dl></div>
 <div class="para"><p>If you tried a merge which resulted in a complex conflicts and
 would want to start over, you can recover with <em>git-reset</em>.</p></div>
 </div>
 <h2 id="_configuration">CONFIGURATION</h2>
 <div class="sectionbody">
 <div class="vlist"><dl>
 <dt>
 merge.stat
 </dt>
 <dd>
 <p>
  Whether to print the diffstat between ORIG_HEAD and merge result
  at the end of the merge. True by default.
 </p>
 </dd>
 <dt>
 merge.log
 </dt>
 <dd>
 <p>
  Whether to include summaries of merged commits in newly created
  merge commit messages. False by default.
 </p>
 </dd>
 <dt>
 merge.renameLimit
 </dt>
 <dd>
 <p>
  The number of files to consider when performing rename detection
  during a merge; if not specified, defaults to the value of
  diff.renameLimit.
 </p>
 </dd>
 <dt>
 merge.tool
 </dt>
 <dd>
 <p>
  Controls which merge resolution program is used by
  <a href="git-mergetool.html">git-mergetool(1)</a>. Valid built-in values are: "kdiff3",
  "tkdiff", "meld", "xxdiff", "emerge", "vimdiff", "gvimdiff", and
  "opendiff". Any other value is treated is custom merge tool
  and there must be a corresponding mergetool.&lt;tool&gt;.cmd option.
 </p>
 </dd>
 <dt>
 merge.verbosity
 </dt>
 <dd>
 <p>
  Controls the amount of output shown by the recursive merge
  strategy. Level 0 outputs nothing except a final error
  message if conflicts were detected. Level 1 outputs only
  conflicts, 2 outputs conflicts and file changes. Level 5 and
  above outputs debugging information. The default is level 2.
  Can be overridden by <em>GIT_MERGE_VERBOSITY</em> environment variable.
 </p>
 </dd>
 <dt>
 merge.&lt;driver&gt;.name
 </dt>
 <dd>
 <p>
  Defines a human readable name for a custom low-level
  merge driver. See <a href="gitattributes.html">gitattributes(5)</a> for details.
 </p>
 </dd>
 <dt>
 merge.&lt;driver&gt;.driver
 </dt>
 <dd>
 <p>
  Defines the command that implements a custom low-level
  merge driver. See <a href="gitattributes.html">gitattributes(5)</a> for details.
 </p>
 </dd>
 <dt>
 merge.&lt;driver&gt;.recursive
 </dt>
 <dd>
 <p>
  Names a low-level merge driver to be used when
  performing an internal merge between common ancestors.
  See <a href="gitattributes.html">gitattributes(5)</a> for details.
 </p>
 </dd>
 <dt>
 branch.&lt;name&gt;.mergeoptions
 </dt>
 <dd>
 <p>
  Sets default options for merging into branch &lt;name&gt;. The syntax and
  supported options are equal to that of <em>git-merge</em>, but option values
  containing whitespace characters are currently not supported.
 </p>
 </dd>
 </dl></div>
 </div>
 <h2 id="_how_merge_works">HOW MERGE WORKS</h2>
 <div class="sectionbody">
 <div class="para"><p>A merge is always between the current <tt>HEAD</tt> and one or more
 commits (usually, branch head or tag), and the index file must
 match the tree of <tt>HEAD</tt> commit (i.e. the contents of the last commit)
 when it starts out. In other words, <tt>git diff --cached HEAD</tt> must
 report no changes. (One exception is when the changed index
 entries are already in the same state that would result from
 the merge anyway.)</p></div>
 <div class="para"><p>Three kinds of merge can happen:</p></div>
 <div class="ilist"><ul>
 <li>
 <p>
 The merged commit is already contained in <tt>HEAD</tt>. This is the
  simplest case, called "Already up-to-date."
 </p>
 </li>
 <li>
 <p>
 <tt>HEAD</tt> is already contained in the merged commit. This is the
  most common case especially when involved through <em>git pull</em>:
  you are tracking an upstream repository, committed no local
  changes and now you want to update to a newer upstream revision.
  Your <tt>HEAD</tt> (and the index) is updated to at point the merged
  commit, without creating an extra merge commit. This is
  called "Fast-forward".
 </p>
 </li>
 <li>
 <p>
 Both the merged commit and <tt>HEAD</tt> are independent and must be
  tied together by a merge commit that has them both as its parents.
  The rest of this section describes this "True merge" case.
 </p>
 </li>
 </ul></div>
 <div class="para"><p>The chosen merge strategy merges the two commits into a single
 new source tree.
 When things cleanly merge, these things happen:</p></div>
 <div class="olist"><ol>
 <li>
 <p>
 The results are updated both in the index file and in your
  working tree;
 </p>
 </li>
 <li>
 <p>
 Index file is written out as a tree;
 </p>
 </li>
 <li>
 <p>
 The tree gets committed; and
 </p>
 </li>
 <li>
 <p>
 The <tt>HEAD</tt> pointer gets advanced.
 </p>
 </li>
 </ol></div>
 <div class="para"><p>Because of 2., we require that the original state of the index
 file to match exactly the current <tt>HEAD</tt> commit; otherwise we
 will write out your local changes already registered in your
 index file along with the merge result, which is not good.
 Because 1. involves only the paths different between your
 branch and the remote branch you are pulling from during the
 merge (which is typically a fraction of the whole tree), you can
 have local modifications in your working tree as long as they do
 not overlap with what the merge updates.</p></div>
 <div class="para"><p>When there are conflicts, these things happen:</p></div>
 <div class="olist"><ol>
 <li>
 <p>
 <tt>HEAD</tt> stays the same.
 </p>
 </li>
 <li>
 <p>
 Cleanly merged paths are updated both in the index file and
  in your working tree.
 </p>
 </li>
 <li>
 <p>
 For conflicting paths, the index file records up to three
  versions; stage1 stores the version from the common ancestor,
  stage2 from <tt>HEAD</tt>, and stage3 from the remote branch (you
  can inspect the stages with <tt>git ls-files -u</tt>). The working
  tree files have the result of "merge" program; i.e. 3-way
  merge result with familiar conflict markers <tt>&lt;&lt;&lt; === &gt;&gt;&gt;</tt>.
 </p>
 </li>
 <li>
 <p>
 No other changes are done. In particular, the local
  modifications you had before you started merge will stay the
  same and the index entries for them stay as they were,
  i.e. matching <tt>HEAD</tt>.
 </p>
 </li>
 </ol></div>
 <div class="para"><p>After seeing a conflict, you can do two things:</p></div>
 <div class="ilist"><ul>
 <li>
 <p>
 Decide not to merge. The only clean-up you need are to reset
  the index file to the <tt>HEAD</tt> commit to reverse 2. and to clean
  up working tree changes made by 2. and 3.; <em>git-reset --hard</em> can
  be used for this.
 </p>
 </li>
 <li>
 <p>
 Resolve the conflicts. <tt>git diff</tt> would report only the
  conflicting paths because of the above 2. and 3.
  Edit the working tree files into a desirable shape
  (<em>git mergetool</em> can ease this task), <em>git-add</em> or <em>git-rm</em>
  them, to make the index file contain what the merge result
  should be, and run <em>git-commit</em> to commit the result.
 </p>
 </li>
 </ul></div>
 </div>
 <h2 id="_see_also">SEE ALSO</h2>
 <div class="sectionbody">
 <div class="para"><p><a href="git-fmt-merge-msg.html">git-fmt-merge-msg(1)</a>, <a href="git-pull.html">git-pull(1)</a>,
 <a href="gitattributes.html">gitattributes(5)</a>,
 <a href="git-reset.html">git-reset(1)</a>,
 <a href="git-diff.html">git-diff(1)</a>, <a href="git-ls-files.html">git-ls-files(1)</a>,
 <a href="git-add.html">git-add(1)</a>, <a href="git-rm.html">git-rm(1)</a>,
 <a href="git-mergetool.html">git-mergetool(1)</a></p></div>
 </div>
 <h2 id="_author">Author</h2>
 <div class="sectionbody">
 <div class="para"><p>Written by Junio C Hamano &lt;gitster@pobox.com&gt;</p></div>
 </div>
 <h2 id="_documentation">Documentation</h2>
 <div class="sectionbody">
 <div class="para"><p>Documentation by Junio C Hamano and the git-list &lt;git@vger.kernel.org&gt;.</p></div>
 </div>
 <h2 id="_git">GIT</h2>
 <div class="sectionbody">
 <div class="para"><p>Part of the <a href="git.html">git(1)</a> suite</p></div>
 </div>
 <div id="footer">
 <div id="footer-text">
 Last updated 2008-08-06 06:19:09 UTC
 </div>
 </div>
 </body>
 </html>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
	"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
	<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
	<meta name="generator" content="AsciiDoc 8.2.5" />
	<style type="text/css">
	/* Debug borders */
	p, li, dt, dd, div, pre, h1, h2, h3, h4, h5, h6 {
	/*
	border: 1px solid red;
	*/
	}

	body {
	margin: 1em 5% 1em 5%;
	}

	a {
	color: blue;
	text-decoration: underline;
	}
	a:visited {
	color: fuchsia;
	}

	em {
	font-style: italic;
	}

	strong {
	font-weight: bold;
	}

	tt {
	color: navy;
	}

	h1, h2, h3, h4, h5, h6 {
	color: #527bbd;
	font-family: sans-serif;
	margin-top: 1.2em;
	margin-bottom: 0.5em;
	line-height: 1.3;
	}

	h1, h2, h3 {
	border-bottom: 2px solid silver;
	}
	h2 {
	padding-top: 0.5em;
	}
	h3 {
	float: left;
	}
	h3 + * {
	clear: left;
	}

	div.sectionbody {
	font-family: serif;
	margin-left: 0;
	}

	hr {
	border: 1px solid silver;
	}

	p {
	margin-top: 0.5em;
	margin-bottom: 0.5em;
	}

	pre {
	padding: 0;
	margin: 0;
	}

	span#author {
	color: #527bbd;
	font-family: sans-serif;
	font-weight: bold;
	font-size: 1.1em;
	}
	span#email {
	}
	span#revision {
	font-family: sans-serif;
	}

	div#footer {
	font-family: sans-serif;
	font-size: small;
	border-top: 2px solid silver;
	padding-top: 0.5em;
	margin-top: 4.0em;
	}
	div#footer-text {
	float: left;
	padding-bottom: 0.5em;
	}
	div#footer-badges {
	float: right;
	padding-bottom: 0.5em;
	}

	div#preamble,
	div.tableblock, div.imageblock, div.exampleblock, div.verseblock,
	div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock,
	div.admonitionblock {
	margin-right: 10%;
	margin-top: 1.5em;
	margin-bottom: 1.5em;
	}
	div.admonitionblock {
	margin-top: 2.5em;
	margin-bottom: 2.5em;
	}

	div.content { /* Block element content. */
	padding: 0;
	}

	/* Block element titles. */
	div.title, caption.title {
	font-family: sans-serif;
	font-weight: bold;
	text-align: left;
	margin-top: 1.0em;
	margin-bottom: 0.5em;
	}
	div.title + * {
	margin-top: 0;
	}

	td div.title:first-child {
	margin-top: 0.0em;
	}
	div.content div.title:first-child {
	margin-top: 0.0em;
	}
	div.content + div.title {
	margin-top: 0.0em;
	}

	div.sidebarblock > div.content {
	background: #ffffee;
	border: 1px solid silver;
	padding: 0.5em;
	}

	div.listingblock {
	margin-right: 0%;
	}
	div.listingblock > div.content {
	border: 1px solid silver;
	background: #f4f4f4;
	padding: 0.5em;
	}

	div.quoteblock > div.content {
	padding-left: 2.0em;
	}

	div.attribution {
	text-align: right;
	}
	div.verseblock + div.attribution {
	text-align: left;
	}

	div.admonitionblock .icon {
	vertical-align: top;
	font-size: 1.1em;
	font-weight: bold;
	text-decoration: underline;
	color: #527bbd;
	padding-right: 0.5em;
	}
	div.admonitionblock td.content {
	padding-left: 0.5em;
	border-left: 2px solid silver;
	}

	div.exampleblock > div.content {
	border-left: 2px solid silver;
	padding: 0.5em;
	}

	div.verseblock div.content {
	white-space: pre;
	}

	div.imageblock div.content { padding-left: 0; }
	div.imageblock img { border: 1px solid silver; }
	span.image img { border-style: none; }

	dl {
	margin-top: 0.8em;
	margin-bottom: 0.8em;
	}
	dt {
	margin-top: 0.5em;
	margin-bottom: 0;
	font-style: italic;
	}
	dd > *:first-child {
	margin-top: 0;
	}

	ul, ol {
	list-style-position: outside;
	}
	div.olist2 ol {
	list-style-type: lower-alpha;
	}

	div.tableblock > table {
	border: 3px solid #527bbd;
	}
	thead {
	font-family: sans-serif;
	font-weight: bold;
	}
	tfoot {
	font-weight: bold;
	}

	div.hlist {
	margin-top: 0.8em;
	margin-bottom: 0.8em;
	}
	div.hlist td {
	padding-bottom: 5px;
	}
	td.hlist1 {
	vertical-align: top;
	font-style: italic;
	padding-right: 0.8em;
	}
	td.hlist2 {
	vertical-align: top;
	}

	@media print {
	div#footer-badges { display: none; }
	}

	div#toctitle {
	color: #527bbd;
	font-family: sans-serif;
	font-size: 1.1em;
	font-weight: bold;
	margin-top: 1.0em;
	margin-bottom: 0.1em;
	}

	div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
	margin-top: 0;
	margin-bottom: 0;
	}
	div.toclevel2 {
	margin-left: 2em;
	font-size: 0.9em;
	}
	div.toclevel3 {
	margin-left: 4em;
	font-size: 0.9em;
	}
	div.toclevel4 {
	margin-left: 6em;
	font-size: 0.9em;
	}
	include1::./stylesheets/xhtml11-manpage.css[]
	/* Workarounds for IE6's broken and incomplete CSS2. */

	div.sidebar-content {
	background: #ffffee;
	border: 1px solid silver;
	padding: 0.5em;
	}
	div.sidebar-title, div.image-title {
	font-family: sans-serif;
	font-weight: bold;
	margin-top: 0.0em;
	margin-bottom: 0.5em;
	}

	div.listingblock div.content {
	border: 1px solid silver;
	background: #f4f4f4;
	padding: 0.5em;
	}

	div.quoteblock-content {
	padding-left: 2.0em;
	}

	div.exampleblock-content {
	border-left: 2px solid silver;
	padding-left: 0.5em;
	}

	/* IE6 sets dynamically generated links as visited. */
	div#toc a:visited { color: blue; }
	</style>
	<title>git-merge(1)</title>
	</head>
	<body>
	<div id="header">
	<h1>
	git-merge(1) Manual Page
	</h1>
	<h2>NAME</h2>
	<div class="sectionbody">
	<p>git-merge -
	Join two or more development histories together
	</p>
	</div>
	</div>
	<h2>SYNOPSIS</h2>
	<div class="sectionbody">
	<div class="verseblock">
	<div class="content"><em>git merge</em> [-n] [--stat] [--no-commit] [--squash] [-s <strategy>]…
	[-m <msg>] <remote> <remote>…
	<em>git merge</em> <msg> HEAD <remote>…</div></div>
	</div>
	<h2 id="_description">DESCRIPTION</h2>
	<div class="sectionbody">
	<div class="para"><p>This is the top-level interface to the merge machinery
	which drives multiple merge strategy scripts.</p></div>
	<div class="para"><p>The second syntax (<msg> <tt>HEAD</tt> <remote>) is supported for
	historical reasons. Do not use it from the command line or in
	new scripts. It is the same as <tt>git merge -m <msg> <remote></tt>.</p></div>
	</div>
	<h2 id="_options">OPTIONS</h2>
	<div class="sectionbody">
	<div class="vlist"><dl>
	<dt>
	--stat
	</dt>
	<dd>
	<p>
	Show a diffstat at the end of the merge. The diffstat is also
	controlled by the configuration option merge.stat.
	</p>
	</dd>
	<dt>
	-n
	</dt>
	<dt>
	--no-stat
	</dt>
	<dd>
	<p>
	Do not show diffstat at the end of the merge.
	</p>
	</dd>
	<dt>
	--summary
	</dt>
	<dt>
	--no-summary
	</dt>
	<dd>
	<p>
	Synonyms to --stat and --no-stat; these are deprecated and will be
	removed in the future.
	</p>
	</dd>
	<dt>
	--log
	</dt>
	<dd>
	<p>
	In addition to branch names, populate the log message with
	one-line descriptions from the actual commits that are being
	merged.
	</p>
	</dd>
	<dt>
	--no-log
	</dt>
	<dd>
	<p>
	Do not list one-line descriptions from the actual commits being
	merged.
	</p>
	</dd>
	<dt>
	--no-commit
	</dt>
	<dd>
	<p>
	Perform the merge but pretend the merge failed and do
	not autocommit, to give the user a chance to inspect and
	further tweak the merge result before committing.
	</p>
	</dd>
	<dt>
	--commit
	</dt>
	<dd>
	<p>
	Perform the merge and commit the result. This option can
	be used to override --no-commit.
	</p>
	</dd>
	<dt>
	--squash
	</dt>
	<dd>
	<p>
	Produce the working tree and index state as if a real
	merge happened, but do not actually make a commit or
	move the <tt>HEAD</tt>, nor record <tt>$GIT_DIR/MERGE_HEAD</tt> to
	cause the next <tt>git commit</tt> 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).
	</p>
	</dd>
	<dt>
	--no-squash
	</dt>
	<dd>
	<p>
	Perform the merge and commit the result. This option can
	be used to override --squash.
	</p>
	</dd>
	<dt>
	--no-ff
	</dt>
	<dd>
	<p>
	Generate a merge commit even if the merge resolved as a
	fast-forward.
	</p>
	</dd>
	<dt>
	--ff
	</dt>
	<dd>
	<p>
	Do not generate a merge commit if the merge resolved as
	a fast-forward, only update the branch pointer. This is
	the default behavior of git-merge.
	</p>
	</dd>
	<dt>
	-s <strategy>
	</dt>
	<dt>
	--strategy=<strategy>
	</dt>
	<dd>
	<p>
	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 <tt>-s</tt> option, a built-in list of strategies
	is used instead (<em>git-merge-recursive</em> when merging a single
	head, <em>git-merge-octopus</em> otherwise).
	</p>
	</dd>
	<dt>
	-m <msg>
	</dt>
	<dd>
	<p>
	The commit message to be used for the merge commit (in case
	it is created). The <em>git-fmt-merge-msg</em> script can be used
	to give a good default for automated <em>git-merge</em> invocations.
	</p>
	</dd>
	<dt>
	<remote>…
	</dt>
	<dd>
	<p>
	Other branch heads to merge into our branch. You need at
	least one <remote>. Specifying more than one <remote>
	obviously means you are trying an Octopus.
	</p>
	</dd>
	</dl></div>
	</div>
	<h2 id="_merge_strategies">MERGE STRATEGIES</h2>
	<div class="sectionbody">
	<div class="vlist"><dl>
	<dt>
	resolve
	</dt>
	<dd>
	<p>
	This can only resolve two heads (i.e. the current branch
	and another branch you pulled from) using 3-way merge
	algorithm. It tries to carefully detect criss-cross
	merge ambiguities and is considered generally safe and
	fast.
	</p>
	</dd>
	<dt>
	recursive
	</dt>
	<dd>
	<p>
	This can only resolve two heads using 3-way merge
	algorithm. When there are more than one common
	ancestors that can be used for 3-way merge, it creates a
	merged tree of the common ancestors and uses that as
	the reference tree for the 3-way merge. This has been
	reported to result in fewer merge conflicts without
	causing mis-merges by tests done on actual merge commits
	taken from Linux 2.6 kernel development history.
	Additionally this can detect and handle merges involving
	renames. This is the default merge strategy when
	pulling or merging one branch.
	</p>
	</dd>
	<dt>
	octopus
	</dt>
	<dd>
	<p>
	This resolves more than two-head case, but refuses to do
	complex merge that needs manual resolution. It is
	primarily meant to be used for bundling topic branch
	heads together. This is the default merge strategy when
	pulling or merging more than one branches.
	</p>
	</dd>
	<dt>
	ours
	</dt>
	<dd>
	<p>
	This resolves any number of heads, but the result of the
	merge is always the current branch head. It is meant to
	be used to supersede old development history of side
	branches.
	</p>
	</dd>
	<dt>
	subtree
	</dt>
	<dd>
	<p>
	This is a modified recursive strategy. When merging trees A and
	B, if B corresponds to a subtree of A, B is first adjusted to
	match the tree structure of A, instead of reading the trees at
	the same level. This adjustment is also done to the common
	ancestor tree.
	</p>
	</dd>
	</dl></div>
	<div class="para"><p>If you tried a merge which resulted in a complex conflicts and
	would want to start over, you can recover with <em>git-reset</em>.</p></div>
	</div>
	<h2 id="_configuration">CONFIGURATION</h2>
	<div class="sectionbody">
	<div class="vlist"><dl>
	<dt>
	merge.stat
	</dt>
	<dd>
	<p>
	Whether to print the diffstat between ORIG_HEAD and merge result
	at the end of the merge. True by default.
	</p>
	</dd>
	<dt>
	merge.log
	</dt>
	<dd>
	<p>
	Whether to include summaries of merged commits in newly created
	merge commit messages. False by default.
	</p>
	</dd>
	<dt>
	merge.renameLimit
	</dt>
	<dd>
	<p>
	The number of files to consider when performing rename detection
	during a merge; if not specified, defaults to the value of
	diff.renameLimit.
	</p>
	</dd>
	<dt>
	merge.tool
	</dt>
	<dd>
	<p>
	Controls which merge resolution program is used by
	<a href="git-mergetool.html">git-mergetool(1)</a>. Valid built-in values are: "kdiff3",
	"tkdiff", "meld", "xxdiff", "emerge", "vimdiff", "gvimdiff", and
	"opendiff". Any other value is treated is custom merge tool
	and there must be a corresponding mergetool.<tool>.cmd option.
	</p>
	</dd>
	<dt>
	merge.verbosity
	</dt>
	<dd>
	<p>
	Controls the amount of output shown by the recursive merge
	strategy. Level 0 outputs nothing except a final error
	message if conflicts were detected. Level 1 outputs only
	conflicts, 2 outputs conflicts and file changes. Level 5 and
	above outputs debugging information. The default is level 2.
	Can be overridden by <em>GIT_MERGE_VERBOSITY</em> environment variable.
	</p>
	</dd>
	<dt>
	merge.<driver>.name
	</dt>
	<dd>
	<p>
	Defines a human readable name for a custom low-level
	merge driver. See <a href="gitattributes.html">gitattributes(5)</a> for details.
	</p>
	</dd>
	<dt>
	merge.<driver>.driver
	</dt>
	<dd>
	<p>
	Defines the command that implements a custom low-level
	merge driver. See <a href="gitattributes.html">gitattributes(5)</a> for details.
	</p>
	</dd>
	<dt>
	merge.<driver>.recursive
	</dt>
	<dd>
	<p>
	Names a low-level merge driver to be used when
	performing an internal merge between common ancestors.
	See <a href="gitattributes.html">gitattributes(5)</a> for details.
	</p>
	</dd>
	<dt>
	branch.<name>.mergeoptions
	</dt>
	<dd>
	<p>
	Sets default options for merging into branch <name>. The syntax and
	supported options are equal to that of <em>git-merge</em>, but option values
	containing whitespace characters are currently not supported.
	</p>
	</dd>
	</dl></div>
	</div>
	<h2 id="_how_merge_works">HOW MERGE WORKS</h2>
	<div class="sectionbody">
	<div class="para"><p>A merge is always between the current <tt>HEAD</tt> and one or more
	commits (usually, branch head or tag), and the index file must
	match the tree of <tt>HEAD</tt> commit (i.e. the contents of the last commit)
	when it starts out. In other words, <tt>git diff --cached HEAD</tt> must
	report no changes. (One exception is when the changed index
	entries are already in the same state that would result from
	the merge anyway.)</p></div>
	<div class="para"><p>Three kinds of merge can happen:</p></div>
	<div class="ilist"><ul>
	<li>
	<p>
	The merged commit is already contained in <tt>HEAD</tt>. This is the
	simplest case, called "Already up-to-date."
	</p>
	</li>
	<li>
	<p>
	<tt>HEAD</tt> is already contained in the merged commit. This is the
	most common case especially when involved through <em>git pull</em>:
	you are tracking an upstream repository, committed no local
	changes and now you want to update to a newer upstream revision.
	Your <tt>HEAD</tt> (and the index) is updated to at point the merged
	commit, without creating an extra merge commit. This is
	called "Fast-forward".
	</p>
	</li>
	<li>
	<p>
	Both the merged commit and <tt>HEAD</tt> are independent and must be
	tied together by a merge commit that has them both as its parents.
	The rest of this section describes this "True merge" case.
	</p>
	</li>
	</ul></div>
	<div class="para"><p>The chosen merge strategy merges the two commits into a single
	new source tree.
	When things cleanly merge, these things happen:</p></div>
	<div class="olist"><ol>
	<li>
	<p>
	The results are updated both in the index file and in your
	working tree;
	</p>
	</li>
	<li>
	<p>
	Index file is written out as a tree;
	</p>
	</li>
	<li>
	<p>
	The tree gets committed; and
	</p>
	</li>
	<li>
	<p>
	The <tt>HEAD</tt> pointer gets advanced.
	</p>
	</li>
	</ol></div>
	<div class="para"><p>Because of 2., we require that the original state of the index
	file to match exactly the current <tt>HEAD</tt> commit; otherwise we
	will write out your local changes already registered in your
	index file along with the merge result, which is not good.
	Because 1. involves only the paths different between your
	branch and the remote branch you are pulling from during the
	merge (which is typically a fraction of the whole tree), you can
	have local modifications in your working tree as long as they do
	not overlap with what the merge updates.</p></div>
	<div class="para"><p>When there are conflicts, these things happen:</p></div>
	<div class="olist"><ol>
	<li>
	<p>
	<tt>HEAD</tt> stays the same.
	</p>
	</li>
	<li>
	<p>
	Cleanly merged paths are updated both in the index file and
	in your working tree.
	</p>
	</li>
	<li>
	<p>
	For conflicting paths, the index file records up to three
	versions; stage1 stores the version from the common ancestor,
	stage2 from <tt>HEAD</tt>, and stage3 from the remote branch (you
	can inspect the stages with <tt>git ls-files -u</tt>). The working
	tree files have the result of "merge" program; i.e. 3-way
	merge result with familiar conflict markers <tt><<< === >>></tt>.
	</p>
	</li>
	<li>
	<p>
	No other changes are done. In particular, the local
	modifications you had before you started merge will stay the
	same and the index entries for them stay as they were,
	i.e. matching <tt>HEAD</tt>.
	</p>
	</li>
	</ol></div>
	<div class="para"><p>After seeing a conflict, you can do two things:</p></div>
	<div class="ilist"><ul>
	<li>
	<p>
	Decide not to merge. The only clean-up you need are to reset
	the index file to the <tt>HEAD</tt> commit to reverse 2. and to clean
	up working tree changes made by 2. and 3.; <em>git-reset --hard</em> can
	be used for this.
	</p>
	</li>
	<li>
	<p>
	Resolve the conflicts. <tt>git diff</tt> would report only the
	conflicting paths because of the above 2. and 3.
	Edit the working tree files into a desirable shape
	(<em>git mergetool</em> can ease this task), <em>git-add</em> or <em>git-rm</em>
	them, to make the index file contain what the merge result
	should be, and run <em>git-commit</em> to commit the result.
	</p>
	</li>
	</ul></div>
	</div>
	<h2 id="_see_also">SEE ALSO</h2>
	<div class="sectionbody">
	<div class="para"><p><a href="git-fmt-merge-msg.html">git-fmt-merge-msg(1)</a>, <a href="git-pull.html">git-pull(1)</a>,
	<a href="gitattributes.html">gitattributes(5)</a>,
	<a href="git-reset.html">git-reset(1)</a>,
	<a href="git-diff.html">git-diff(1)</a>, <a href="git-ls-files.html">git-ls-files(1)</a>,
	<a href="git-add.html">git-add(1)</a>, <a href="git-rm.html">git-rm(1)</a>,
	<a href="git-mergetool.html">git-mergetool(1)</a></p></div>
	</div>
	<h2 id="_author">Author</h2>
	<div class="sectionbody">
	<div class="para"><p>Written by Junio C Hamano <gitster@pobox.com></p></div>
	</div>
	<h2 id="_documentation">Documentation</h2>
	<div class="sectionbody">
	<div class="para"><p>Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.</p></div>
	</div>
	<h2 id="_git">GIT</h2>
	<div class="sectionbody">
	<div class="para"><p>Part of the <a href="git.html">git(1)</a> suite</p></div>
	</div>
	<div id="footer">
	<div id="footer-text">
	Last updated 2008-08-06 06:19:09 UTC
	</div>
	</div>
	</body>
	</html>