white space fixes in setup.c
[git/mingw/4msysgit/wingit-dll.git] / Documentation / git-commit.txt
blob627994eb9727379183c40dde786b80c53d3e2af3
1 git-commit(1)
2 =============
4 NAME
5 ----
6 git-commit - Record changes to the repository
8 SYNOPSIS
9 --------
10 [verse]
11 'git-commit' [-a | --interactive] [-s] [-v] [-u]
12            [(-c | -C) <commit> | -F <file> | -m <msg> | --amend]
13            [--no-verify] [-e] [--author <author>]
14            [--] [[-i | -o ]<file>...]
16 DESCRIPTION
17 -----------
18 Use 'git commit' when you want to record your changes into the repository
19 along with a log message describing what the commit is about. All changes
20 to be committed must be explicitly identified using one of the following
21 methods:
23 1. by using gitlink:git-add[1] to incrementally "add" changes to the
24    next commit before using the 'commit' command (Note: even modified
25    files must be "added");
27 2. by using gitlink:git-rm[1] to identify content removal for the next
28    commit, again before using the 'commit' command;
30 3. by directly listing files containing changes to be committed as arguments
31    to the 'commit' command, in which cases only those files alone will be
32    considered for the commit;
34 4. by using the -a switch with the 'commit' command to automatically "add"
35    changes from all known files i.e. files that have already been committed
36    before, and to automatically "rm" files that have been
37    removed from the working tree, and perform the actual commit.
39 5. by using the --interactive switch with the 'commit' command to decide one
40    by one which files should be part of the commit, before finalizing the
41    operation.  Currently, this is done by invoking `git-add --interactive`.
43 The gitlink:git-status[1] command can be used to obtain a
44 summary of what is included by any of the above for the next
45 commit by giving the same set of parameters you would give to
46 this command.
48 If you make a commit and then found a mistake immediately after
49 that, you can recover from it with gitlink:git-reset[1].
52 OPTIONS
53 -------
54 -a|--all::
55         Tell the command to automatically stage files that have
56         been modified and deleted, but new files you have not
57         told git about are not affected.
59 -c or -C <commit>::
60         Take existing commit object, and reuse the log message
61         and the authorship information (including the timestamp)
62         when creating the commit.  With '-C', the editor is not
63         invoked; with '-c' the user can further edit the commit
64         message.
66 -F <file>::
67         Take the commit message from the given file.  Use '-' to
68         read the message from the standard input.
70 --author <author>::
71         Override the author name used in the commit.  Use
72         `A U Thor <author@example.com>` format.
74 -m <msg>|--message=<msg>::
75         Use the given <msg> as the commit message.
77 -t <file>|--template=<file>::
78         Use the contents of the given file as the initial version
79         of the commit message. The editor is invoked and you can
80         make subsequent changes. If a message is specified using
81         the `-m` or `-F` options, this option has no effect. This
82         overrides the `commit.template` configuration variable.
84 -s|--signoff::
85         Add Signed-off-by line at the end of the commit message.
87 --no-verify::
88         This option bypasses the pre-commit hook.
89         See also link:hooks.html[hooks].
91 -e|--edit::
92         The message taken from file with `-F`, command line with
93         `-m`, and from file with `-C` are usually used as the
94         commit log message unmodified.  This option lets you
95         further edit the message taken from these sources.
97 --amend::
99         Used to amend the tip of the current branch. Prepare the tree
100         object you would want to replace the latest commit as usual
101         (this includes the usual -i/-o and explicit paths), and the
102         commit log editor is seeded with the commit message from the
103         tip of the current branch. The commit you create replaces the
104         current tip -- if it was a merge, it will have the parents of
105         the current tip as parents -- so the current top commit is
106         discarded.
109 It is a rough equivalent for:
110 ------
111         $ git reset --soft HEAD^
112         $ ... do something else to come up with the right tree ...
113         $ git commit -c ORIG_HEAD
115 ------
116 but can be used to amend a merge commit.
119 -i|--include::
120         Before making a commit out of staged contents so far,
121         stage the contents of paths given on the command line
122         as well.  This is usually not what you want unless you
123         are concluding a conflicted merge.
125 -u|--untracked-files::
126         Show all untracked files, also those in uninteresting
127         directories, in the "Untracked files:" section of commit
128         message template.  Without this option only its name and
129         a trailing slash are displayed for each untracked
130         directory.
132 -v|--verbose::
133         Show unified diff between the HEAD commit and what
134         would be committed at the bottom of the commit message
135         template.  Note that this diff output doesn't have its
136         lines prefixed with '#'.
138 -q|--quiet::
139         Suppress commit summary message.
141 \--::
142         Do not interpret any more arguments as options.
144 <file>...::
145         When files are given on the command line, the command
146         commits the contents of the named files, without
147         recording the changes already staged.  The contents of
148         these files are also staged for the next commit on top
149         of what have been staged before.
152 EXAMPLES
153 --------
154 When recording your own work, the contents of modified files in
155 your working tree are temporarily stored to a staging area
156 called the "index" with gitlink:git-add[1].  Removal
157 of a file is staged with gitlink:git-rm[1].  After building the
158 state to be committed incrementally with these commands, `git
159 commit` (without any pathname parameter) is used to record what
160 has been staged so far.  This is the most basic form of the
161 command.  An example:
163 ------------
164 $ edit hello.c
165 $ git rm goodbye.c
166 $ git add hello.c
167 $ git commit
168 ------------
170 Instead of staging files after each individual change, you can
171 tell `git commit` to notice the changes to the files whose
172 contents are tracked in
173 your working tree and do corresponding `git add` and `git rm`
174 for you.  That is, this example does the same as the earlier
175 example if there is no other change in your working tree:
177 ------------
178 $ edit hello.c
179 $ rm goodbye.c
180 $ git commit -a
181 ------------
183 The command `git commit -a` first looks at your working tree,
184 notices that you have modified hello.c and removed goodbye.c,
185 and performs necessary `git add` and `git rm` for you.
187 After staging changes to many files, you can alter the order the
188 changes are recorded in, by giving pathnames to `git commit`.
189 When pathnames are given, the command makes a commit that
190 only records the changes made to the named paths:
192 ------------
193 $ edit hello.c hello.h
194 $ git add hello.c hello.h
195 $ edit Makefile
196 $ git commit Makefile
197 ------------
199 This makes a commit that records the modification to `Makefile`.
200 The changes staged for `hello.c` and `hello.h` are not included
201 in the resulting commit.  However, their changes are not lost --
202 they are still staged and merely held back.  After the above
203 sequence, if you do:
205 ------------
206 $ git commit
207 ------------
209 this second commit would record the changes to `hello.c` and
210 `hello.h` as expected.
212 After a merge (initiated by either gitlink:git-merge[1] or
213 gitlink:git-pull[1]) stops because of conflicts, cleanly merged
214 paths are already staged to be committed for you, and paths that
215 conflicted are left in unmerged state.  You would have to first
216 check which paths are conflicting with gitlink:git-status[1]
217 and after fixing them manually in your working tree, you would
218 stage the result as usual with gitlink:git-add[1]:
220 ------------
221 $ git status | grep unmerged
222 unmerged: hello.c
223 $ edit hello.c
224 $ git add hello.c
225 ------------
227 After resolving conflicts and staging the result, `git ls-files -u`
228 would stop mentioning the conflicted path.  When you are done,
229 run `git commit` to finally record the merge:
231 ------------
232 $ git commit
233 ------------
235 As with the case to record your own changes, you can use `-a`
236 option to save typing.  One difference is that during a merge
237 resolution, you cannot use `git commit` with pathnames to
238 alter the order the changes are committed, because the merge
239 should be recorded as a single commit.  In fact, the command
240 refuses to run when given pathnames (but see `-i` option).
243 DISCUSSION
244 ----------
246 Though not required, it's a good idea to begin the commit message
247 with a single short (less than 50 character) line summarizing the
248 change, followed by a blank line and then a more thorough description.
249 Tools that turn commits into email, for example, use the first line
250 on the Subject: line and the rest of the commit in the body.
252 include::i18n.txt[]
254 ENVIRONMENT AND CONFIGURATION VARIABLES
255 ---------------------------------------
256 The editor used to edit the commit log message will be chosen from the
257 GIT_EDITOR environment variable, the core.editor configuration variable, the
258 VISUAL environment variable, or the EDITOR environment variable (in that
259 order).
261 HOOKS
262 -----
263 This command can run `commit-msg`, `pre-commit`, and
264 `post-commit` hooks.  See link:hooks.html[hooks] for more
265 information.
268 SEE ALSO
269 --------
270 gitlink:git-add[1],
271 gitlink:git-rm[1],
272 gitlink:git-mv[1],
273 gitlink:git-merge[1],
274 gitlink:git-commit-tree[1]
276 Author
277 ------
278 Written by Linus Torvalds <torvalds@osdl.org> and
279 Junio C Hamano <junkio@cox.net>
284 Part of the gitlink:git[7] suite