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] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg>]
12 [--no-verify] [--amend] [-e] [--author <author>]
13 [--] [[-i | -o ]<file>...]
15 DESCRIPTION
16 -----------
17 Use 'git commit' when you want to record your changes into the repository
18 along with a log message describing what the commit is about. All changes
19 to be committed must be explicitly identified using one of the following
20 methods:
22 1. by using gitlink:git-add[1] to incrementally "add" changes to the
23 next commit before using the 'commit' command (Note: even modified
24 files must be "added");
26 2. by using gitlink:git-rm[1] to identify content removal for the next
27 commit, again before using the 'commit' command;
29 3. by directly listing files containing changes to be committed as arguments
30 to the 'commit' command, in which cases only those files alone will be
31 considered for the commit;
33 4. by using the -a switch with the 'commit' command to automatically "add"
34 changes from all known files i.e. files that have already been committed
35 before, and to automatically "rm" files that have been
36 removed from the working tree, and perform the actual commit.
38 The gitlink:git-status[1] command can be used to obtain a
39 summary of what is included by any of the above for the next
40 commit by giving the same set of parameters you would give to
41 this command.
43 If you make a commit and then found a mistake immediately after
44 that, you can recover from it with gitlink:git-reset[1].
47 OPTIONS
48 -------
49 -a|--all::
50 Tell the command to automatically stage files that have
51 been modified and deleted, but new files you have not
52 told git about are not affected.
54 -c or -C <commit>::
55 Take existing commit object, and reuse the log message
56 and the authorship information (including the timestamp)
57 when creating the commit. With '-C', the editor is not
58 invoked; with '-c' the user can further edit the commit
59 message.
61 -F <file>::
62 Take the commit message from the given file. Use '-' to
63 read the message from the standard input.
65 --author <author>::
66 Override the author name used in the commit. Use
67 `A U Thor <author@example.com>` format.
69 -m <msg>::
70 Use the given <msg> as the commit message.
72 -s|--signoff::
73 Add Signed-off-by line at the end of the commit message.
75 --no-verify::
76 This option bypasses the pre-commit hook.
77 See also link:hooks.html[hooks].
79 -e|--edit::
80 The message taken from file with `-F`, command line with
81 `-m`, and from file with `-C` are usually used as the
82 commit log message unmodified. This option lets you
83 further edit the message taken from these sources.
85 --amend::
87 Used to amend the tip of the current branch. Prepare the tree
88 object you would want to replace the latest commit as usual
89 (this includes the usual -i/-o and explicit paths), and the
90 commit log editor is seeded with the commit message from the
91 tip of the current branch. The commit you create replaces the
92 current tip -- if it was a merge, it will have the parents of
93 the current tip as parents -- so the current top commit is
94 discarded.
95 +
96 --
97 It is a rough equivalent for:
98 ------
99 $ git reset --soft HEAD^
100 $ ... do something else to come up with the right tree ...
101 $ git commit -c ORIG_HEAD
103 ------
104 but can be used to amend a merge commit.
105 --
107 -i|--include::
108 Before making a commit out of staged contents so far,
109 stage the contents of paths given on the command line
110 as well. This is usually not what you want unless you
111 are concluding a conflicted merge.
113 -q|--quiet::
114 Suppress commit summary message.
116 \--::
117 Do not interpret any more arguments as options.
119 <file>...::
120 When files are given on the command line, the command
121 commits the contents of the named files, without
122 recording the changes already staged. The contents of
123 these files are also staged for the next commit on top
124 of what have been staged before.
127 EXAMPLES
128 --------
129 When recording your own work, the contents of modified files in
130 your working tree are temporarily stored to a staging area
131 called the "index" with gitlink:git-add[1]. Removal
132 of a file is staged with gitlink:git-rm[1]. After building the
133 state to be committed incrementally with these commands, `git
134 commit` (without any pathname parameter) is used to record what
135 has been staged so far. This is the most basic form of the
136 command. An example:
138 ------------
139 $ edit hello.c
140 $ git rm goodbye.c
141 $ git add hello.c
142 $ git commit
143 ------------
145 Instead of staging files after each individual change, you can
146 tell `git commit` to notice the changes to the files whose
147 contents are tracked in
148 your working tree and do corresponding `git add` and `git rm`
149 for you. That is, this example does the same as the earlier
150 example if there is no other change in your working tree:
152 ------------
153 $ edit hello.c
154 $ rm goodbye.c
155 $ git commit -a
156 ------------
158 The command `git commit -a` first looks at your working tree,
159 notices that you have modified hello.c and removed goodbye.c,
160 and performs necessary `git add` and `git rm` for you.
162 After staging changes to many files, you can alter the order the
163 changes are recorded in, by giving pathnames to `git commit`.
164 When pathnames are given, the command makes a commit that
165 only records the changes made to the named paths:
167 ------------
168 $ edit hello.c hello.h
169 $ git add hello.c hello.h
170 $ edit Makefile
171 $ git commit Makefile
172 ------------
174 This makes a commit that records the modification to `Makefile`.
175 The changes staged for `hello.c` and `hello.h` are not included
176 in the resulting commit. However, their changes are not lost --
177 they are still staged and merely held back. After the above
178 sequence, if you do:
180 ------------
181 $ git commit
182 ------------
184 this second commit would record the changes to `hello.c` and
185 `hello.h` as expected.
187 After a merge (initiated by either gitlink:git-merge[1] or
188 gitlink:git-pull[1]) stops because of conflicts, cleanly merged
189 paths are already staged to be committed for you, and paths that
190 conflicted are left in unmerged state. You would have to first
191 check which paths are conflicting with gitlink:git-status[1]
192 and after fixing them manually in your working tree, you would
193 stage the result as usual with gitlink:git-add[1]:
195 ------------
196 $ git status | grep unmerged
197 unmerged: hello.c
198 $ edit hello.c
199 $ git add hello.c
200 ------------
202 After resolving conflicts and staging the result, `git ls-files -u`
203 would stop mentioning the conflicted path. When you are done,
204 run `git commit` to finally record the merge:
206 ------------
207 $ git commit
208 ------------
210 As with the case to record your own changes, you can use `-a`
211 option to save typing. One difference is that during a merge
212 resolution, you cannot use `git commit` with pathnames to
213 alter the order the changes are committed, because the merge
214 should be recorded as a single commit. In fact, the command
215 refuses to run when given pathnames (but see `-i` option).
218 DISCUSSION
219 ----------
221 Though not required, it's a good idea to begin the commit message
222 with a single short (less than 50 character) line summarizing the
223 change, followed by a blank line and then a more thorough description.
224 Tools that turn commits into email, for example, use the first line
225 on the Subject: line and the rest of the commit in the body.
227 include::i18n.txt[]
229 ENVIRONMENT VARIABLES
230 ---------------------
231 The command specified by either the VISUAL or EDITOR environment
232 variables is used to edit the commit log message.
234 HOOKS
235 -----
236 This command can run `commit-msg`, `pre-commit`, and
237 `post-commit` hooks. See link:hooks.html[hooks] for more
238 information.
241 SEE ALSO
242 --------
243 gitlink:git-add[1],
244 gitlink:git-rm[1],
245 gitlink:git-mv[1],
246 gitlink:git-merge[1],
247 gitlink:git-commit-tree[1]
249 Author
250 ------
251 Written by Linus Torvalds <torvalds@osdl.org> and
252 Junio C Hamano <junkio@cox.net>
255 GIT
256 ---
257 Part of the gitlink:git[7] suite