1GIT-COMMIT(1) Git Manual GIT-COMMIT(1)
2
6 git-commit - Record changes to the repository
7
9 git-commit [-a | --interactive] [-s] [-v] [-u]
10 [(-c | -C) <commit> | -F <file> | -m <msg> | --amend]
11 [--no-verify] [-e] [--author <author>]
12 [--] [[-i | -o ]<file>...]
13
15 Use git commit to store the current contents of the index in a new
16 commit along with a log message describing the changes you have made.
17 The content to be added can be specified in several ways:
19 1. by using git-add(1) to incrementally "add" changes to the index
22 before using the commit command (Note: even modified files must be
23 "added");
24 2. by using git-rm(1) to remove files from the working tree and the
26 index, again before using the commit command;
27 3. by listing files as arguments to the commit command, in which case
29 the commit will ignore changes staged in the index, and instead
30 record the current content of the listed files;
31 4. by using the -a switch with the commit command to automatically
33 "add" changes from all known files (i.e. all files that are already
34 listed in the index) and to automatically "rm" files in the index
35 that have been removed from the working tree, and then perform the
36 actual commit;
37 5. by using the --interactive switch with the commit command to
39 decide one by one which files should be part of the commit, before
40 finalizing the operation. Currently, this is done by invoking
41 git-add --interactive.
42 The git-status(1) command can be used to obtain a summary of what is
43 included by any of the above for the next commit by giving the same set
44 of parameters you would give to this command.
45 If you make a commit and then found a mistake immediately after that,
47 you can recover from it with git-reset(1).
48
50 -a|--all
51 Tell the command to automatically stage files that have been
52 modified and deleted, but new files you have not told git about are
53 not affected.
54 -c or -C <commit>
56 Take existing commit object, and reuse the log message and the
57 authorship information (including the timestamp) when creating the
58 commit. With -C, the editor is not invoked; with -c the user can
59 further edit the commit message.
60 -F <file>
62 Take the commit message from the given file. Use - to read the
63 message from the standard input.
64 --author <author>
66 Override the author name used in the commit. Use A U Thor
67 <author@example.com> format.
68 -m <msg>|--message=<msg>
70 Use the given <msg> as the commit message.
71 -t <file>|--template=<file>
73 Use the contents of the given file as the initial version of the
74 commit message. The editor is invoked and you can make subsequent
75 changes. If a message is specified using the -m or -F options, this
76 option has no effect. This overrides the commit.template
77 configuration variable.
78 -s|--signoff
80 Add Signed-off-by line at the end of the commit message.
81 --no-verify
83 This option bypasses the pre-commit hook. See also hooks[1].
84 -e|--edit
86 The message taken from file with -F, command line with -m, and from
87 file with -C are usually used as the commit log message unmodified.
88 This option lets you further edit the message taken from these
89 sources.
90 --amend
92 Used to amend the tip of the current branch. Prepare the tree
93 object you would want to replace the latest commit as usual (this
94 includes the usual -i/-o and explicit paths), and the commit log
95 editor is seeded with the commit message from the tip of the
96 current branch. The commit you create replaces the current tip — if
97 it was a merge, it will have the parents of the current tip as
98 parents — so the current top commit is discarded.
99 It is a rough equivalent for:
101 $ git reset --soft HEAD^
105 $ ... do something else to come up with the right tree ...
106 $ git commit -c ORIG_HEAD
107 but can be used to amend a merge commit.
110 -i|--include
112 Before making a commit out of staged contents so far, stage the
113 contents of paths given on the command line as well. This is
114 usually not what you want unless you are concluding a conflicted
115 merge.
116 -u|--untracked-files
118 Show all untracked files, also those in uninteresting directories,
119 in the "Untracked files:" section of commit message template.
120 Without this option only its name and a trailing slash are
121 displayed for each untracked directory.
122 -v|--verbose
124 Show unified diff between the HEAD commit and what would be
125 committed at the bottom of the commit message template. Note that
126 this diff output doesn´t have its lines prefixed with #.
127 -q|--quiet
129 Suppress commit summary message.
130 --
132 Do not interpret any more arguments as options.
133 <file>...
135 When files are given on the command line, the command commits the
136 contents of the named files, without recording the changes already
137 staged. The contents of these files are also staged for the next
138 commit on top of what have been staged before.
139
141 When recording your own work, the contents of modified files in your
142 working tree are temporarily stored to a staging area called the
143 "index" with git-add(1). Removal of a file is staged with git-rm(1).
144 After building the state to be committed incrementally with these
145 commands, git commit (without any pathname parameter) is used to record
146 what has been staged so far. This is the most basic form of the
147 command. An example:
148 $ edit hello.c
152 $ git rm goodbye.c
153 $ git add hello.c
154 $ git commit
155 Instead of staging files after each individual change, you can tell git
157 commit to notice the changes to the files whose contents are tracked in
158 your working tree and do corresponding git add and git rm for you. That
159 is, this example does the same as the earlier example if there is no
160 other change in your working tree:
161 $ edit hello.c
165 $ rm goodbye.c
166 $ git commit -a
167 The command git commit -a first looks at your working tree, notices
169 that you have modified hello.c and removed goodbye.c, and performs
170 necessary git add and git rm for you.
171 After staging changes to many files, you can alter the order the
173 changes are recorded in, by giving pathnames to git commit. When
174 pathnames are given, the command makes a commit that only records the
175 changes made to the named paths:
176 $ edit hello.c hello.h
180 $ git add hello.c hello.h
181 $ edit Makefile
182 $ git commit Makefile
183 This makes a commit that records the modification to Makefile. The
185 changes staged for hello.c and hello.h are not included in the
186 resulting commit. However, their changes are not lost — they are still
187 staged and merely held back. After the above sequence, if you do:
188 $ git commit
192 this second commit would record the changes to hello.c and hello.h as
194 expected.
195 After a merge (initiated by either git-merge(1) or git-pull(1)) stops
197 because of conflicts, cleanly merged paths are already staged to be
198 committed for you, and paths that conflicted are left in unmerged
199 state. You would have to first check which paths are conflicting with
200 git-status(1) and after fixing them manually in your working tree, you
201 would stage the result as usual with git-add(1):
202 $ git status | grep unmerged
206 unmerged: hello.c
207 $ edit hello.c
208 $ git add hello.c
209 After resolving conflicts and staging the result, git ls-files -u would
211 stop mentioning the conflicted path. When you are done, run git commit
212 to finally record the merge:
213 $ git commit
217 As with the case to record your own changes, you can use -a option to
219 save typing. One difference is that during a merge resolution, you
220 cannot use git commit with pathnames to alter the order the changes are
221 committed, because the merge should be recorded as a single commit. In
222 fact, the command refuses to run when given pathnames (but see -i
223 option).
224
226 Though not required, it´s a good idea to begin the commit message with
227 a single short (less than 50 character) line summarizing the change,
228 followed by a blank line and then a more thorough description. Tools
229 that turn commits into email, for example, use the first line on the
230 Subject: line and the rest of the commit in the body.
231 At the core level, git is character encoding agnostic.
233 · The pathnames recorded in the index and in the tree objects are
236 treated as uninterpreted sequences of non-NUL bytes. What
237 readdir(2) returns are what are recorded and compared with the data
238 git keeps track of, which in turn are expected to be what lstat(2)
239 and creat(2) accepts. There is no such thing as pathname encoding
240 translation.
241 · The contents of the blob objects are uninterpreted sequence of
243 bytes. There is no encoding translation at the core level.
244 · The commit log messages are uninterpreted sequence of non-NUL
246 bytes.
247 Although we encourage that the commit log messages are encoded in
248 UTF-8, both the core and git Porcelain are designed not to force UTF-8
249 on projects. If all participants of a particular project find it more
250 convenient to use legacy encodings, git does not forbid it. However,
251 there are a few things to keep in mind.
252 1. git-commit-tree (hence, git-commit which uses it) issues an
255 warning if the commit log message given to it does not look like a
256 valid UTF-8 string, unless you explicitly say your project uses a
257 legacy encoding. The way to say this is to have i18n.commitencoding
258 in .git/config file, like this:
259 [i18n]
263 commitencoding = ISO-8859-1
264 Commit objects created with the above setting record the value of
266 i18n.commitencoding in its encoding header. This is to help other
267 people who look at them later. Lack of this header implies that the
268 commit log message is encoded in UTF-8.
269 2. git-log, git-show and friends looks at the encoding header of a
271 commit object, and tries to re-code the log message into UTF-8
272 unless otherwise specified. You can specify the desired output
273 encoding with i18n.logoutputencoding in .git/config file, like
274 this:
275 [i18n]
279 logoutputencoding = ISO-8859-1
280 If you do not have this configuration variable, the value of
282 i18n.commitencoding is used instead.
283 Note that we deliberately chose not to re-code the commit log message
284 when a commit is made to force UTF-8 at the commit object level,
285 because re-coding to UTF-8 is not necessarily a reversible operation.
286
288 The editor used to edit the commit log message will be chosen from the
289 GIT_EDITOR environment variable, the core.editor configuration
290 variable, the VISUAL environment variable, or the EDITOR environment
291 variable (in that order).
292
294 This command can run commit-msg, pre-commit, and post-commit hooks. See
295 hooks[1] for more information.
296
298 git-add(1), git-rm(1), git-mv(1), git-merge(1), git-commit-tree(1)
299
301 Written by Linus Torvalds <torvalds@osdl.org> and Junio C Hamano
302 <junkio@cox.net>
303
305 Part of the git(7) suite
306
308 1. hooks
309 hooks.html
310Git 1.5.3.3 10/09/2007 GIT-COMMIT(1)