summaryrefslogtreecommitdiff
path: root/Documentation/git-commit.txt
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/git-commit.txt')
-rw-r--r--Documentation/git-commit.txt262
1 files changed, 262 insertions, 0 deletions
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
new file mode 100644
index 0000000..53a7bb0
--- /dev/null
+++ b/Documentation/git-commit.txt
@@ -0,0 +1,262 @@
+git-commit(1)
+=============
+
+NAME
+----
+git-commit - Record changes to the repository
+
+SYNOPSIS
+--------
+[verse]
+'git-commit' [-a | --interactive] [-s] [-v]
+ [(-c | -C) <commit> | -F <file> | -m <msg> | --amend]
+ [--no-verify] [-e] [--author <author>]
+ [--] [[-i | -o ]<file>...]
+
+DESCRIPTION
+-----------
+Use 'git commit' when you want to record your changes into the repository
+along with a log message describing what the commit is about. All changes
+to be committed must be explicitly identified using one of the following
+methods:
+
+1. by using gitlink:git-add[1] to incrementally "add" changes to the
+ next commit before using the 'commit' command (Note: even modified
+ files must be "added");
+
+2. by using gitlink:git-rm[1] to identify content removal for the next
+ commit, again before using the 'commit' command;
+
+3. by directly listing files containing changes to be committed as arguments
+ to the 'commit' command, in which cases only those files alone will be
+ considered for the commit;
+
+4. by using the -a switch with the 'commit' command to automatically "add"
+ changes from all known files i.e. files that have already been committed
+ before, and to automatically "rm" files that have been
+ removed from the working tree, and perform the actual commit.
+
+5. by using the --interactive switch with the 'commit' command to decide one
+ by one which files should be part of the commit, before finalizing the
+ operation. Currently, this is done by invoking `git-add --interactive`.
+
+The gitlink:git-status[1] command can be used to obtain a
+summary of what is included by any of the above for the next
+commit by giving the same set of parameters you would give to
+this command.
+
+If you make a commit and then found a mistake immediately after
+that, you can recover from it with gitlink:git-reset[1].
+
+
+OPTIONS
+-------
+-a|--all::
+ Tell the command to automatically stage files that have
+ been modified and deleted, but new files you have not
+ told git about are not affected.
+
+-c or -C <commit>::
+ Take existing commit object, and reuse the log message
+ and the authorship information (including the timestamp)
+ when creating the commit. With '-C', the editor is not
+ invoked; with '-c' the user can further edit the commit
+ message.
+
+-F <file>::
+ Take the commit message from the given file. Use '-' to
+ read the message from the standard input.
+
+--author <author>::
+ Override the author name used in the commit. Use
+ `A U Thor <author@example.com>` format.
+
+-m <msg>::
+ Use the given <msg> as the commit message.
+
+-s|--signoff::
+ Add Signed-off-by line at the end of the commit message.
+
+--no-verify::
+ This option bypasses the pre-commit hook.
+ See also link:hooks.html[hooks].
+
+-e|--edit::
+ The message taken from file with `-F`, command line with
+ `-m`, and from file with `-C` are usually used as the
+ commit log message unmodified. This option lets you
+ further edit the message taken from these sources.
+
+--amend::
+
+ Used to amend the tip of the current branch. Prepare the tree
+ object you would want to replace the latest commit as usual
+ (this includes the usual -i/-o and explicit paths), and the
+ commit log editor is seeded with the commit message from the
+ tip of the current branch. The commit you create replaces the
+ current tip -- if it was a merge, it will have the parents of
+ the current tip as parents -- so the current top commit is
+ discarded.
++
+--
+It is a rough equivalent for:
+------
+ $ git reset --soft HEAD^
+ $ ... do something else to come up with the right tree ...
+ $ git commit -c ORIG_HEAD
+
+------
+but can be used to amend a merge commit.
+--
+
+-i|--include::
+ Before making a commit out of staged contents so far,
+ stage the contents of paths given on the command line
+ as well. This is usually not what you want unless you
+ are concluding a conflicted merge.
+
+-q|--quiet::
+ Suppress commit summary message.
+
+\--::
+ Do not interpret any more arguments as options.
+
+<file>...::
+ When files are given on the command line, the command
+ commits the contents of the named files, without
+ recording the changes already staged. The contents of
+ these files are also staged for the next commit on top
+ of what have been staged before.
+
+
+EXAMPLES
+--------
+When recording your own work, the contents of modified files in
+your working tree are temporarily stored to a staging area
+called the "index" with gitlink:git-add[1]. Removal
+of a file is staged with gitlink:git-rm[1]. After building the
+state to be committed incrementally with these commands, `git
+commit` (without any pathname parameter) is used to record what
+has been staged so far. This is the most basic form of the
+command. An example:
+
+------------
+$ edit hello.c
+$ git rm goodbye.c
+$ git add hello.c
+$ git commit
+------------
+
+Instead of staging files after each individual change, you can
+tell `git commit` to notice the changes to the files whose
+contents are tracked in
+your working tree and do corresponding `git add` and `git rm`
+for you. That is, this example does the same as the earlier
+example if there is no other change in your working tree:
+
+------------
+$ edit hello.c
+$ rm goodbye.c
+$ git commit -a
+------------
+
+The command `git commit -a` first looks at your working tree,
+notices that you have modified hello.c and removed goodbye.c,
+and performs necessary `git add` and `git rm` for you.
+
+After staging changes to many files, you can alter the order the
+changes are recorded in, by giving pathnames to `git commit`.
+When pathnames are given, the command makes a commit that
+only records the changes made to the named paths:
+
+------------
+$ edit hello.c hello.h
+$ git add hello.c hello.h
+$ edit Makefile
+$ git commit Makefile
+------------
+
+This makes a commit that records the modification to `Makefile`.
+The changes staged for `hello.c` and `hello.h` are not included
+in the resulting commit. However, their changes are not lost --
+they are still staged and merely held back. After the above
+sequence, if you do:
+
+------------
+$ git commit
+------------
+
+this second commit would record the changes to `hello.c` and
+`hello.h` as expected.
+
+After a merge (initiated by either gitlink:git-merge[1] or
+gitlink:git-pull[1]) stops because of conflicts, cleanly merged
+paths are already staged to be committed for you, and paths that
+conflicted are left in unmerged state. You would have to first
+check which paths are conflicting with gitlink:git-status[1]
+and after fixing them manually in your working tree, you would
+stage the result as usual with gitlink:git-add[1]:
+
+------------
+$ git status | grep unmerged
+unmerged: hello.c
+$ edit hello.c
+$ git add hello.c
+------------
+
+After resolving conflicts and staging the result, `git ls-files -u`
+would stop mentioning the conflicted path. When you are done,
+run `git commit` to finally record the merge:
+
+------------
+$ git commit
+------------
+
+As with the case to record your own changes, you can use `-a`
+option to save typing. One difference is that during a merge
+resolution, you cannot use `git commit` with pathnames to
+alter the order the changes are committed, because the merge
+should be recorded as a single commit. In fact, the command
+refuses to run when given pathnames (but see `-i` option).
+
+
+DISCUSSION
+----------
+
+Though not required, it's a good idea to begin the commit message
+with a single short (less than 50 character) line summarizing the
+change, followed by a blank line and then a more thorough description.
+Tools that turn commits into email, for example, use the first line
+on the Subject: line and the rest of the commit in the body.
+
+include::i18n.txt[]
+
+ENVIRONMENT VARIABLES
+---------------------
+The command specified by either the VISUAL or EDITOR environment
+variables is used to edit the commit log message.
+
+HOOKS
+-----
+This command can run `commit-msg`, `pre-commit`, and
+`post-commit` hooks. See link:hooks.html[hooks] for more
+information.
+
+
+SEE ALSO
+--------
+gitlink:git-add[1],
+gitlink:git-rm[1],
+gitlink:git-mv[1],
+gitlink:git-merge[1],
+gitlink:git-commit-tree[1]
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org> and
+Junio C Hamano <junkio@cox.net>
+
+
+GIT
+---
+Part of the gitlink:git[7] suite