It is a good starting point, but "generally" needs to be emphasized. For utility commands it is always a good idea to read the
man utility page for what is correct syntax.
There is a guideline at The Open Group that can be worth a read. However there is varying level of how conforming implementations are. Some implementations allow one to break this convention, but one should try to heed it as it is both safer and usually more portable (for the day you are on another system with a different implementation.)
When you look at
git and quite a few other tools that is not part of the standard utility package one has to learn the way it is done. The use of command is not unique to
git but also found in others like
amixer etc. As pointed out by @mouviciel this command-based design of git is used by most SCM tools, starting with the old
program [options] [command] [arguments]
options are geared towards the
program itself, and
arguments towards the
It is a nice way to divide an extended a subset for a main program/suite/tool-kit working within a domain.
domain -verbose DO_THIS -with_file filename.txt
domain -verbose DO_THAT -with_file filename.txt
For some it is also given as a short option and by that adhere to the guidelines like e.g.
fdisk -l <device>Enter vs.
When you execute e.g.
git config ... it is not the shell, but
that interpret that
config is the command. The use of
git-config is more a short way of specifying
config as a git command. Try e.g.
man git-config. By itself it is usually not recognized as a command.
git this is also a bit more complex. As it is a tool-kit -> suite, as in many, many commands belonging to
git – it is natural to use a command based implementation. This is a design chosen by the developers of
Further. As it holds a lot of commands, they have divided the commands in several groups where the two main is classified as Plumbing and Porcelain. Also see: What does the term porcelain mean in Git?. The manual page has a ordered grouping starting from
Further one can also customize, trough configuration files, what some of the commands do. As an example. You can view differences between commits by
git diff. This command can be customized in your
.gitconfig. You can specify which diff program to use and how it should be called.
To make help for various commands easily accessible one also has the possibility to say:
git help command
git help commit, gives you help for
Guess it could help if you see
git as a command line suite, or even a menu driven command environment. As with a GUI application where you can click
File->Open->[Some file], a command driven suite could have
suite open <file>.