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 changes to the repository
 </p>
 </div>
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
 <div class="verseblock">
 <div class="content"><em>git-commit</em> [-a | --interactive] [-s] [-v] [-u]
  [(-c | -C) &lt;commit&gt; | -F &lt;file&gt; | -m &lt;msg&gt; | --amend]
  [--allow-empty] [--no-verify] [-e] [--author &lt;author&gt;]
  [--cleanup=&lt;mode&gt;] [--] [[-i | -o ]&lt;file&gt;&#8230;]</div></div>
 </div>
 <h2>DESCRIPTION</h2>
 <div class="sectionbody">
 <p>Use <em>git commit</em> to store the current contents of the index in a new
 commit along with a log message describing the changes you have made.</p>
 <p>The content to be added can be specified in several ways:</p>
 <ol>
 <li>
 <p>
 by using <a href="git-add.html">git-add(1)</a> to incrementally "add" changes to the
  index 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 remove files from the working tree
  and the index, again before using the <em>commit</em> command;
 </p>
 </li>
 <li>
 <p>
 by listing files as arguments to the <em>commit</em> command, in which
  case the commit will ignore changes staged in the index, and instead
  record the current content of the listed files;
 </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. all files that are already
  listed in the index) and to automatically "rm" files in the index
  that have been removed from the working tree, and then perform the
  actual commit;
 </p>
 </li>
 <li>
 <p>
 by using the --interactive switch with the <em>commit</em> command to decide one
  by one which files should be part of the commit, before finalizing the
  operation. Currently, this is done by invoking <tt>git-add --interactive</tt>.
 </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;|--message=&lt;msg&gt;
 </dt>
 <dd>
 <p>
  Use the given &lt;msg&gt; as the commit message.
 </p>
 </dd>
 <dt>
 -t &lt;file&gt;|--template=&lt;file&gt;
 </dt>
 <dd>
 <p>
  Use the contents of the given file as the initial version
  of the commit message. The editor is invoked and you can
  make subsequent changes. If a message is specified using
  the <tt>-m</tt> or <tt>-F</tt> options, this option has no effect. This
  overrides the <tt>commit.template</tt> configuration variable.
 </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 and commit-msg hooks.
  See also <a href="hooks.html">hooks</a>.
 </p>
 </dd>
 <dt>
 --allow-empty
 </dt>
 <dd>
 <p>
  Usually recording a commit that has the exact same tree as its
  sole parent commit is a mistake, and the command prevents you
  from making such a commit. This option bypasses the safety, and
  is primarily for use by foreign scm interface scripts.
 </p>
 </dd>
 <dt>
 --cleanup=&lt;mode&gt;
 </dt>
 <dd>
 <p>
  This option sets how the commit message is cleaned up.
  The <em>&lt;mode&gt;</em> can be one of <em>verbatim</em>, <em>whitespace</em>, <em>strip</em>,
  and <em>default</em>. The <em>default</em> mode will strip leading and
  trailing empty lines and #commentary from the commit message
  only if the message is to be edited. Otherwise only whitespace
  removed. The <em>verbatim</em> mode does not change message at all,
  <em>whitespace</em> removes just leading/trailing whitespace lines
  and <em>strip</em> removes both whitespace and commentary.
 </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>
 -u|--untracked-files
 </dt>
 <dd>
 <p>
  Show all untracked files, also those in uninteresting
  directories, in the "Untracked files:" section of commit
  message template. Without this option only its name and
  a trailing slash are displayed for each untracked
  directory.
 </p>
 </dd>
 <dt>
 -v|--verbose
 </dt>
 <dd>
 <p>
  Show unified diff between the HEAD commit and what
  would be committed at the bottom of the commit message
  template. Note that this diff output doesn't have its
  lines prefixed with <em>#</em>.
 </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>. A file can be
 reverted back, only in the index but not in the working tree,
 to that of the last commit with <tt>git-reset HEAD &#8212; &lt;file&gt;</tt>,
 which effectively reverts <tt>git-add</tt> and prevents the changes to
 this file from participating in the next commit. 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
  a 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 i18n.commitencoding in <tt>.git/config</tt> file, like this:
 </p>
 <div class="listingblock">
 <div class="content">
 <pre><tt>[i18n]
  commitencoding = ISO-8859-1</tt></pre>
 </div></div>
 <p>Commit objects created with the above setting record the value
 of <tt>i18n.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>i18n.logoutputencoding</tt> in <tt>.git/config</tt> file, like this:
 </p>
 <div class="listingblock">
 <div class="content">
 <pre><tt>[i18n]
  logoutputencoding = ISO-8859-1</tt></pre>
 </div></div>
 <p>If you do not have this configuration variable, the value of
 <tt>i18n.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 AND CONFIGURATION VARIABLES</h2>
 <div class="sectionbody">
 <p>The editor used to edit the commit log message will be chosen from the
 GIT_EDITOR environment variable, the core.editor configuration variable, the
 VISUAL environment variable, or the EDITOR environment variable (in that
 order).</p>
 </div>
 <h2>HOOKS</h2>
 <div class="sectionbody">
 <p>This command can run <tt>commit-msg</tt>, <tt>prepare-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-Feb-2008 03:50:04 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 changes to the repository
	</p>
	</div>
	</div>
	<h2>SYNOPSIS</h2>
	<div class="sectionbody">
	<div class="verseblock">
	<div class="content"><em>git-commit</em> [-a \| --interactive] [-s] [-v] [-u]
	[(-c \| -C) <commit> \| -F <file> \| -m <msg> \| --amend]
	[--allow-empty] [--no-verify] [-e] [--author <author>]
	[--cleanup=<mode>] [--] [[-i \| -o ]<file>…]</div></div>
	</div>
	<h2>DESCRIPTION</h2>
	<div class="sectionbody">
	<p>Use <em>git commit</em> to store the current contents of the index in a new
	commit along with a log message describing the changes you have made.</p>
	<p>The content to be added can be specified in several ways:</p>
	<ol>
	<li>
	<p>
	by using <a href="git-add.html">git-add(1)</a> to incrementally "add" changes to the
	index 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 remove files from the working tree
	and the index, again before using the <em>commit</em> command;
	</p>
	</li>
	<li>
	<p>
	by listing files as arguments to the <em>commit</em> command, in which
	case the commit will ignore changes staged in the index, and instead
	record the current content of the listed files;
	</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. all files that are already
	listed in the index) and to automatically "rm" files in the index
	that have been removed from the working tree, and then perform the
	actual commit;
	</p>
	</li>
	<li>
	<p>
	by using the --interactive switch with the <em>commit</em> command to decide one
	by one which files should be part of the commit, before finalizing the
	operation. Currently, this is done by invoking <tt>git-add --interactive</tt>.
	</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>\|--message=<msg>
	</dt>
	<dd>
	<p>
	Use the given <msg> as the commit message.
	</p>
	</dd>
	<dt>
	-t <file>\|--template=<file>
	</dt>
	<dd>
	<p>
	Use the contents of the given file as the initial version
	of the commit message. The editor is invoked and you can
	make subsequent changes. If a message is specified using
	the <tt>-m</tt> or <tt>-F</tt> options, this option has no effect. This
	overrides the <tt>commit.template</tt> configuration variable.
	</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 and commit-msg hooks.
	See also <a href="hooks.html">hooks</a>.
	</p>
	</dd>
	<dt>
	--allow-empty
	</dt>
	<dd>
	<p>
	Usually recording a commit that has the exact same tree as its
	sole parent commit is a mistake, and the command prevents you
	from making such a commit. This option bypasses the safety, and
	is primarily for use by foreign scm interface scripts.
	</p>
	</dd>
	<dt>
	--cleanup=<mode>
	</dt>
	<dd>
	<p>
	This option sets how the commit message is cleaned up.
	The <em><mode></em> can be one of <em>verbatim</em>, <em>whitespace</em>, <em>strip</em>,
	and <em>default</em>. The <em>default</em> mode will strip leading and
	trailing empty lines and #commentary from the commit message
	only if the message is to be edited. Otherwise only whitespace
	removed. The <em>verbatim</em> mode does not change message at all,
	<em>whitespace</em> removes just leading/trailing whitespace lines
	and <em>strip</em> removes both whitespace and commentary.
	</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>
	-u\|--untracked-files
	</dt>
	<dd>
	<p>
	Show all untracked files, also those in uninteresting
	directories, in the "Untracked files:" section of commit
	message template. Without this option only its name and
	a trailing slash are displayed for each untracked
	directory.
	</p>
	</dd>
	<dt>
	-v\|--verbose
	</dt>
	<dd>
	<p>
	Show unified diff between the HEAD commit and what
	would be committed at the bottom of the commit message
	template. Note that this diff output doesn't have its
	lines prefixed with <em>#</em>.
	</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>. A file can be
	reverted back, only in the index but not in the working tree,
	to that of the last commit with <tt>git-reset HEAD — <file></tt>,
	which effectively reverts <tt>git-add</tt> and prevents the changes to
	this file from participating in the next commit. 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
	a 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 i18n.commitencoding in <tt>.git/config</tt> file, like this:
	</p>
	<div class="listingblock">
	<div class="content">
	<pre><tt>[i18n]
	commitencoding = ISO-8859-1</tt></pre>
	</div></div>
	<p>Commit objects created with the above setting record the value
	of <tt>i18n.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>i18n.logoutputencoding</tt> in <tt>.git/config</tt> file, like this:
	</p>
	<div class="listingblock">
	<div class="content">
	<pre><tt>[i18n]
	logoutputencoding = ISO-8859-1</tt></pre>
	</div></div>
	<p>If you do not have this configuration variable, the value of
	<tt>i18n.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 AND CONFIGURATION VARIABLES</h2>
	<div class="sectionbody">
	<p>The editor used to edit the commit log message will be chosen from the
	GIT_EDITOR environment variable, the core.editor configuration variable, the
	VISUAL environment variable, or the EDITOR environment variable (in that
	order).</p>
	</div>
	<h2>HOOKS</h2>
	<div class="sectionbody">
	<p>This command can run <tt>commit-msg</tt>, <tt>prepare-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-Feb-2008 03:50:04 UTC
	</div>
	</div>
	</body>
	</html>