The content to be added can be specified in several ways:
-1. by using `git-add` to incrementally "add" changes to the
+1. by using 'git-add' to incrementally "add" changes to the
index before using the 'commit' command (Note: even modified
files must be "added");
-2. by using `git-rm` to remove files from the working tree
+2. by using 'git-rm' 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, in which
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`.
+ operation. Currently, this is done by invoking 'git-add --interactive'.
-The `git-status` command can be used to obtain a
+The 'git-status' 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 find a mistake immediately after
-that, you can recover from it with `git-reset`.
+that, you can recover from it with 'git-reset'.
OPTIONS
Make a commit only from the paths specified on the
command line, disregarding any contents that have been
staged so far. This is the default mode of operation of
- 'git commit' if any paths are given on the command line,
+ 'git-commit' if any paths are given on the command line,
in which case this option can be omitted.
If this option is specified together with '--amend', then
no paths need be specified, which can be used to amend
--------
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 `git-add`. A file can be
+called the "index" with 'git-add'. A file can be
reverted back, only in the index but not in the working tree,
to that of the last commit with `git reset HEAD -- <file>`,
-which effectively reverts `git-add` and prevents the changes to
+which effectively reverts 'git-add' and prevents the changes to
this file from participating in the next commit. After building
the state to be committed incrementally with these commands,
`git commit` (without any pathname parameter) is used to record what
this second commit would record the changes to `hello.c` and
`hello.h` as expected.
-After a merge (initiated by `git-merge` or `git-pull`) stops
+After a merge (initiated by 'git-merge' or 'git-pull') 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 `git-status`
+check which paths are conflicting with 'git-status'
and after fixing them manually in your working tree, you would
-stage the result as usual with `git-add`:
+stage the result as usual with 'git-add':
------------
$ git status | grep unmerged
Author
------
Written by Linus Torvalds <torvalds@osdl.org> and
-Junio C Hamano <junkio@cox.net>
+Junio C Hamano <gitster@pobox.com>
GIT