Git is simple to use. Just type git. Without any arguments, Git lists its options and the most common subcommands:

$ git

git [--version] [--exec-path[=GIT_EXEC_PATH]]
    [-p|--paginate|--no-pager] [--bare] [--git-dir=GIT_DIR]
    [--work-tree=GIT_WORK_TREE] [--help] COMMAND [ARGS]

The most commonly used git commands are:
   add        Add file contents to the index
   bisect     Find the change that introduced a bug by binary search
   branch     List, create, or delete branches
   checkout   Checkout and switch to a branch
   clone      Clone a repository into a new directory
   commit     Record changes to the repository
   diff       Show changes between commits, the commit and working trees, etc.
   fetch      Download objects and refs from another repository
   grep       Print lines matching a pattern
   init       Create an empty git repository or reinitialize an existing one
   log        Show commit logs
   merge      Join two or more development histories
   mv         Move or rename a file, a directory, or a symlink
   pull       Fetch from and merge with another repository or a local branch
   push       Update remote refs along with associated objects
   rebase     Forward-port local commits to the updated upstream head
   reset      Reset current HEAD to the specified state
   rm         Remove files from the working tree and from the index
   show       Show various types of objects
   status     Show the working tree status
   tag        Create, list, delete, or verify a tag object signed with GPG

For a complete (and somewhat daunting) list of git subcommands, type git help --all.

As you can see from the usage hint, a small handful of options apply to git. Most options, shown as [ARGS] in the hint, apply to specific subcommands.

For example, the option --version affects the git command and produces a version number:

$ git --version
git version 1.6.0

In contrast, --amend is an example of an option specific to the git subcommand commit:

$ git commit --amend

Some invocations require both forms of options (here, the extra spaces in the command line merely serve to visually separate the subcommand from the base command and are not required):

$ git --git-dir=project.git    repack -d

For convenience, documentation for each git subcommand is available using either git help subcommand or git subcommand --help.

Historically, Git was provided as a suite of many simple, distinct, standalone commands developed according to the “Unix toolkit” philosophy: build small, interoperable tools. Each command sported a hyphenated name, such as git-commit and git-log. However, the current trend among developers is to use the single git executable and affix a subcommand. That said, both forms, git commit and git-commit, are identical.

Git commands understand both “short” and “long” options. For example, the git commit command treats the following examples as equivalents:

$ git commit -m "Fixed a typo."
$ git commit --message="Fixed a typo."

The short form, -m, uses a single hyphen, whereas the long form, --message, uses two. (This is consistent with the GNU long options extension.) Some options exist only in one form.

Finally, you can separate options from a list of arguments via the “bare double dash” convention. For instance, use the double dash to contrast the control portion of the command line from a list of operands, such as filenames:

$ git diff -w master origin -- tools/Makefile

You may need to use the double dash to separate and explicitly identify filenames if they might otherwise be mistaken for another part of the command. For example, if you happened to have both a file and a tag named main.c, you would get different behavior:

# Checkout the tag named "main.c"
$ git checkout main.c

# Checkout the file named "main.c"
$ git checkout -- main.c