command. If you are completely stuck, simply run “git help”; it will
print a brief list of commonly-used commands, along with a description
of what each does. If you ask for help on a specific command (such as
-"git help init"), it prints more detailed information. [XXX: Does "git
-help \<foo\>" work universally as a built-in or does it expect man to be
-present and just call out to "man git-\<foo\>"?]
+"git help init"), it prints more detailed information. [XXX: Does `git
+help <foo>` work universally as a built-in or does it expect man to be
+present and just call out to `man git-<foo>`?]
[XXX: The original hgbook includes the complete output of "hg
help init" at this point. I'm not including the corresponding
systems.
* Most options have long names. For example, as we’ve already seen,
- the “git log" command accepts a --max-count=\<number\> option.
+ the “git log" command accepts a `--max-count=<number>` option.
* Some options have short, single-character names. Often these are
- aliases for long commands, (such as "-n \<number\>" instead of
- --max-count=\<number\>), but sometimes the option exists in
- short-form with no long-form equivalent, (such as -p). [XXX: It
- wouldn't hurt to fix this by adding --patch, etc. right?]
- * Long options start with two dashes (e.g. --max-count), while short
- options start with one (e.g. -n).
+ aliases for long commands, (such as `-n <number>` instead of
+ `--max-count=<number>`), but sometimes the option exists in
+ short-form with no long-form equivalent, (such as `-p`). [XXX: It
+ wouldn't hurt to fix this by adding `--patch`, etc. right?]
+ * Long options start with two dashes (e.g. `--max-count`), while short
+ options start with one (e.g. `-n`).
* Option naming and usage is consistent across commands. For
example, every command that lets you specify a commit identifier
the author and committer name and email as soon as a value is found):
1. If you specify a --author option to the “git commit” command on
- the command line, followed by a "Real Name \<email@example.com\>"
+ the command line, followed by a `"Real Name <email@example.com>"`
string, then this name and addresss will be used for the author
fields. The committer fields will still be determined as
below. This option is very helpful for when applying a commit
Note: The -a on the command-line instructs git to commit the new
content of *all* tracked files that have been modified. This is a
convenience over explicitly listing filenames to be committed on the
-"git commit" command line. It is useful to use "git commit \<files\>"
+`git commit` command line. It is useful to use `git commit <files>`
when there is a need to commit only some subset of the files that have
been modified.
-If new files need to be committed for the first time, just use "git
-add \<file\>" before "git commit -a". If a file needs to be removed,
-just remove it as normal before committing and "git commit -a" will
+If new files need to be committed for the first time, just use `git
+add <file>` before `git commit -a`. If a file needs to be removed,
+just remove it as normal before committing and `git commit -a` will
notice that---it does not need to be explicitly told about the
removal.
-The editor that the “git commit” command drops us into will contain an
+The editor that the `git commit` command drops us into will contain an
empty line, followed by a number of lines starting with “#”. These
-lines contain the same information as seen in "git status" before:
+lines contain the same information as seen in `git status` before:
empty line
# Please enter the commit message for your changes.