Git Command-Line Options and Behavior

command line option of the `git commit` command, when given, takes precedence over these two sources of information. Aggregating short options ~~~~~~~~~~~~~~~~~~~~~~~~~ Commands that support the enhanced option parser allow you to aggregate short options. This means that you can for example use `git rm -rf` or `git clean -fdx`. Abbreviating long options ~~~~~~~~~~~~~~~~~~~~~~~~~ Commands that support the enhanced option parser accepts unique prefix of a long option as if it is fully spelled out, but use this with a caution. For example, `git commit --amen` behaves as if you typed `git commit --amend`, but that is true only until a later version of Git introduces another option that shares the same prefix, e.g. `git commit --amenity` option. Separating argument from the option ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ You can write the mandatory option parameter to an option as a separate word on the command line. That means that all the following uses work: ---------------------------- $ git foo --long-opt=Arg $ git foo --long-opt Arg $ git foo -oArg $ git foo -o Arg ---------------------------- However, this is *NOT* allowed for switches with an optional value, where the 'stuck' form must be used: ---------------------------- $ git describe --abbrev HEAD # correct $ git describe --abbrev=10 HEAD # correct $ git describe --abbrev 10 HEAD # NOT WHAT YOU MEANT ---------------------------- NOTES ON FREQUENTLY CONFUSED OPTIONS ------------------------------------ Many commands that can work on files in the working tree and/or in the index can take `--cached` and/or `--index` options. Sometimes people incorrectly think that, because the index was originally called cache, these two are synonyms. They are *not* -- these two options mean very different things. * The `--cached` option is used to ask a command that usually works on files in the working tree to *only* work with the index. For example, `git grep`, when used without a commit to specify from which commit to look for strings in, usually works on files in the working tree, but with the `--cached` option, it looks for strings in the index. * The `--index` option is used to ask a command that usually works on files in the working tree to *also* affect the index. For example, `git stash apply` usually merges changes recorded in a stash entry to the working tree, but with the `--index` option, it also merges changes to the index as well. `git apply` command can be used with `--cached` and `--index` (but not at the same time). Usually the command only affects the files in the working tree, but with `--index`, it patches both the files and their index entries, and with `--cached`, it modifies only the index entries. See also https://lore.kernel.org/git/7v64clg5u9.fsf@assigned-by-dhcp.cox.net/ and https://lore.kernel.org/git/7vy7ej9g38.fsf@gitster.siamese.dyndns.org/ for further information. Some other commands that also work on files in the working tree and/or in the index can take `--staged` and/or `--worktree`. * `--staged` is exactly like `--cached`, which is used to ask a command to only work on the index, not the working tree. * `--worktree` is the opposite, to ask a command to work on the working tree only, not the index. * The two options can be specified together to ask a command to work on both the index and the working tree. GIT --- Part of the linkgit:git[1] suite

This section describes various aspects of Git's command-line interface, including aggregating short options, abbreviating long options, separating arguments from options, and notes on frequently confused options such as --cached, --index, --staged, and --worktree, which control whether commands operate on the working tree, index, or both.