OSDN Git Service

Add Git official document to help
[tortoisegit/TortoiseGitJp.git] / doc / source / en / TortoiseGit / git_doc / git-commit.html.xml
1 <?xml version="1.0" encoding="UTF-8"?>\r
2 <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">\r
3 \r
4 <article lang="en" id="git-commit(1)">\r
5 <articleinfo>\r
6     <title>git-commit(1)</title>\r
7         <indexterm>\r
8                 <primary>git-commit(1)</primary>\r
9         </indexterm>\r
10 </articleinfo>\r
11 <simplesect id="_name">\r
12 <title>NAME</title>\r
13 <simpara>git-commit - Record changes to the repository</simpara>\r
14 </simplesect>\r
15 <simplesect id="_synopsis">\r
16 <title>SYNOPSIS</title>\r
17 <blockquote>\r
18 <literallayout><emphasis>git commit</emphasis> [-a | --interactive] [-s] [-v] [-u&lt;mode&gt;] [--amend]\r
19            [(-c | -C) &lt;commit&gt;] [-F &lt;file&gt; | -m &lt;msg&gt;]\r
20            [--allow-empty] [--no-verify] [-e] [--author=&lt;author&gt;]\r
21            [--cleanup=&lt;mode&gt;] [--] [[-i | -o ]&lt;file&gt;&#8230;]</literallayout>\r
22 </blockquote>\r
23 </simplesect>\r
24 <simplesect id="_description">\r
25 <title>DESCRIPTION</title>\r
26 <simpara>Stores the current contents of the index in a new commit along\r
27 with a log message from the user describing the changes.</simpara>\r
28 <simpara>The content to be added can be specified in several ways:</simpara>\r
29 <orderedlist numeration="arabic">\r
30 <listitem>\r
31 <simpara>\r
32 by using <emphasis>git-add</emphasis> to incrementally "add" changes to the\r
33    index before using the <emphasis>commit</emphasis> command (Note: even modified\r
34    files must be "added");\r
35 </simpara>\r
36 </listitem>\r
37 <listitem>\r
38 <simpara>\r
39 by using <emphasis>git-rm</emphasis> to remove files from the working tree\r
40    and the index, again before using the <emphasis>commit</emphasis> command;\r
41 </simpara>\r
42 </listitem>\r
43 <listitem>\r
44 <simpara>\r
45 by listing files as arguments to the <emphasis>commit</emphasis> command, in which\r
46    case the commit will ignore changes staged in the index, and instead\r
47    record the current content of the listed files (which must already\r
48    be known to git);\r
49 </simpara>\r
50 </listitem>\r
51 <listitem>\r
52 <simpara>\r
53 by using the -a switch with the <emphasis>commit</emphasis> command to automatically\r
54    "add" changes from all known files (i.e. all files that are already\r
55    listed in the index) and to automatically "rm" files in the index\r
56    that have been removed from the working tree, and then perform the\r
57    actual commit;\r
58 </simpara>\r
59 </listitem>\r
60 <listitem>\r
61 <simpara>\r
62 by using the --interactive switch with the <emphasis>commit</emphasis> command to decide one\r
63    by one which files should be part of the commit, before finalizing the\r
64    operation.  Currently, this is done by invoking <emphasis>git-add --interactive</emphasis>.\r
65 </simpara>\r
66 </listitem>\r
67 </orderedlist>\r
68 <simpara>The <emphasis>git-status</emphasis> command can be used to obtain a\r
69 summary of what is included by any of the above for the next\r
70 commit by giving the same set of parameters you would give to\r
71 this command.</simpara>\r
72 <simpara>If you make a commit and then find a mistake immediately after\r
73 that, you can recover from it with <emphasis>git-reset</emphasis>.</simpara>\r
74 </simplesect>\r
75 <simplesect id="_options">\r
76 <title>OPTIONS</title>\r
77 <variablelist>\r
78 <varlistentry>\r
79 <term>\r
80 -a\r
81 </term>\r
82 <term>\r
83 --all\r
84 </term>\r
85 <listitem>\r
86 <simpara>\r
87         Tell the command to automatically stage files that have\r
88         been modified and deleted, but new files you have not\r
89         told git about are not affected.\r
90 </simpara>\r
91 </listitem>\r
92 </varlistentry>\r
93 <varlistentry>\r
94 <term>\r
95 -C &lt;commit&gt;\r
96 </term>\r
97 <term>\r
98 --reuse-message=&lt;commit&gt;\r
99 </term>\r
100 <listitem>\r
101 <simpara>\r
102         Take an existing commit object, and reuse the log message\r
103         and the authorship information (including the timestamp)\r
104         when creating the commit.\r
105 </simpara>\r
106 </listitem>\r
107 </varlistentry>\r
108 <varlistentry>\r
109 <term>\r
110 -c &lt;commit&gt;\r
111 </term>\r
112 <term>\r
113 --reedit-message=&lt;commit&gt;\r
114 </term>\r
115 <listitem>\r
116 <simpara>\r
117         Like <emphasis>-C</emphasis>, but with <emphasis>-c</emphasis> the editor is invoked, so that\r
118         the user can further edit the commit message.\r
119 </simpara>\r
120 </listitem>\r
121 </varlistentry>\r
122 <varlistentry>\r
123 <term>\r
124 -F &lt;file&gt;\r
125 </term>\r
126 <term>\r
127 --file=&lt;file&gt;\r
128 </term>\r
129 <listitem>\r
130 <simpara>\r
131         Take the commit message from the given file.  Use <emphasis>-</emphasis> to\r
132         read the message from the standard input.\r
133 </simpara>\r
134 </listitem>\r
135 </varlistentry>\r
136 <varlistentry>\r
137 <term>\r
138 --author=&lt;author&gt;\r
139 </term>\r
140 <listitem>\r
141 <simpara>\r
142         Override the author name used in the commit.  You can use the\r
143         standard <literal>A U Thor &lt;<ulink url="mailto:author@example.com">author@example.com</ulink>&gt;</literal> format.  Otherwise,\r
144         an existing commit that matches the given string and its author\r
145         name is used.\r
146 </simpara>\r
147 </listitem>\r
148 </varlistentry>\r
149 <varlistentry>\r
150 <term>\r
151 -m &lt;msg&gt;\r
152 </term>\r
153 <term>\r
154 --message=&lt;msg&gt;\r
155 </term>\r
156 <listitem>\r
157 <simpara>\r
158         Use the given &lt;msg&gt; as the commit message.\r
159 </simpara>\r
160 </listitem>\r
161 </varlistentry>\r
162 <varlistentry>\r
163 <term>\r
164 -t &lt;file&gt;\r
165 </term>\r
166 <term>\r
167 --template=&lt;file&gt;\r
168 </term>\r
169 <listitem>\r
170 <simpara>\r
171         Use the contents of the given file as the initial version\r
172         of the commit message. The editor is invoked and you can\r
173         make subsequent changes. If a message is specified using\r
174         the <literal>-m</literal> or <literal>-F</literal> options, this option has no effect. This\r
175         overrides the <literal>commit.template</literal> configuration variable.\r
176 </simpara>\r
177 </listitem>\r
178 </varlistentry>\r
179 <varlistentry>\r
180 <term>\r
181 -s\r
182 </term>\r
183 <term>\r
184 --signoff\r
185 </term>\r
186 <listitem>\r
187 <simpara>\r
188         Add Signed-off-by line by the committer at the end of the commit\r
189         log message.\r
190 </simpara>\r
191 </listitem>\r
192 </varlistentry>\r
193 <varlistentry>\r
194 <term>\r
195 -n\r
196 </term>\r
197 <term>\r
198 --no-verify\r
199 </term>\r
200 <listitem>\r
201 <simpara>\r
202         This option bypasses the pre-commit and commit-msg hooks.\r
203         See also <xref linkend="githooks(5)"/>.\r
204 </simpara>\r
205 </listitem>\r
206 </varlistentry>\r
207 <varlistentry>\r
208 <term>\r
209 --allow-empty\r
210 </term>\r
211 <listitem>\r
212 <simpara>\r
213         Usually recording a commit that has the exact same tree as its\r
214         sole parent commit is a mistake, and the command prevents you\r
215         from making such a commit.  This option bypasses the safety, and\r
216         is primarily for use by foreign scm interface scripts.\r
217 </simpara>\r
218 </listitem>\r
219 </varlistentry>\r
220 <varlistentry>\r
221 <term>\r
222 --cleanup=&lt;mode&gt;\r
223 </term>\r
224 <listitem>\r
225 <simpara>\r
226         This option sets how the commit message is cleaned up.\r
227         The  <emphasis>&lt;mode&gt;</emphasis> can be one of <emphasis>verbatim</emphasis>, <emphasis>whitespace</emphasis>, <emphasis>strip</emphasis>,\r
228         and <emphasis>default</emphasis>. The <emphasis>default</emphasis> mode will strip leading and\r
229         trailing empty lines and #commentary from the commit message\r
230         only if the message is to be edited. Otherwise only whitespace\r
231         removed. The <emphasis>verbatim</emphasis> mode does not change message at all,\r
232         <emphasis>whitespace</emphasis> removes just leading/trailing whitespace lines\r
233         and <emphasis>strip</emphasis> removes both whitespace and commentary.\r
234 </simpara>\r
235 </listitem>\r
236 </varlistentry>\r
237 <varlistentry>\r
238 <term>\r
239 -e\r
240 </term>\r
241 <term>\r
242 --edit\r
243 </term>\r
244 <listitem>\r
245 <simpara>\r
246         The message taken from file with <literal>-F</literal>, command line with\r
247         <literal>-m</literal>, and from file with <literal>-C</literal> are usually used as the\r
248         commit log message unmodified.  This option lets you\r
249         further edit the message taken from these sources.\r
250 </simpara>\r
251 </listitem>\r
252 </varlistentry>\r
253 <varlistentry>\r
254 <term>\r
255 --amend\r
256 </term>\r
257 <listitem>\r
258 <simpara>\r
259         Used to amend the tip of the current branch. Prepare the tree\r
260         object you would want to replace the latest commit as usual\r
261         (this includes the usual -i/-o and explicit paths), and the\r
262         commit log editor is seeded with the commit message from the\r
263         tip of the current branch. The commit you create replaces the\r
264         current tip&#8201;&#8212;&#8201;if it was a merge, it will have the parents of\r
265         the current tip as parents&#8201;&#8212;&#8201;so the current top commit is\r
266         discarded.\r
267 </simpara>\r
268 <simpara>It is a rough equivalent for:</simpara>\r
269 <literallayout>        $ git reset --soft HEAD^\r
270         $ ... do something else to come up with the right tree ...\r
271         $ git commit -c ORIG_HEAD</literallayout>\r
272 <simpara>but can be used to amend a merge commit.</simpara>\r
273 <simpara>You should understand the implications of rewriting history if you\r
274 amend a commit that has already been published.  (See the "RECOVERING\r
275 FROM UPSTREAM REBASE" section in <xref linkend="git-rebase(1)"/>.)</simpara>\r
276 </listitem>\r
277 </varlistentry>\r
278 <varlistentry>\r
279 <term>\r
280 -i\r
281 </term>\r
282 <term>\r
283 --include\r
284 </term>\r
285 <listitem>\r
286 <simpara>\r
287         Before making a commit out of staged contents so far,\r
288         stage the contents of paths given on the command line\r
289         as well.  This is usually not what you want unless you\r
290         are concluding a conflicted merge.\r
291 </simpara>\r
292 </listitem>\r
293 </varlistentry>\r
294 <varlistentry>\r
295 <term>\r
296 -o\r
297 </term>\r
298 <term>\r
299 --only\r
300 </term>\r
301 <listitem>\r
302 <simpara>\r
303         Make a commit only from the paths specified on the\r
304         command line, disregarding any contents that have been\r
305         staged so far. This is the default mode of operation of\r
306         <emphasis>git-commit</emphasis> if any paths are given on the command line,\r
307         in which case this option can be omitted.\r
308         If this option is specified together with <emphasis>--amend</emphasis>, then\r
309         no paths need to be specified, which can be used to amend\r
310         the last commit without committing changes that have\r
311         already been staged.\r
312 </simpara>\r
313 </listitem>\r
314 </varlistentry>\r
315 <varlistentry>\r
316 <term>\r
317 -u[&lt;mode&gt;]\r
318 </term>\r
319 <term>\r
320 --untracked-files[=&lt;mode&gt;]\r
321 </term>\r
322 <listitem>\r
323 <simpara>\r
324         Show untracked files (Default: <emphasis>all</emphasis>).\r
325 </simpara>\r
326 <simpara>The mode parameter is optional, and is used to specify\r
327 the handling of untracked files. The possible options are:</simpara>\r
328 <itemizedlist>\r
329 <listitem>\r
330 <simpara>\r
331 <emphasis>no</emphasis>     - Show no untracked files\r
332 </simpara>\r
333 </listitem>\r
334 <listitem>\r
335 <simpara>\r
336 <emphasis>normal</emphasis> - Shows untracked files and directories\r
337 </simpara>\r
338 </listitem>\r
339 <listitem>\r
340 <simpara>\r
341 <emphasis>all</emphasis>    - Also shows individual files in untracked directories.\r
342 </simpara>\r
343 </listitem>\r
344 </itemizedlist>\r
345 <simpara>See <xref linkend="git-config(1)"/> for configuration variable\r
346 used to change the default for when the option is not\r
347 specified.</simpara>\r
348 </listitem>\r
349 </varlistentry>\r
350 <varlistentry>\r
351 <term>\r
352 -v\r
353 </term>\r
354 <term>\r
355 --verbose\r
356 </term>\r
357 <listitem>\r
358 <simpara>\r
359         Show unified diff between the HEAD commit and what\r
360         would be committed at the bottom of the commit message\r
361         template.  Note that this diff output doesn&#8217;t have its\r
362         lines prefixed with <emphasis>#</emphasis>.\r
363 </simpara>\r
364 </listitem>\r
365 </varlistentry>\r
366 <varlistentry>\r
367 <term>\r
368 -q\r
369 </term>\r
370 <term>\r
371 --quiet\r
372 </term>\r
373 <listitem>\r
374 <simpara>\r
375         Suppress commit summary message.\r
376 </simpara>\r
377 </listitem>\r
378 </varlistentry>\r
379 <varlistentry>\r
380 <term>\r
381 --\r
382 </term>\r
383 <listitem>\r
384 <simpara>\r
385         Do not interpret any more arguments as options.\r
386 </simpara>\r
387 </listitem>\r
388 </varlistentry>\r
389 <varlistentry>\r
390 <term>\r
391 &lt;file&gt;&#8230;\r
392 </term>\r
393 <listitem>\r
394 <simpara>\r
395         When files are given on the command line, the command\r
396         commits the contents of the named files, without\r
397         recording the changes already staged.  The contents of\r
398         these files are also staged for the next commit on top\r
399         of what have been staged before.\r
400 </simpara>\r
401 </listitem>\r
402 </varlistentry>\r
403 </variablelist>\r
404 </simplesect>\r
405 <simplesect id="_examples">\r
406 <title>EXAMPLES</title>\r
407 <simpara>When recording your own work, the contents of modified files in\r
408 your working tree are temporarily stored to a staging area\r
409 called the "index" with <emphasis>git-add</emphasis>.  A file can be\r
410 reverted back, only in the index but not in the working tree,\r
411 to that of the last commit with <literal>git reset HEAD&#8201;&#8212;&#8201;&lt;file&gt;</literal>,\r
412 which effectively reverts <emphasis>git-add</emphasis> and prevents the changes to\r
413 this file from participating in the next commit.  After building\r
414 the state to be committed incrementally with these commands,\r
415 <literal>git commit</literal> (without any pathname parameter) is used to record what\r
416 has been staged so far.  This is the most basic form of the\r
417 command.  An example:</simpara>\r
418 <literallayout>$ edit hello.c\r
419 $ git rm goodbye.c\r
420 $ git add hello.c\r
421 $ git commit</literallayout>\r
422 <simpara>Instead of staging files after each individual change, you can\r
423 tell <literal>git commit</literal> to notice the changes to the files whose\r
424 contents are tracked in\r
425 your working tree and do corresponding <literal>git add</literal> and <literal>git rm</literal>\r
426 for you.  That is, this example does the same as the earlier\r
427 example if there is no other change in your working tree:</simpara>\r
428 <literallayout>$ edit hello.c\r
429 $ rm goodbye.c\r
430 $ git commit -a</literallayout>\r
431 <simpara>The command <literal>git commit -a</literal> first looks at your working tree,\r
432 notices that you have modified hello.c and removed goodbye.c,\r
433 and performs necessary <literal>git add</literal> and <literal>git rm</literal> for you.</simpara>\r
434 <simpara>After staging changes to many files, you can alter the order the\r
435 changes are recorded in, by giving pathnames to <literal>git commit</literal>.\r
436 When pathnames are given, the command makes a commit that\r
437 only records the changes made to the named paths:</simpara>\r
438 <literallayout>$ edit hello.c hello.h\r
439 $ git add hello.c hello.h\r
440 $ edit Makefile\r
441 $ git commit Makefile</literallayout>\r
442 <simpara>This makes a commit that records the modification to <literal>Makefile</literal>.\r
443 The changes staged for <literal>hello.c</literal> and <literal>hello.h</literal> are not included\r
444 in the resulting commit.  However, their changes are not lost&#8201;&#8212;&#8201;they are still staged and merely held back.  After the above\r
445 sequence, if you do:</simpara>\r
446 <literallayout>$ git commit</literallayout>\r
447 <simpara>this second commit would record the changes to <literal>hello.c</literal> and\r
448 <literal>hello.h</literal> as expected.</simpara>\r
449 <simpara>After a merge (initiated by <emphasis>git-merge</emphasis> or <emphasis>git-pull</emphasis>) stops\r
450 because of conflicts, cleanly merged\r
451 paths are already staged to be committed for you, and paths that\r
452 conflicted are left in unmerged state.  You would have to first\r
453 check which paths are conflicting with <emphasis>git-status</emphasis>\r
454 and after fixing them manually in your working tree, you would\r
455 stage the result as usual with <emphasis>git-add</emphasis>:</simpara>\r
456 <literallayout>$ git status | grep unmerged\r
457 unmerged: hello.c\r
458 $ edit hello.c\r
459 $ git add hello.c</literallayout>\r
460 <simpara>After resolving conflicts and staging the result, <literal>git ls-files -u</literal>\r
461 would stop mentioning the conflicted path.  When you are done,\r
462 run <literal>git commit</literal> to finally record the merge:</simpara>\r
463 <literallayout>$ git commit</literallayout>\r
464 <simpara>As with the case to record your own changes, you can use <literal>-a</literal>\r
465 option to save typing.  One difference is that during a merge\r
466 resolution, you cannot use <literal>git commit</literal> with pathnames to\r
467 alter the order the changes are committed, because the merge\r
468 should be recorded as a single commit.  In fact, the command\r
469 refuses to run when given pathnames (but see <literal>-i</literal> option).</simpara>\r
470 </simplesect>\r
471 <simplesect id="_discussion">\r
472 <title>DISCUSSION</title>\r
473 <simpara>Though not required, it&#8217;s a good idea to begin the commit message\r
474 with a single short (less than 50 character) line summarizing the\r
475 change, followed by a blank line and then a more thorough description.\r
476 Tools that turn commits into email, for example, use the first line\r
477 on the Subject: line and the rest of the commit in the body.</simpara>\r
478 <simpara>At the core level, git is character encoding agnostic.</simpara>\r
479 <itemizedlist>\r
480 <listitem>\r
481 <simpara>\r
482 The pathnames recorded in the index and in the tree objects\r
483    are treated as uninterpreted sequences of non-NUL bytes.\r
484    What readdir(2) returns are what are recorded and compared\r
485    with the data git keeps track of, which in turn are expected\r
486    to be what lstat(2) and creat(2) accepts.  There is no such\r
487    thing as pathname encoding translation.\r
488 </simpara>\r
489 </listitem>\r
490 <listitem>\r
491 <simpara>\r
492 The contents of the blob objects are uninterpreted sequences\r
493    of bytes.  There is no encoding translation at the core\r
494    level.\r
495 </simpara>\r
496 </listitem>\r
497 <listitem>\r
498 <simpara>\r
499 The commit log messages are uninterpreted sequences of non-NUL\r
500    bytes.\r
501 </simpara>\r
502 </listitem>\r
503 </itemizedlist>\r
504 <simpara>Although we encourage that the commit log messages are encoded\r
505 in UTF-8, both the core and git Porcelain are designed not to\r
506 force UTF-8 on projects.  If all participants of a particular\r
507 project find it more convenient to use legacy encodings, git\r
508 does not forbid it.  However, there are a few things to keep in\r
509 mind.</simpara>\r
510 <orderedlist numeration="arabic">\r
511 <listitem>\r
512 <simpara>\r
513 <emphasis>git-commit</emphasis> and <emphasis>git-commit-tree</emphasis> issues\r
514   a warning if the commit log message given to it does not look\r
515   like a valid UTF-8 string, unless you explicitly say your\r
516   project uses a legacy encoding.  The way to say this is to\r
517   have i18n.commitencoding in <literal>.git/config</literal> file, like this:\r
518 </simpara>\r
519 <literallayout>[i18n]\r
520         commitencoding = ISO-8859-1</literallayout>\r
521 <simpara>Commit objects created with the above setting record the value\r
522 of <literal>i18n.commitencoding</literal> in its <literal>encoding</literal> header.  This is to\r
523 help other people who look at them later.  Lack of this header\r
524 implies that the commit log message is encoded in UTF-8.</simpara>\r
525 </listitem>\r
526 <listitem>\r
527 <simpara>\r
528 <emphasis>git-log</emphasis>, <emphasis>git-show</emphasis>, <emphasis>git-blame</emphasis> and friends look at the\r
529   <literal>encoding</literal> header of a commit object, and try to re-code the\r
530   log message into UTF-8 unless otherwise specified.  You can\r
531   specify the desired output encoding with\r
532   <literal>i18n.logoutputencoding</literal> in <literal>.git/config</literal> file, like this:\r
533 </simpara>\r
534 <literallayout>[i18n]\r
535         logoutputencoding = ISO-8859-1</literallayout>\r
536 <simpara>If you do not have this configuration variable, the value of\r
537 <literal>i18n.commitencoding</literal> is used instead.</simpara>\r
538 </listitem>\r
539 </orderedlist>\r
540 <simpara>Note that we deliberately chose not to re-code the commit log\r
541 message when a commit is made to force UTF-8 at the commit\r
542 object level, because re-coding to UTF-8 is not necessarily a\r
543 reversible operation.</simpara>\r
544 </simplesect>\r
545 <simplesect id="_environment_and_configuration_variables">\r
546 <title>ENVIRONMENT AND CONFIGURATION VARIABLES</title>\r
547 <simpara>The editor used to edit the commit log message will be chosen from the\r
548 GIT_EDITOR environment variable, the core.editor configuration variable, the\r
549 VISUAL environment variable, or the EDITOR environment variable (in that\r
550 order).</simpara>\r
551 </simplesect>\r
552 <simplesect id="_hooks">\r
553 <title>HOOKS</title>\r
554 <simpara>This command can run <literal>commit-msg</literal>, <literal>prepare-commit-msg</literal>, <literal>pre-commit</literal>,\r
555 and <literal>post-commit</literal> hooks.  See <xref linkend="githooks(5)"/> for more\r
556 information.</simpara>\r
557 </simplesect>\r
558 <simplesect id="_see_also">\r
559 <title>SEE ALSO</title>\r
560 <simpara><xref linkend="git-add(1)"/>,\r
561 <xref linkend="git-rm(1)"/>,\r
562 <xref linkend="git-mv(1)"/>,\r
563 <xref linkend="git-merge(1)"/>,\r
564 <xref linkend="git-commit-tree(1)"/></simpara>\r
565 </simplesect>\r
566 <simplesect id="_author">\r
567 <title>Author</title>\r
568 <simpara>Written by Linus Torvalds &lt;<ulink url="mailto:torvalds@osdl.org">torvalds@osdl.org</ulink>&gt; and\r
569 Junio C Hamano &lt;<ulink url="mailto:gitster@pobox.com">gitster@pobox.com</ulink>&gt;</simpara>\r
570 </simplesect>\r
571 <simplesect id="_git">\r
572 <title>GIT</title>\r
573 <simpara>Part of the <xref linkend="git(1)"/> suite</simpara>\r
574 </simplesect>\r
575 </article>\r