6 git-commit - Record changes to the repository
11 'git-commit' [-a | --interactive] [-s] [-v]
12 [(-c | -C) <commit> | -F <file> | -m <msg> | --amend]
13 [--no-verify] [-e] [--author <author>]
14 [--] [[-i | -o ]<file>...]
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
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
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].
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.
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
67 Take the commit message from the given file. Use '-' to
68 read the message from the standard input.
71 Override the author name used in the commit. Use
72 `A U Thor <author@example.com>` format.
75 Use the given <msg> as the commit message.
78 Add Signed-off-by line at the end of the commit message.
81 This option bypasses the pre-commit hook.
82 See also link:hooks.html[hooks].
85 The message taken from file with `-F`, command line with
86 `-m`, and from file with `-C` are usually used as the
87 commit log message unmodified. This option lets you
88 further edit the message taken from these sources.
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
94 (this includes the usual -i/-o and explicit paths), and the
95 commit log editor is seeded with the commit message from the
96 tip of the current branch. The commit you create replaces the
97 current tip -- if it was a merge, it will have the parents of
98 the current tip as parents -- so the current top commit is
102 It is a rough equivalent for:
104 $ git reset --soft HEAD^
105 $ ... do something else to come up with the right tree ...
106 $ git commit -c ORIG_HEAD
109 but can be used to amend a merge commit.
113 Before making a commit out of staged contents so far,
114 stage the contents of paths given on the command line
115 as well. This is usually not what you want unless you
116 are concluding a conflicted merge.
119 Suppress commit summary message.
122 Do not interpret any more arguments as options.
125 When files are given on the command line, the command
126 commits the contents of the named files, without
127 recording the changes already staged. The contents of
128 these files are also staged for the next commit on top
129 of what have been staged before.
134 When recording your own work, the contents of modified files in
135 your working tree are temporarily stored to a staging area
136 called the "index" with gitlink:git-add[1]. Removal
137 of a file is staged with gitlink:git-rm[1]. After building the
138 state to be committed incrementally with these commands, `git
139 commit` (without any pathname parameter) is used to record what
140 has been staged so far. This is the most basic form of the
150 Instead of staging files after each individual change, you can
151 tell `git commit` to notice the changes to the files whose
152 contents are tracked in
153 your working tree and do corresponding `git add` and `git rm`
154 for you. That is, this example does the same as the earlier
155 example if there is no other change in your working tree:
163 The command `git commit -a` first looks at your working tree,
164 notices that you have modified hello.c and removed goodbye.c,
165 and performs necessary `git add` and `git rm` for you.
167 After staging changes to many files, you can alter the order the
168 changes are recorded in, by giving pathnames to `git commit`.
169 When pathnames are given, the command makes a commit that
170 only records the changes made to the named paths:
173 $ edit hello.c hello.h
174 $ git add hello.c hello.h
176 $ git commit Makefile
179 This makes a commit that records the modification to `Makefile`.
180 The changes staged for `hello.c` and `hello.h` are not included
181 in the resulting commit. However, their changes are not lost --
182 they are still staged and merely held back. After the above
189 this second commit would record the changes to `hello.c` and
190 `hello.h` as expected.
192 After a merge (initiated by either gitlink:git-merge[1] or
193 gitlink:git-pull[1]) stops because of conflicts, cleanly merged
194 paths are already staged to be committed for you, and paths that
195 conflicted are left in unmerged state. You would have to first
196 check which paths are conflicting with gitlink:git-status[1]
197 and after fixing them manually in your working tree, you would
198 stage the result as usual with gitlink:git-add[1]:
201 $ git status | grep unmerged
207 After resolving conflicts and staging the result, `git ls-files -u`
208 would stop mentioning the conflicted path. When you are done,
209 run `git commit` to finally record the merge:
215 As with the case to record your own changes, you can use `-a`
216 option to save typing. One difference is that during a merge
217 resolution, you cannot use `git commit` with pathnames to
218 alter the order the changes are committed, because the merge
219 should be recorded as a single commit. In fact, the command
220 refuses to run when given pathnames (but see `-i` option).
226 Though not required, it's a good idea to begin the commit message
227 with a single short (less than 50 character) line summarizing the
228 change, followed by a blank line and then a more thorough description.
229 Tools that turn commits into email, for example, use the first line
230 on the Subject: line and the rest of the commit in the body.
234 ENVIRONMENT VARIABLES
235 ---------------------
236 The command specified by either the VISUAL or EDITOR environment
237 variables is used to edit the commit log message.
241 This command can run `commit-msg`, `pre-commit`, and
242 `post-commit` hooks. See link:hooks.html[hooks] for more
251 gitlink:git-merge[1],
252 gitlink:git-commit-tree[1]
256 Written by Linus Torvalds <torvalds@osdl.org> and
257 Junio C Hamano <junkio@cox.net>
262 Part of the gitlink:git[7] suite
projects / git / blob