Miscellaneous notes on git commit, using the Linux kernel source as an example.

git commit [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend]
           [--dry-run] [(-c | -C | --fixup | --squash) <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] [-S[<keyid>]] [--] [<file>...]

See which files are staged for committing:

$ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	modified:   MAINTAINERS
	modified:   README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   Makefile
$

To see the entire difference about to be committed:

$ git diff --cached                            [or --staged]
diff --git a/MAINTAINERS b/MAINTAINERS
index 41ce5f4ad838..202d67e2facb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1,4 +1,4 @@
-
+New stuff in MAINTAINERS
 
        List of maintainers and how to submit kernel changes
 
diff --git a/README b/README
index 669ac7c32292..3db2a5b35089 100644
--- a/README
+++ b/README
@@ -1,3 +1,5 @@
+New stuff in README
+
 Linux kernel
 ============
 

For a histogram-style summary, add --stat:

$ git diff --cached --stat
 MAINTAINERS | 2 +-
 README      | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)
$

-m <msg>, --message=<msg>
    Use the given <msg> as the commit message. If multiple -m
    options are given, their values are concatenated as
    separate paragraphs.

    The -m option is mutually exclusive with -c, -C, and -F.

Note how this option accommodates both the modifications and deletions of tracked files:

-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.

You can define a more informative commit template message, say in a personal ~/.gitmessage.txt file:

Subject line (try to keep under 60 characters)

Multi-line description of commit,
feel free to be detailed.

[Ticket: X]

and have it used in one of two ways when committing.

First, manually at the command line:

-t <file>, --template=<file>
    When editing the commit message, start the editor with the
    contents in the given file. The commit.template
    configuration variable is often used to give this option
    implicitly to the command. This mechanism can be used by
    projects that want to guide participants with some hints on
    what to write in the message in what order. If the user
    exits the editor without editing the message, the commit is
    aborted. This has no effect when a message is given by
    other means, e.g. with the -m or -F options.

As a second option, set it once as a configuration setting:

$ git config --global commit.template ~/.gitmessage.txt