git-commit(1)
=============

NAME
----
git-commit - Record changes to the repository

SYNOPSIS
--------
[synopsis]
git commit [-a | --interactive | --patch] [-s] [-v] [-u[<mode>]] [--amend]
	   [--dry-run] [(-c | -C | --squash) <commit> | --fixup [(amend|reword):]<commit>]
	   [-F <file> | -m <msg>] [--reset-author] [--allow-empty]
	   [--allow-empty-message] [--no-verify] [-e] [--author=<author>]
	   [--date=<date>] [--cleanup=<mode>] [--[no-]status]
	   [-i | -o] [--pathspec-from-file=<file> [--pathspec-file-nul]]
	   [(--trailer <token>[(=|:)<value>])...] [-S[<keyid>]]
	   [--] [<pathspec>...]

DESCRIPTION
-----------
Create a new commit containing the current contents of the index and
the given log message describing the changes. The new commit is a
direct child of HEAD, usually the tip of the current branch, and the
branch is updated to point to it (unless no branch is associated with
the working tree, in which case `HEAD` is "detached" as described in
linkgit:git-checkout[1]).

The content to be committed can be specified in several ways:

1. by using linkgit:git-add[1] to incrementally "add" changes to the
   index before using the `commit` command (Note: even modified files
   must be "added");

2. by using linkgit:git-rm[1] to remove files from the working tree
   and the index, again before using the `commit` command;

3. by listing files as arguments to the `commit` command
   (without `--interactive` or `--patch` switch), in which
   case the commit will ignore changes staged in the index, and instead
   record the current content of the listed files (which must already
   be known to Git);

4. by using the `-a` switch with the `commit` command to automatically
   "add" changes from all known files (i.e. all files that are already
   listed in the index) and to automatically "rm" files in the index
   that have been removed from the working tree, and then perform the
   actual commit;

5. by using the `--interactive` or `--patch` switches with the `commit` command
   to decide one by one which files or hunks should be part of the commit
   in addition to contents in the index,
   before finalizing the operation. See the ``Interactive Mode'' section of
   linkgit:git-add[1] to learn how to operate these modes.

The `--dry-run` option 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 (options and paths).

If you make a commit and then find a mistake immediately after
that, you can recover from it with `git reset`.

:git-commit: 1

OPTIONS
-------
`-a`::
`--all`::
	Automatically stage files that have
	been modified and deleted, but new files you have not
	told Git about are not affected.

`-p`::
`--patch`::
	Use the interactive patch selection interface to choose
	which changes to commit. See linkgit:git-add[1] for
	details.

`-C <commit>`::
`--reuse-message=<commit>`::
	Take an existing _<commit>_ object, and reuse the log message
	and the authorship information (including the timestamp)
	when creating the commit.

`-c <commit>`::
`--reedit-message=<commit>`::
	Like `-C`, but with `-c` the editor is invoked, so that
	the user can further edit the commit message.

`--fixup=[(amend|reword):]<commit>`::
	Create a new commit which "fixes up" _<commit>_ when applied with
	`git rebase --autosquash`. Plain `--fixup=<commit>` creates a
	"fixup!" commit which changes the content of _<commit>_ but leaves
	its log message untouched. `--fixup=amend:<commit>` is similar but
	creates an "amend!" commit which also replaces the log message of
	_<commit>_ with the log message of the "amend!" commit.
	`--fixup=reword:<commit>` creates an "amend!" commit which
	replaces the log message of _<commit>_ with its own log message
	but makes no changes to the content of _<commit>_.
+
The commit created by plain `--fixup=<commit>` has a title
composed of "fixup!" followed by the title of _<commit>_,
and is recognized specially by `git rebase --autosquash`. The `-m`
option