git-commit.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 7.0.2" />
 <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; }
 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 {
  border-bottom: 2px solid silver;
 }
 h2 {
  border-bottom: 2px solid silver;
  padding-top: 0.5em;
 }

 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.2em;
 }
 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 > div.content {
  border: 1px solid silver;
  background: #f4f4f4;
  padding: 0.5em;
 }

 div.quoteblock > div.content {
  padding-left: 2.0em;
 }
 div.quoteblock .attribution {
  text-align: right;
 }

 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;
 }
 ol.olist2 {
  list-style-type: lower-alpha;
 }

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

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

 @media print {
  div#footer-badges { display: none; }
 }
 include::./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;
 }
 </style>
 <title>git-commit(1)</title>
 </head>
 <body>
 <div id="header">
 <h1>
 git-commit(1) Manual Page
 </h1>
 <h2>NAME</h2>
 <div class="sectionbody">
 <p>git-commit -
  Record your changes
 </p>
 </div>
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
 <div class="content"><em>git-commit</em> [-a] [-s] [-v] [(-c | -C) &lt;commit&gt; | -F &lt;file&gt; | -m &lt;msg&gt;]
  [--no-verify] [--amend] [-e] [--author &lt;author&gt;]
  [--] [[-i | -o ]&lt;file&gt;&#8230;]</div></div>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
 <p>Use <em>git commit</em> when you want to record your changes into the repository
 along with a log message describing what the commit is about. All changes
 to be committed must be explicitly identified using one of the following
 methods:</p>
 <ol>
 <li>
 <p>
 by using <a href="git-add.html">git-add(1)</a> to incrementally "add" changes to the
  next commit before using the <em>commit</em> command (Note: even modified
  files must be "added");
 </p>
 </li>
 <li>
 <p>
 by using <a href="git-rm.html">git-rm(1)</a> to identify content removal for the next
  commit, again before using the <em>commit</em> command;
 </p>
 </li>
 <li>
 <p>
 by directly listing files containing changes to be committed as arguments
  to the <em>commit</em> command, in which cases only those files alone will be
  considered for the commit;
 </p>
 </li>
 <li>
 <p>
 by using the -a switch with the <em>commit</em> command to automatically "add"
  changes from all known files i.e. files that have already been committed
  before, and to automatically "rm" files that have been
  removed from the working tree, and perform the actual commit.
 </p>
 </li>
 </ol>
 <p>The <a href="git-status.html">git-status(1)</a> command can be used to obtain a
 summary of what is included by any of the above for the next
 commit by giving the same set of parameters you would give to
 this command.</p>
 <p>If you make a commit and then found a mistake immediately after
 that, you can recover from it with <a href="git-reset.html">git-reset(1)</a>.</p>
 </div>
 <h2>OPTIONS</h2>
 <div class="sectionbody">
 <dl>
 <dt>
 -a|--all
 </dt>
 <dd>
 <p>
  Tell the command to automatically stage files that have
  been modified and deleted, but new files you have not
  told git about are not affected.
 </p>
 </dd>
 <dt>
 -c or -C &lt;commit&gt;
 </dt>
 <dd>
 <p>
  Take existing commit object, and reuse the log message
  and the authorship information (including the timestamp)
  when creating the commit. With <em>-C</em>, the editor is not
  invoked; with <em>-c</em> the user can further edit the commit
  message.
 </p>
 </dd>
 <dt>
 -F &lt;file&gt;
 </dt>
 <dd>
 <p>
  Take the commit message from the given file. Use <em>-</em> to
  read the message from the standard input.
 </p>
 </dd>
 <dt>
 --author &lt;author&gt;
 </dt>
 <dd>
 <p>
  Override the author name used in the commit. Use
  <tt>A U Thor &lt;author@example.com&gt;</tt> format.
 </p>
 </dd>
 <dt>
 -m &lt;msg&gt;
 </dt>
 <dd>
 <p>
  Use the given &lt;msg&gt; as the commit message.
 </p>
 </dd>
 <dt>
 -s|--signoff
 </dt>
 <dd>
 <p>
  Add Signed-off-by line at the end of the commit message.
 </p>
 </dd>
 <dt>
 --no-verify
 </dt>
 <dd>
 <p>
  This option bypasses the pre-commit hook.
  See also <a href="hooks.html">hooks</a>.
 </p>
 </dd>
 <dt>
 -e|--edit
 </dt>
 <dd>
 <p>
  The message taken from file with <tt>-F</tt>, command line with
  <tt>-m</tt>, and from file with <tt>-C</tt> are usually used as the
  commit log message unmodified. This option lets you
  further edit the message taken from these sources.
 </p>
 </dd>
 <dt>
 --amend
 </dt>
 <dd>
 <p>
  Used to amend the tip of the current branch. Prepare the tree
  object you would want to replace the latest commit as usual
  (this includes the usual -i/-o and explicit paths), and the
  commit log editor is seeded with the commit message from the
  tip of the current branch. The commit you create replaces the
  current tip &#8212; if it was a merge, it will have the parents of
  the current tip as parents &#8212; so the current top commit is
  discarded.
 </p>
 <p>It is a rough equivalent for:</p>
 <div class="listingblock">
 <div class="content">
 <pre><tt> $ git reset --soft HEAD^
  $ ... do something else to come up with the right tree ...
  $ git commit -c ORIG_HEAD
 </tt></pre>
 </div></div>
 <p>but can be used to amend a merge commit.</p>
 </dd>
 <dt>
 -i|--include
 </dt>
 <dd>
 <p>
  Before making a commit out of staged contents so far,
  stage the contents of paths given on the command line
  as well. This is usually not what you want unless you
  are concluding a conflicted merge.
 </p>
 </dd>
 <dt>
 -q|--quiet
 </dt>
 <dd>
 <p>
  Suppress commit summary message.
 </p>
 </dd>
 <dt>
 --
 </dt>
 <dd>
 <p>
  Do not interpret any more arguments as options.
 </p>
 </dd>
 <dt>
 &lt;file&gt;&#8230;
 </dt>
 <dd>
 <p>
  When files are given on the command line, the command
  commits the contents of the named files, without
  recording the changes already staged. The contents of
  these files are also staged for the next commit on top
  of what have been staged before.
 </p>
 </dd>
 </dl>
 </div>
 <h2>EXAMPLES</h2>
 <div class="sectionbody">
 <p>When recording your own work, the contents of modified files in
 your working tree are temporarily stored to a staging area
 called the "index" with <a href="git-add.html">git-add(1)</a>. Removal
 of a file is staged with <a href="git-rm.html">git-rm(1)</a>. After building the
 state to be committed incrementally with these commands, <tt>git
 commit</tt> (without any pathname parameter) is used to record what
 has been staged so far. This is the most basic form of the
 command. An example:</p>
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ edit hello.c
 $ git rm goodbye.c
 $ git add hello.c
 $ git commit</tt></pre>
 </div></div>
 <p>Instead of staging files after each individual change, you can
 tell <tt>git commit</tt> to notice the changes to the files whose
 contents are tracked in
 your working tree and do corresponding <tt>git add</tt> and <tt>git rm</tt>
 for you. That is, this example does the same as the earlier
 example if there is no other change in your working tree:</p>
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ edit hello.c
 $ rm goodbye.c
 $ git commit -a</tt></pre>
 </div></div>
 <p>The command <tt>git commit -a</tt> first looks at your working tree,
 notices that you have modified hello.c and removed goodbye.c,
 and performs necessary <tt>git add</tt> and <tt>git rm</tt> for you.</p>
 <p>After staging changes to many files, you can alter the order the
 changes are recorded in, by giving pathnames to <tt>git commit</tt>.
 When pathnames are given, the command makes a commit that
 only records the changes made to the named paths:</p>
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ edit hello.c hello.h
 $ git add hello.c hello.h
 $ edit Makefile
 $ git commit Makefile</tt></pre>
 </div></div>
 <p>This makes a commit that records the modification to <tt>Makefile</tt>.
 The changes staged for <tt>hello.c</tt> and <tt>hello.h</tt> are not included
 in the resulting commit. However, their changes are not lost &#8212;
 they are still staged and merely held back. After the above
 sequence, if you do:</p>
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ git commit</tt></pre>
 </div></div>
 <p>this second commit would record the changes to <tt>hello.c</tt> and
 <tt>hello.h</tt> as expected.</p>
 <p>After a merge (initiated by either <a href="git-merge.html">git-merge(1)</a> or
 <a href="git-pull.html">git-pull(1)</a>) stops because of conflicts, cleanly merged
 paths are already staged to be committed for you, and paths that
 conflicted are left in unmerged state. You would have to first
 check which paths are conflicting with <a href="git-status.html">git-status(1)</a>
 and after fixing them manually in your working tree, you would
 stage the result as usual with <a href="git-add.html">git-add(1)</a>:</p>
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ git status | grep unmerged
 unmerged: hello.c
 $ edit hello.c
 $ git add hello.c</tt></pre>
 </div></div>
 <p>After resolving conflicts and staging the result, <tt>git ls-files -u</tt>
 would stop mentioning the conflicted path. When you are done,
 run <tt>git commit</tt> to finally record the merge:</p>
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ git commit</tt></pre>
 </div></div>
 <p>As with the case to record your own changes, you can use <tt>-a</tt>
 option to save typing. One difference is that during a merge
 resolution, you cannot use <tt>git commit</tt> with pathnames to
 alter the order the changes are committed, because the merge
 should be recorded as a single commit. In fact, the command
 refuses to run when given pathnames (but see <tt>-i</tt> option).</p>
 </div>
 <h2>DISCUSSION</h2>
 <div class="sectionbody">
 <p>Though not required, it's a good idea to begin the commit message
 with a single short (less than 50 character) line summarizing the
 change, followed by a blank line and then a more thorough description.
 Tools that turn commits into email, for example, use the first line
 on the Subject: line and the rest of the commit in the body.</p>
 <p>At the core level, git is character encoding agnostic.</p>
 <ul>
 <li>
 <p>
 The pathnames recorded in the index and in the tree objects
  are treated as uninterpreted sequences of non-NUL bytes.
  What readdir(2) returns are what are recorded and compared
  with the data git keeps track of, which in turn are expected
  to be what lstat(2) and creat(2) accepts. There is no such
  thing as pathname encoding translation.
 </p>
 </li>
 <li>
 <p>
 The contents of the blob objects are uninterpreted sequence
  of bytes. There is no encoding translation at the core
  level.
 </p>
 </li>
 <li>
 <p>
 The commit log messages are uninterpreted sequence of non-NUL
  bytes.
 </p>
 </li>
 </ul>
 <p>Although we encourage that the commit log messages are encoded
 in UTF-8, both the core and git Porcelain are designed not to
 force UTF-8 on projects. If all participants of a particular
 project find it more convenient to use legacy encodings, git
 does not forbid it. However, there are a few things to keep in
 mind.</p>
 <ol>
 <li>
 <p>
 <tt>git-commit-tree</tt> (hence, <tt>git-commit</tt> which uses it) issues
  an warning if the commit log message given to it does not look
  like a valid UTF-8 string, unless you explicitly say your
  project uses a legacy encoding. The way to say this is to
  have core.commitencoding in <tt>.git/config</tt> file, like this:
 </p>
 <div class="listingblock">
 <div class="content">
 <pre><tt>[core]
  commitencoding = ISO-8859-1</tt></pre>
 </div></div>
 <p>Commit objects created with the above setting record the value
 of <tt>core.commitencoding</tt> in its <tt>encoding</tt> header. This is to
 help other people who look at them later. Lack of this header
 implies that the commit log message is encoded in UTF-8.</p>
 </li>
 <li>
 <p>
 <tt>git-log</tt>, <tt>git-show</tt> and friends looks at the <tt>encoding</tt>
  header of a commit object, and tries to re-code the log
  message into UTF-8 unless otherwise specified. You can
  specify the desired output encoding with
  <tt>core.logoutputencoding</tt> in <tt>.git/config</tt> file, like this:
 </p>
 <div class="listingblock">
 <div class="content">
 <pre><tt>[core]
  logoutputencoding = ISO-8859-1</tt></pre>
 </div></div>
 <p>If you do not have this configuration variable, the value of
 <tt>core.commitencoding</tt> is used instead.</p>
 </li>
 </ol>
 <p>Note that we deliberately chose not to re-code the commit log
 message when a commit is made to force UTF-8 at the commit
 object level, because re-coding to UTF-8 is not necessarily a
 reversible operation.</p>
 </div>
 <h2>ENVIRONMENT VARIABLES</h2>
 <div class="sectionbody">
 <p>The command specified by either the VISUAL or EDITOR environment
 variables is used to edit the commit log message.</p>
 </div>
 <h2>HOOKS</h2>
 <div class="sectionbody">
 <p>This command can run <tt>commit-msg</tt>, <tt>pre-commit</tt>, and
 <tt>post-commit</tt> hooks. See <a href="hooks.html">hooks</a> for more
 information.</p>
 </div>
 <h2>SEE ALSO</h2>
 <div class="sectionbody">
 <p><a href="git-add.html">git-add(1)</a>,
 <a href="git-rm.html">git-rm(1)</a>,
 <a href="git-mv.html">git-mv(1)</a>,
 <a href="git-merge.html">git-merge(1)</a>,
 <a href="git-commit-tree.html">git-commit-tree(1)</a></p>
 </div>
 <h2>Author</h2>
 <div class="sectionbody">
 <p>Written by Linus Torvalds &lt;torvalds@osdl.org&gt; and
 Junio C Hamano &lt;junkio@cox.net&gt;</p>
 </div>
 <h2>GIT</h2>
 <div class="sectionbody">
 <p>Part of the <a href="git.html">git(7)</a> suite</p>
 </div>
 <div id="footer">
 <div id="footer-text">
 Last updated 17-Jan-2007 17:42:13 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 7.0.2" />
	<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; }
	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 {
	border-bottom: 2px solid silver;
	}
	h2 {
	border-bottom: 2px solid silver;
	padding-top: 0.5em;
	}

	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.2em;
	}
	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 > div.content {
	border: 1px solid silver;
	background: #f4f4f4;
	padding: 0.5em;
	}

	div.quoteblock > div.content {
	padding-left: 2.0em;
	}
	div.quoteblock .attribution {
	text-align: right;
	}

	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;
	}
	ol.olist2 {
	list-style-type: lower-alpha;
	}

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

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

	@media print {
	div#footer-badges { display: none; }
	}
	include::./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;
	}
	</style>
	<title>git-commit(1)</title>
	</head>
	<body>
	<div id="header">
	<h1>
	git-commit(1) Manual Page
	</h1>
	<h2>NAME</h2>
	<div class="sectionbody">
	<p>git-commit -
	Record your changes
	</p>
	</div>
	</div>
	<h2>SYNOPSIS</h2>
	<div class="sectionbody">
	<div class="verseblock">
	<div class="content"><em>git-commit</em> [-a] [-s] [-v] [(-c \| -C) <commit> \| -F <file> \| -m <msg>]
	[--no-verify] [--amend] [-e] [--author <author>]
	[--] [[-i \| -o ]<file>…]</div></div>
	</div>
	<h2>DESCRIPTION</h2>
	<div class="sectionbody">
	<p>Use <em>git commit</em> when you want to record your changes into the repository
	along with a log message describing what the commit is about. All changes
	to be committed must be explicitly identified using one of the following
	methods:</p>
	<ol>
	<li>
	<p>
	by using <a href="git-add.html">git-add(1)</a> to incrementally "add" changes to the
	next commit before using the <em>commit</em> command (Note: even modified
	files must be "added");
	</p>
	</li>
	<li>
	<p>
	by using <a href="git-rm.html">git-rm(1)</a> to identify content removal for the next
	commit, again before using the <em>commit</em> command;
	</p>
	</li>
	<li>
	<p>
	by directly listing files containing changes to be committed as arguments
	to the <em>commit</em> command, in which cases only those files alone will be
	considered for the commit;
	</p>
	</li>
	<li>
	<p>
	by using the -a switch with the <em>commit</em> command to automatically "add"
	changes from all known files i.e. files that have already been committed
	before, and to automatically "rm" files that have been
	removed from the working tree, and perform the actual commit.
	</p>
	</li>
	</ol>
	<p>The <a href="git-status.html">git-status(1)</a> command can be used to obtain a
	summary of what is included by any of the above for the next
	commit by giving the same set of parameters you would give to
	this command.</p>
	<p>If you make a commit and then found a mistake immediately after
	that, you can recover from it with <a href="git-reset.html">git-reset(1)</a>.</p>
	</div>
	<h2>OPTIONS</h2>
	<div class="sectionbody">
	<dl>
	<dt>
	-a\|--all
	</dt>
	<dd>
	<p>
	Tell the command to automatically stage files that have
	been modified and deleted, but new files you have not
	told git about are not affected.
	</p>
	</dd>
	<dt>
	-c or -C <commit>
	</dt>
	<dd>
	<p>
	Take existing commit object, and reuse the log message
	and the authorship information (including the timestamp)
	when creating the commit. With <em>-C</em>, the editor is not
	invoked; with <em>-c</em> the user can further edit the commit
	message.
	</p>
	</dd>
	<dt>
	-F <file>
	</dt>
	<dd>
	<p>
	Take the commit message from the given file. Use <em>-</em> to
	read the message from the standard input.
	</p>
	</dd>
	<dt>
	--author <author>
	</dt>
	<dd>
	<p>
	Override the author name used in the commit. Use
	<tt>A U Thor <author@example.com></tt> format.
	</p>
	</dd>
	<dt>
	-m <msg>
	</dt>
	<dd>
	<p>
	Use the given <msg> as the commit message.
	</p>
	</dd>
	<dt>
	-s\|--signoff
	</dt>
	<dd>
	<p>
	Add Signed-off-by line at the end of the commit message.
	</p>
	</dd>
	<dt>
	--no-verify
	</dt>
	<dd>
	<p>
	This option bypasses the pre-commit hook.
	See also <a href="hooks.html">hooks</a>.
	</p>
	</dd>
	<dt>
	-e\|--edit
	</dt>
	<dd>
	<p>
	The message taken from file with <tt>-F</tt>, command line with
	<tt>-m</tt>, and from file with <tt>-C</tt> are usually used as the
	commit log message unmodified. This option lets you
	further edit the message taken from these sources.
	</p>
	</dd>
	<dt>
	--amend
	</dt>
	<dd>
	<p>
	Used to amend the tip of the current branch. Prepare the tree
	object you would want to replace the latest commit as usual
	(this includes the usual -i/-o and explicit paths), and the
	commit log editor is seeded with the commit message from the
	tip of the current branch. The commit you create replaces the
	current tip — if it was a merge, it will have the parents of
	the current tip as parents — so the current top commit is
	discarded.
	</p>
	<p>It is a rough equivalent for:</p>
	<div class="listingblock">
	<div class="content">
	<pre><tt> $ git reset --soft HEAD^
	$ ... do something else to come up with the right tree ...
	$ git commit -c ORIG_HEAD
	</tt></pre>
	</div></div>
	<p>but can be used to amend a merge commit.</p>
	</dd>
	<dt>
	-i\|--include
	</dt>
	<dd>
	<p>
	Before making a commit out of staged contents so far,
	stage the contents of paths given on the command line
	as well. This is usually not what you want unless you
	are concluding a conflicted merge.
	</p>
	</dd>
	<dt>
	-q\|--quiet
	</dt>
	<dd>
	<p>
	Suppress commit summary message.
	</p>
	</dd>
	<dt>
	--
	</dt>
	<dd>
	<p>
	Do not interpret any more arguments as options.
	</p>
	</dd>
	<dt>
	<file>…
	</dt>
	<dd>
	<p>
	When files are given on the command line, the command
	commits the contents of the named files, without
	recording the changes already staged. The contents of
	these files are also staged for the next commit on top
	of what have been staged before.
	</p>
	</dd>
	</dl>
	</div>
	<h2>EXAMPLES</h2>
	<div class="sectionbody">
	<p>When recording your own work, the contents of modified files in
	your working tree are temporarily stored to a staging area
	called the "index" with <a href="git-add.html">git-add(1)</a>. Removal
	of a file is staged with <a href="git-rm.html">git-rm(1)</a>. After building the
	state to be committed incrementally with these commands, <tt>git
	commit</tt> (without any pathname parameter) is used to record what
	has been staged so far. This is the most basic form of the
	command. An example:</p>
	<div class="listingblock">
	<div class="content">
	<pre><tt>$ edit hello.c
	$ git rm goodbye.c
	$ git add hello.c
	$ git commit</tt></pre>
	</div></div>
	<p>Instead of staging files after each individual change, you can
	tell <tt>git commit</tt> to notice the changes to the files whose
	contents are tracked in
	your working tree and do corresponding <tt>git add</tt> and <tt>git rm</tt>
	for you. That is, this example does the same as the earlier
	example if there is no other change in your working tree:</p>
	<div class="listingblock">
	<div class="content">
	<pre><tt>$ edit hello.c
	$ rm goodbye.c
	$ git commit -a</tt></pre>
	</div></div>
	<p>The command <tt>git commit -a</tt> first looks at your working tree,
	notices that you have modified hello.c and removed goodbye.c,
	and performs necessary <tt>git add</tt> and <tt>git rm</tt> for you.</p>
	<p>After staging changes to many files, you can alter the order the
	changes are recorded in, by giving pathnames to <tt>git commit</tt>.
	When pathnames are given, the command makes a commit that
	only records the changes made to the named paths:</p>
	<div class="listingblock">
	<div class="content">
	<pre><tt>$ edit hello.c hello.h
	$ git add hello.c hello.h
	$ edit Makefile
	$ git commit Makefile</tt></pre>
	</div></div>
	<p>This makes a commit that records the modification to <tt>Makefile</tt>.
	The changes staged for <tt>hello.c</tt> and <tt>hello.h</tt> are not included
	in the resulting commit. However, their changes are not lost —
	they are still staged and merely held back. After the above
	sequence, if you do:</p>
	<div class="listingblock">
	<div class="content">
	<pre><tt>$ git commit</tt></pre>
	</div></div>
	<p>this second commit would record the changes to <tt>hello.c</tt> and
	<tt>hello.h</tt> as expected.</p>
	<p>After a merge (initiated by either <a href="git-merge.html">git-merge(1)</a> or
	<a href="git-pull.html">git-pull(1)</a>) stops because of conflicts, cleanly merged
	paths are already staged to be committed for you, and paths that
	conflicted are left in unmerged state. You would have to first
	check which paths are conflicting with <a href="git-status.html">git-status(1)</a>
	and after fixing them manually in your working tree, you would
	stage the result as usual with <a href="git-add.html">git-add(1)</a>:</p>
	<div class="listingblock">
	<div class="content">
	<pre><tt>$ git status \| grep unmerged
	unmerged: hello.c
	$ edit hello.c
	$ git add hello.c</tt></pre>
	</div></div>
	<p>After resolving conflicts and staging the result, <tt>git ls-files -u</tt>
	would stop mentioning the conflicted path. When you are done,
	run <tt>git commit</tt> to finally record the merge:</p>
	<div class="listingblock">
	<div class="content">
	<pre><tt>$ git commit</tt></pre>
	</div></div>
	<p>As with the case to record your own changes, you can use <tt>-a</tt>
	option to save typing. One difference is that during a merge
	resolution, you cannot use <tt>git commit</tt> with pathnames to
	alter the order the changes are committed, because the merge
	should be recorded as a single commit. In fact, the command
	refuses to run when given pathnames (but see <tt>-i</tt> option).</p>
	</div>
	<h2>DISCUSSION</h2>
	<div class="sectionbody">
	<p>Though not required, it's a good idea to begin the commit message
	with a single short (less than 50 character) line summarizing the
	change, followed by a blank line and then a more thorough description.
	Tools that turn commits into email, for example, use the first line
	on the Subject: line and the rest of the commit in the body.</p>
	<p>At the core level, git is character encoding agnostic.</p>
	<ul>
	<li>
	<p>
	The pathnames recorded in the index and in the tree objects
	are treated as uninterpreted sequences of non-NUL bytes.
	What readdir(2) returns are what are recorded and compared
	with the data git keeps track of, which in turn are expected
	to be what lstat(2) and creat(2) accepts. There is no such
	thing as pathname encoding translation.
	</p>
	</li>
	<li>
	<p>
	The contents of the blob objects are uninterpreted sequence
	of bytes. There is no encoding translation at the core
	level.
	</p>
	</li>
	<li>
	<p>
	The commit log messages are uninterpreted sequence of non-NUL
	bytes.
	</p>
	</li>
	</ul>
	<p>Although we encourage that the commit log messages are encoded
	in UTF-8, both the core and git Porcelain are designed not to
	force UTF-8 on projects. If all participants of a particular
	project find it more convenient to use legacy encodings, git
	does not forbid it. However, there are a few things to keep in
	mind.</p>
	<ol>
	<li>
	<p>
	<tt>git-commit-tree</tt> (hence, <tt>git-commit</tt> which uses it) issues
	an warning if the commit log message given to it does not look
	like a valid UTF-8 string, unless you explicitly say your
	project uses a legacy encoding. The way to say this is to
	have core.commitencoding in <tt>.git/config</tt> file, like this:
	</p>
	<div class="listingblock">
	<div class="content">
	<pre><tt>[core]
	commitencoding = ISO-8859-1</tt></pre>
	</div></div>
	<p>Commit objects created with the above setting record the value
	of <tt>core.commitencoding</tt> in its <tt>encoding</tt> header. This is to
	help other people who look at them later. Lack of this header
	implies that the commit log message is encoded in UTF-8.</p>
	</li>
	<li>
	<p>
	<tt>git-log</tt>, <tt>git-show</tt> and friends looks at the <tt>encoding</tt>
	header of a commit object, and tries to re-code the log
	message into UTF-8 unless otherwise specified. You can
	specify the desired output encoding with
	<tt>core.logoutputencoding</tt> in <tt>.git/config</tt> file, like this:
	</p>
	<div class="listingblock">
	<div class="content">
	<pre><tt>[core]
	logoutputencoding = ISO-8859-1</tt></pre>
	</div></div>
	<p>If you do not have this configuration variable, the value of
	<tt>core.commitencoding</tt> is used instead.</p>
	</li>
	</ol>
	<p>Note that we deliberately chose not to re-code the commit log
	message when a commit is made to force UTF-8 at the commit
	object level, because re-coding to UTF-8 is not necessarily a
	reversible operation.</p>
	</div>
	<h2>ENVIRONMENT VARIABLES</h2>
	<div class="sectionbody">
	<p>The command specified by either the VISUAL or EDITOR environment
	variables is used to edit the commit log message.</p>
	</div>
	<h2>HOOKS</h2>
	<div class="sectionbody">
	<p>This command can run <tt>commit-msg</tt>, <tt>pre-commit</tt>, and
	<tt>post-commit</tt> hooks. See <a href="hooks.html">hooks</a> for more
	information.</p>
	</div>
	<h2>SEE ALSO</h2>
	<div class="sectionbody">
	<p><a href="git-add.html">git-add(1)</a>,
	<a href="git-rm.html">git-rm(1)</a>,
	<a href="git-mv.html">git-mv(1)</a>,
	<a href="git-merge.html">git-merge(1)</a>,
	<a href="git-commit-tree.html">git-commit-tree(1)</a></p>
	</div>
	<h2>Author</h2>
	<div class="sectionbody">
	<p>Written by Linus Torvalds <torvalds@osdl.org> and
	Junio C Hamano <junkio@cox.net></p>
	</div>
	<h2>GIT</h2>
	<div class="sectionbody">
	<p>Part of the <a href="git.html">git(7)</a> suite</p>
	</div>
	<div id="footer">
	<div id="footer-text">
	Last updated 17-Jan-2007 17:42:13 UTC
	</div>
	</div>
	</body>
	</html>