Reapply commits on top of another base tip

If <branch> is specified, git rebase will perform an automatic git switch <branch> before doing anything else. Otherwise it remains on the current branch

                     A---B---C topic
                    /
               D---E---F---G master

git checkout topic && git rebase master
git rebase master topic
# rebase (from) master (for) topic
                             A'--B'--C' topic
                            /
               D---E---F---G master

----------------------------------------------------

               o---o---o---o---o  master
                    \
                     o---o---o---o---o  next
                                      \
                                       o---o---o  topic

git rebase --onto master next topic
# rebase (onto) master (from) next (for) topic

               o---o---o---o---o  master
                   |            \
                   |             o'--o'--o'  topic
                    \
                     o---o---o---o---o  next

git rebase [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase> | --keep-base] [<upstream> [<branch>]]
git rebase [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>] --root [<branch>]
git rebase (--continue | --skip | --abort | --quit | --edit-todo | --show-current-patch)

  --onto <newbase> # Starting point at which to create the new commits. If the --onto option is not specified, the starting point is <upstream>. May be any valid commit, and not just an existing branch name
  --keep-base # Set the starting point at which to create the new commits to the merge base of <upstream> <branch>. Running git rebase --keep-base <upstream> <branch> is equivalent to running git rebase --onto <upstream>... <upstream>
  <upstream> # Upstream branch to compare against. May be any valid commit, not just an existing branch name. Defaults to the configured upstream for the current branch
  <branch> # Working branch; defaults to HEAD

  --continue # Restart the rebasing process after having resolved a merge conflict
  --abort # Abort the rebase operation and reset HEAD to the original branch. If <branch> was provided when the rebase operation was started, then HEAD will be reset to <branch>. Otherwise HEAD will be reset to where it was when the rebase operation was started
  --quit # Abort the rebase operation but HEAD is not reset back to the original branch. The index and working tree are also left unchanged as a result
  --keep-empty # Keep the commits that do not change anything from its parents in the result
  --allow-empty-message # By default, rebasing commits with an empty message will fail. This option overrides that behavior, allowing commits with empty messages to be rebased
  --skip # Restart the rebasing process by skipping the current patch
  --edit-todo # Edit the todo list during an interactive rebase
  --show-current-patch # Show the current patch in an interactive rebase or when rebase is stopped because of conflicts. This is the equivalent of git show REBASE_HEAD
  -m, --merge # Use merging strategies to rebase. When the recursive (default) merge strategy is used, this allows rebase to be aware of renames on the upstream side
  -s <strategy>, --strategy=<strategy> # Use the given merge strategy. If there is no -s option git merge-recursive is used instead. This implies --merge
  -X <strategy-option>, --strategy-option=<strategy-option> # Pass the <strategy-option> through to the merge strategy. This implies --merge and, if no strategy has been specified, -s recursive. Note the reversal of ours and theirs as noted above for the -m option
  --rerere-autoupdate, --no-rerere-autoupdate # Allow the rerere mechanism to update the index with the result of auto-conflict resolution if possible
  -S[<keyid>], --gpg-sign[=<keyid>] # GPG-sign commits. The keyid argument is optional and defaults to the committer identity; if specified, it must be stuck to the option without a space
  -q, --quiet # Be quiet. Implies --no-stat
  -v, --verbose # Be verbose. Implies --stat
  --stat # Show a diffstat of what changed upstream since the last rebase. The diffstat is also controlled by the configuration option rebase.stat
  -n, --no-stat # Do not show a diffstat as part of the rebase process
  --no-verify # This option bypasses the pre-rebase hook. See also githooks(5)
  --verify # Allows the pre-rebase hook to run, which is the default. This option can be used to override --no-verify. See also githooks(5)
  -C<n> # Ensure at least <n> lines of surrounding context match before and after each change. When fewer lines of surrounding context exist they all must match. By default no context is ever ignored
  --no-ff, --force-rebase, -f # Individually replay all rebased commits instead of fast-forwarding over the unchanged ones. This ensures that the entire history of the rebased branch is composed of new commits
  --fork-point, --no-fork-point # Use reflog to find a better common ancestor between <upstream> and <branch> when calculating which commits have been introduced by <branch>
  --ignore-whitespace, --whitespace=<option> # These flag are passed to the git apply program (see git-apply(1)) that applies the patch
  --committer-date-is-author-date, --ignore-date # These flags are passed to git am to easily change the dates of the rebased commits (see git-am(1))
  --signoff # Add a Signed-off-by: trailer to all the rebased commits. Note that if --interactive is given then only commits marked to be picked, edited or reworded will have the trailer added
  -i, --interactive # Make a list of the commits which are about to be rebased. Let the user edit that list before rebasing. This mode can also be used to split commits (see SPLITTING COMMITS below)
  -r, --rebase-merges[=(rebase-cousins|no-rebase-cousins)] # By default, a rebase will simply drop merge commits from the todo list, and put the rebased commits into a single, linear branch. With --rebase-merges, the rebase will instead try to preserve the branching structure within the commits that are to be rebased, by recreating the merge commits
  -p, --preserve-merges # [DEPRECATED: use --rebase-merges instead] Recreate merge commits instead of flattening the history by replaying commits a merge commit introduces. Merge conflict resolutions or manual amendments to merge commits are not preserved
  -x <cmd>, --exec <cmd> # Append "exec <cmd>" after each line creating a commit in the final history. <cmd> will be interpreted as one or more shell commands. Any command that fails will interrupt the rebase, with exit code 1
  --root # Rebase all commits reachable from <branch>, instead of limiting them with an <upstream>. This allows you to rebase the root commit(s) on a branch
  --autosquash, --no-autosquash # When the commit log message begins with "squash! ..." (or "fixup! ..."), and there is already a commit in the todo list that matches the same ..., automatically modify the todo list of rebase -i so that the commit marked for squashing comes right after the commit to be modified, and change the action of the moved commit from pick to squash (or fixup)
  --autostash, --no-autostash # Automatically create a temporary stash entry before the operation begins, and apply it after the operation ends. This means that you can run rebase on a dirty worktree. However, use with care: the final stash application after a # successful rebase might result in non-trivial conflicts
  --reschedule-failed-exec, --no-reschedule-failed-exec
     Automatically reschedule exec commands that failed. This only makes sense in interactive mode (or when an --exec option was provided)

INCOMPATIBLE OPTIONS

The following options:

  --committer-date-is-author-date
  --ignore-date
  --whitespace
  --ignore-whitespace
  -C

are incompatible with the following options:

  --merge
  --strategy
  --strategy-option
  --allow-empty-message
  --[no-]autosquash
  --rebase-merges
  --preserve-merges
  --interactive
  --exec
  --keep-empty
  --edit-todo
  --root when used in combination with --onto

In addition, the following pairs of options are incompatible:

  --preserve-merges and --interactive
  --preserve-merges and --signoff
  --preserve-merges and --rebase-merges
  --keep-base and --onto
  --keep-base and --root

git-restore - Restore working tree files

MRestore specified paths in the working tree with some contents from a restore source. If a path is tracked but does not exist in the restore source, it will be removed to match the source

The command can also be used to restore the content in the index with --staged, or restore both the working tree and the index with --staged --worktree

By default, the restore sources for working tree and the index are the index and HEAD respectively. --source could be used to specify a commit as the restore source

git restore [<options>] [--source=<tree>] [--staged] [--worktree] [--] <pathspec>...
git restore [<options>] [--source=<tree>] [--staged] [--worktree] --pathspec-from-file=<file> [--pathspec-file-nul]
git restore (-p|--patch) [<options>] [--source=<tree>] [--staged] [--worktree] [--] [<pathspec>...]

  -s <tree>, --source=<tree> # Restore the working tree files with the content from the given tree. It is common to specify the source tree by naming a commit, branch or tag associated with it.
  -p, --patch # Interactively select hunks in the difference between the restore source and the restore location. See the “Interactive Mode” section of git-add(1) to learn how to operate the --patch mode.
  -W, --worktree, -S, --staged # Specify the restore location. If neither option is specified, by default the working tree is restored. Specifying --staged will only restore the index. Specifying both restores both.
  -q, --quiet # Quiet, suppress feedback messages. Implies --no-progress.
  --progress, --no-progress # Progress status is reported on the standard error stream by default when it is attached to a terminal, unless --quiet is specified. This flag enables progress reporting even if not attached to a terminal, regardless of --quiet.
  --ours, --theirs # When restoring files in the working tree from the index, use stage #2 (ours) or #3 (theirs) for unmerged paths.
  -m, --merge # When restoring files on the working tree from the index, recreate the conflicted merge in the unmerged paths.
  --conflict=<style> # The same as --merge option above, but changes the way the conflicting hunks are presented, overriding the merge.conflictStyle configuration variable. Possible values are "merge" (default) and "diff3" (in addition to what is shown by # "merge" style, shows the original contents).
  --ignore-unmerged # When restoring files on the working tree from the index, do not abort the operation if there are unmerged entries and neither --ours, --theirs, --merge or --conflict is specified. Unmerged paths on the working tree are left alone.
  --ignore-skip-worktree-bits # In sparse checkout mode, by default is to only update entries matched by <pathspec> and sparse patterns in $GIT_DIR/info/sparse-checkout. This option ignores the sparse patterns and unconditionally restores any files in <pathspec>.
  --overlay, --no-overlay # In overlay mode, the command never removes files when restoring. In no-overlay mode, tracked files that do not appear in the --source tree are removed, to make them match <tree> exactly. The default is no-overlay mode.
  --pathspec-from-file=<file> # Pathspec is passed in <file> instead of commandline args. If <file> is exactly - then standard input is used. Pathspec elements are separated by LF or CR/LF. Pathspec elements can be quoted as explained for the configuration variable core.quotePath (see git-config(1)). See also --pathspec-file-nul and global --literal-pathspecs.
  --pathspec-file-nul # Only meaningful with --pathspec-from-file. Pathspec elements are separated with NUL character and all other characters are taken literally (including newlines and quotes).
  -- # Do not interpret any more arguments as options.
  <pathspec>... # Limits the paths affected by the operation.

EXAMPLES

The following sequence switches to the master branch, reverts the Makefile to two revisions back, deletes hello.c by mistake, and gets it back from the index

git switch master
git restore --source master~2 Makefile # take a file out of another commit
rm -f hello.c
git restore hello.c # restore hello.c from the index

If you want to restore all C source files to match the version in the index, you can say

git restore '*.c'

Note the quotes around *.c. The file hello.c will also be restored, even though it is no longer in the working tree, because the file globbing is used to match entries in the index (not in the working tree by the shell).

To restore all files in the current directory

git restore .

or to restore all working tree files with top pathspec magic (see gitglossary(7))

git restore :/

To restore a file in the index to match the version in HEAD (this is the same as using git-reset(1))

git restore --staged hello.c

or you can restore both the index and the working tree (this the same as using git-checkout(1))

git restore --source=HEAD --staged --worktree hello.c

or the short form which is more practical but less readable:

git restore -s@ -SW hello.c

GIT URLS

In general, URLs contain information about the transport protocol, the address of the remote server, and the path to the repository. Depending on the
transport protocol, some of this information may be absent.

Git supports ssh, git, http, and https protocols (in addition, ftp, and ftps can be used for fetching, but this is inefficient and deprecated; do not use
it).

The native transport (i.e. git:// URL) does no authentication and should be used with caution on unsecured networks.

The following syntaxes may be used with them:

• ssh://[user@]host.xz[:port]/path/to/repo.git/
• git://host.xz[:port]/path/to/repo.git/
• http[s]://host.xz[:port]/path/to/repo.git/
• ftp[s]://host.xz[:port]/path/to/repo.git/

An alternative scp-like syntax may also be used with the ssh protocol:

• [user@]host.xz:path/to/repo.git/

This syntax is only recognized if there are no slashes before the first colon. This helps differentiate a local path that contains a colon. For example the
local path foo:bar could be specified as an absolute path or ./foo:bar to avoid being misinterpreted as an ssh url.

The ssh and git protocols additionally support ~username expansion:

• ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/
• git://host.xz[:port]/~[user]/path/to/repo.git/
• [user@]host.xz:/~[user]/path/to/repo.git/

For local repositories, also supported by Git natively, the following syntaxes may be used:

• /path/to/repo.git/
• file:///path/to/repo.git/

These two syntaxes are mostly equivalent, except when cloning, when the former implies --local option

git clone, git fetch and git pull, but not git push, will also accept a suitable bundle file

When Git doesn’t know how to handle a certain transport protocol, it attempts to use the remote-<transport> remote helper, if one exists. To explicitly
request a remote helper, the following syntax may be used:

• <transport>::<address>

where <address> may be a path, a server and path, or an arbitrary URL-like string recognized by the specific remote helper being invoked

If there are a large number of similarly-named remote repositories and you want to use a different format for them (such that the URLs you use will be rewritten into URLs that work), you can create a configuration section of the form:

[url "<actual url base>"]
    insteadOf = <other url base>

For example, with this:

[url "git://git.host.xz/"]
    insteadOf = host.xz:/path/to/
    insteadOf = work:

a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be rewritten in any context that takes a URL to be "git://git.host.xz/repo.git".

If you want to rewrite URLs for push only, you can create a configuration section of the form:

[url "<actual url base>"]
    pushInsteadOf = <other url base>

For example, with this:

[url "ssh://example.org/"]
    pushInsteadOf = git://example.org/

a URL like "git://example.org/path/to/repo.git" will be rewritten to "ssh://example.org/path/to/repo.git" for pushes, but pulls will still use the original URL.

REMOTES

The name of one of the following can be used instead of a URL as <repository> argument:

• a remote in the Git configuration file: $GIT_DIR/config,
• a file in the $GIT_DIR/remotes directory, or
• a file in the $GIT_DIR/branches directory.

All of these also allow you to omit the refspec from the command line because they each contain a refspec which git will use by default.

Named remote in configuration file
You can choose to provide the name of a remote which you had previously configured using git-remote(1), git-config(1) or even by a manual edit to the
$GIT_DIR/config file. The URL of this remote will be used to access the repository. The refspec of this remote will be used by default when you do not
provide a refspec on the command line. The entry in the config file would appear like this:

[remote "<name>"]
    url = <url>
    pushurl = <pushurl>
    push = <refspec>
    fetch = <refspec>

The <pushurl> is used for pushes only. It is optional and defaults to <url>.

Named file in $GIT_DIR/remotes
You can choose to provide the name of a file in $GIT_DIR/remotes. The URL in this file will be used to access the repository. The refspec in this file will
be used as default when you do not provide a refspec on the command line. This file should have the following format:

URL: one of the above URL format
    Push: <refspec>
    Pull: <refspec>

Push: lines are used by git push and Pull: lines are used by git pull and git fetch. Multiple Push: and Pull: lines may be specified for additional branch
mappings.

Named file in $GIT_DIR/branches
You can choose to provide the name of a file in $GIT_DIR/branches. The URL in this file will be used to access the repository. This file should have the
following format:

<url>#<head>

<url> is required; #<head> is optional.

Depending on the operation, git will use one of the following refspecs, if you don’t provide one on the command line. <branch> is the name of this file in
$GIT_DIR/branches and <head> defaults to master.

git fetch uses:

refs/heads/<head>:refs/heads/<branch>

git push uses:

HEAD:refs/heads/<head>

Create, list, delete or verify a tag object signed with GPG

Add a tag reference in refs/tags/, unless -d/-l/-v is given to delete, list or verify tags

Unless -f is given, the named tag must not yet exist

If one of -a, -s, or -u <keyid> is passed, the command creates a tag object, and requires a tag message. Unless -m <msg> or -F <file> is given, an editor is started for the user to type in the tag message

If -m <msg> or -F <file> is given and -a, -s, and -u <keyid> are absent, -a is implied

Otherwise, a tag reference that points directly at the given object (i.e., a lightweight tag) is created

A GnuPG signed tag object will be created when -s or -u <keyid> is used. When -u <keyid> is not used, the committer identity for the current user is used to find the GnuPG key for signing. The configuration variable gpg.program is used to specify custom GnuPG binary

Tag objects (created with -a, -s, or -u) are called "annotated" tags; they contain a creation date, the tagger name and e-mail, a tagging message, and an optional GnuPG signature. Whereas a "lightweight" tag is simply a name for an object (usually a commit object)

Annotated tags are meant for release while lightweight tags are meant for private or temporary object labels. For this reason, some git commands for naming objects (like git describe) will ignore lightweight tags by default

git tag [-a | -s | -u <keyid>] [-f] [-m <msg> | -F <file>] [-e] <tagname> [<commit> | <object>]
git tag -d <tagname>...
git tag [-n[<num>]] -l [--contains <commit>] [--no-contains <commit>] [--points-at <object>] [--column[=<options>] | --no-column] [--create-reflog] [--sort=<key>] [--format=<format>] [--[no-]merged [<commit>]] [<pattern>...]
git tag -v [--format=<format>] <tagname>...

  -a, --annotate # Make an unsigned, annotated tag object
  -s, --sign # Make a GPG-signed tag, using the default e-mail address’s key
  --no-sign # Override tag
  -u <keyid>, --local-user=<keyid> # Make a GPG-signed tag, using the given key
  -f, --force # Replace an existing tag with the given name (instead of failing)
  -d, --delete # Delete existing tags with the given names
  -v, --verify # Verify the GPG signature of the given tag names
  -n<num> # <num> specifies how many lines from the annotation, if any, are printed when using -l
  -l, --list # List tags
  --sort=<key> # Sort based on the key given
  --color[=<when>] # Respect any colors specified in the --format option
  -i, --ignore-case # Sorting and filtering tags are case insensitive
  --column[=<options>], --no-column # Display tag listing in columns
  --contains [<commit>] # Only list tags which contain the specified commit (HEAD if not specified)
  --no-contains [<commit>] # Only list tags which don’t contain the specified commit (HEAD if not specified)
  --merged [<commit>] # Only list tags whose commits are reachable from the specified commit (HEAD if not specified), incompatible with --no-merged
  --no-merged [<commit>] # Only list tags whose commits are not reachable from the specified commit (HEAD if not specified), incompatible with --merged
  --points-at <object> # Only list tags of the given object (HEAD if not specified)
  -m <msg>, --message=<msg> # Use the given tag message (instead of prompting)
  -F <file>, --file=<file> # Take the tag message from the given file
  -e, --edit # The message taken from file with -F and command line with -m are usually used as the tag message unmodified
  --cleanup=<mode> # This option sets how the tag message is cleaned up
  --create-reflog # Create a reflog for the tag
  --format=<format> # A string that interpolates %(fieldname) from a tag ref being shown and the object it points at
  <tagname> # The name of the tag to create, delete, or describe
  <commit>, <object> # The object that the new tag will refer to, usually a commit

Download objects and refs from another repository

Fetch branches and/or tags (collectively, "refs") from one or more other repositories, along with the objects necessary to complete their histories. Remote-tracking branches are updated (see the description of <refspec> below for ways to control this behavior)

By default, any tag that points into the histories being fetched is also fetched; the effect is to fetch tags that point at branches that you are interested in. This default behavior can be changed by using the --tags or --no-tags options or by configuring remote.<name>.tagOpt. By using a refspec that fetches tags explicitly, you can fetch tags that do not point into branches you are interested in as well

git fetch can fetch from either a single named repository or URL, or from several repositories at once if <group> is given and there is a remotes.<group> entry in the configuration file

When no remote is specified, by default the origin remote will be used, unless there’s an upstream branch configured for the current branch

The names of refs that are fetched, together with the object names they point at, are written to .git/FETCH_HEAD. This information may be used by
scripts or other git commands, such as git-pull(1)

git fetch [<options>] [<repository> [<refspec>...]]
git fetch [<options>] <group>
git fetch --multiple [<options>] [(<repository> | <group>)...]
git fetch --all [<options>]

  --all # Fetch all remotes
  -a, --append # Append ref names and object names of fetched refs to the existing contents of .git/FETCH_HEAD. Without this option old data in .git/FETCH_HEAD will be overwritten
  --depth=<depth> # Limit fetching to the specified number of commits from the tip of each remote branch history. If fetching to a shallow repository created by git clone with --depth=<depth> option, deepen or shorten the history to the specified number of commits. Tags for the deepened commits are not fetched
  --deepen=<depth> # Similar to --depth, except it specifies the number of commits from the current shallow boundary instead of from the tip of each remote branch history
  --shallow-since=<date> # Deepen or shorten the history of a shallow repository to include all reachable commits after <date>
  --shallow-exclude=<revision> # Deepen or shorten the history of a shallow repository to exclude commits reachable from a specified remote branch or tag. This option can be specified multiple times
  --unshallow # If the source repository is complete, convert a shallow repository to a complete one, removing all the limitations imposed by shallow repositories
  --update-shallow # By default when fetching from a shallow repository, git fetch refuses refs that require updating .git/shallow. This option updates .git/shallow and accept such refs
  --negotiation-tip=<commit|glob> # By default, Git will report, to the server, commits reachable from all local refs to find common commits in an attempt to reduce the size of the to-be-received packfile. If specified, Git will only report commits reachable from the given tips. This is useful to speed up fetches when the user knows which local ref is likely to have commits in common with the upstream ref being fetched
  --dry-run # Show what would be done, without making any changes
  -f, --force # When git fetch is used with <src>:<dst> refspec it may refuse to update the local branch as discussed in the <refspec> part below. This option overrides that check
  -k, --keep # Keep downloaded pack
  --multiple # Allow several <repository> and <group> arguments to be specified. No <refspec>s may be specified
  --[no-]auto-gc # Run git gc --auto at the end to perform garbage collection if needed. This is enabled by default
  --[no-]write-commit-graph # Write a commit-graph after fetching. This overrides the config setting fetch.writeCommitGraph
  -p, --prune # Before fetching, remove any remote-tracking references that no longer exist on the remote. Tags are not subject to pruning if they are fetched only because of the default tag auto-following or due to a --tags option. However, if tags are fetched due to an explicit refspec (either on the command line or in the remote configuration, for example if the remote was cloned with the --mirror option), then they are also subject to pruning. Supplying --prune-tags is a shorthand for providing the tag refspec
  -P, --prune-tags # Before fetching, remove any local tags that no longer exist on the remote if --prune is enabled. This option should be used more carefully, unlike --prune it will remove any local references (local tags) that have been created. This option is a shorthand for providing the explicit tag refspec along with --prune, see the discussion about that in its documentation
  -n, --no-tags # By default, tags that point at objects that are downloaded from the remote repository are fetched and stored locally. This option disables this automatic tag following. The default behavior for a remote may be specified with the remote.<name>.tagOpt setting
  --refmap=<refspec> # When fetching refs listed on the command line, use the specified refspec (can be given more than once) to map the refs to remote-tracking branches, instead of the values of remote.*.fetch configuration variables for the remote repository
  -t, --tags # Fetch all tags from the remote (i.e., fetch remote tags refs/tags/* into local tags with the same name), in addition to whatever else would otherwise be fetched. Using this option alone does not subject tags to pruning, even if --prune is used (though tags may be pruned anyway if they are also the destination of an explicit refspec; see --prune)
  --recurse-submodules[=yes|on-demand|no] # This option controls if and under what conditions new commits of populated submodules should be fetched too. It can be used as a boolean option to completely disable recursion when set to no or to unconditionally recurse into all populated submodules when set to yes, which is the default when this option is used without any value. Use on-demand to only recurse into a populated submodule when the superproject retrieves a commit that updates the submodule’s reference to a commit that isn’t already in the local submodule clone
  -j, --jobs=<n> # Number of parallel children to be used for all forms of fetching
  --no-recurse-submodules # Disable recursive fetching of submodules (this has the same effect as using the --recurse-submodules=no option)
  --set-upstream # If the remote is fetched successfully, pull and add upstream (tracking) reference, used by argument-less git-pull(1) and other commands. For more information, see branch.<name>.merge and branch.<name>.remote in git-config(1)
  --submodule-prefix=<path> # Prepend <path> to paths printed in informative messages such as "Fetching submodule foo". This option is used internally when recursing over submodules
  --recurse-submodules-default=[yes|on-demand] # This option is used internally to temporarily provide a non-negative default value for the --recurse-submodules option. All other methods of configuring fetch’s submodule recursion (such as settings in gitmodules(5) and git-config(1)) override this option, as does specifying --[no-]recurse-submodules directly
  -u, --update-head-ok # By default git fetch refuses to update the head which corresponds to the current branch. This flag disables the check. This is purely for the internal use for git pull to communicate with git fetch, and unless you are implementing your own Porcelain you are not supposed to use it
  --upload-pack <upload-pack> # When given, and the repository to fetch from is handled by git fetch-pack, --exec=<upload-pack> is passed to the command to specify non-default path for the command run on the other end
  -q, --quiet # Pass --quiet to git-fetch-pack and silence any other internally used git commands. Progress is not reported to the standard error stream
  -v, --verbose # Be verbose
  --progress # Progress status is reported on the standard error stream by default when it is attached to a terminal, unless -q is specified. This flag forces progress status even if the standard error stream is not directed to a terminal
  -o <option>, --server-option=<option> # Transmit the given string to the server when communicating using protocol version 2. The given string must not contain a NUL or LF character. The server’s handling of server options, including unknown ones, is server-specific. When multiple --server-option=<option> are given, they are all sent to the other side in the order listed on the command line
  --show-forced-updates # By default, git checks if a branch is force-updated during fetch. This can be disabled through fetch.showForcedUpdates, but the --show-forced-updates option guarantees this check occurs
  --no-show-forced-updates # By default, git checks if a branch is force-updated during fetch. Pass --no-show-forced-updates or set fetch.showForcedUpdates to false to skip this check for performance reasons. If used during git-pull the --ff-only option will still check for forced updates before attempting a fast-forward update
  -4, --ipv4 # Use IPv4 addresses only, ignoring IPv6 addresses
  -6, --ipv6 # Use IPv6 addresses only, ignoring IPv4 addresses
  <repository> # The "remote" repository that is the source of a fetch or pull operation. This parameter can be either a URL or the name of a remote
  <group> # A name referring to a list of repositories as the value of remotes.<group> in the configuration file
  <refspec> # Specifies which refs to fetch and which local refs to update. When no <refspec>s appear on the command line, the refs to fetch are read from remote.<repository>.fetch variables instead

examples

Update the remote-tracking branches

git fetch origin

The above command copies all branches from the remote refs/heads/ namespace and stores them to the local refs/remotes/origin/ namespace,
unless the branch.<name>.fetch option is used to specify a non-default refspec

Using refspecs explicitly:

git fetch origin +pu:pu maint:tmp

This updates (or creates, as necessary) branches pu and tmp in the local repository by fetching from the branches (respectively) pu and maint
from the remote repository

The pu branch will be updated even if it does not fast-forward, because it is prefixed with a plus sign; tmp will not be

Peek at a remote’s branch, without configuring the remote in your local repository

git fetch git://git.kernel.org/pub/scm/git/git.git maint
git log FETCH_HEAD

The first command fetches the maint branch from the repository at git://git.kernel.org/pub/scm/git/git.git and the second command uses
FETCH_HEAD to examine the branch with git-log(1). The fetched objects will eventually be removed by git’s built-in housekeeping

List references in a remote repository

Displays references available in a remote repository along with the associated commit IDs

git ls-remote [--heads] [--tags] [--refs] [--upload-pack=<exec>] [-q | --quiet] [--exit-code] [--get-url] [--sort=<key>] [--symref] [<repository> [<refs>...]]

  -h, --heads, -t, --tags # Limit to only refs/heads and refs/tags, respectively. These options are not mutually exclusive; when given both, references stored in refs/heads and refs/tags are displayed
  --refs # Do not show peeled tags or pseudorefs like HEAD in the output
  -q, --quiet # Do not print remote URL to stderr
  --upload-pack=<exec> # Specify the full path of git-upload-pack on the remote host. This allows listing references from repositories accessed via SSH and where the SSH daemon does not use the PATH configured by the user
  --exit-code # Exit with status "2" when no matching refs are found in the remote repository. Usually the command exits with status "0" to indicate it successfully talked with the remote repository, whether it found any matching refs
  --get-url # Expand the URL of the given remote repository taking into account any "url.<base>.insteadOf" config setting (See git-config(1)) and exit without talking to the remote
  --symref # In addition to the object pointed by it, show the underlying ref pointed by it when showing a symbolic ref. Currently, upload-pack only shows the symref HEAD, so it will be the only one shown by ls-remote
  --sort=<key> # Sort based on the key given. Prefix - to sort in descending order of the value. Supports "version:refname" or "v:refname" (tag names are treated as versions). The "version:refname" sort order can also be affected by the "versionsort.suffix" configuration variable. See git-for- each-ref(1) for more sort options, but be aware keys like committerdate that require access to the objects themselves will not work for refs whose objects have not yet been fetched from the remote, and will give a missing object error
  -o <option>, --server-option=<option> # Transmit the given string to the server when communicating using protocol version 2. The given string must not contain a NUL or LF character. When multiple --server-option=<option> are given, they are all sent to the other side in the order listed on the command line
  <repository> # The "remote" repository to query. This parameter can be either a URL or the name of a remote (see the GIT URLS and REMOTES sections of git- fetch(1))
  <refs>... # When unspecified, all references, after filtering done with --heads and --tags, are shown. When <refs>... are specified, only references matching the given patterns are displayed

examples

git ls-remote --tags ./
git ls-remote http://www.kernel.org/pub/scm/git/git.git master pu rc
git remote add korg http://www.kernel.org/pub/scm/git/git.git
git ls-remote --tags korg v\*

Shows the commit logs

The command takes options applicable to the git rev-list command to control what is shown and how, and options applicable to the git diff-* commands to control how the changes each commit introduces are shown

OPTIONS

git log [<options>] [<revision range>] [[--] <path>...]

  --follow # Continue listing the history of a file beyond renames (works only for a single file)
  --no-decorate, --decorate[=short|full|auto|no] # Print out the ref names of any commits that are shown
  --decorate-refs=<pattern>, --decorate-refs-exclude=<pattern> # If no --decorate-refs is given, pretend as if all refs were included
  --source # Print out the ref name given on the command line by which each commit was reached
  --[no-]use-mailmap # Use mailmap file to map author and committer names and email addresses to canonical real names and email addresses
  --full-diff # Without this flag, git log -p <path>
   Note that this affects all diff-based output types, e
  --log-size # Include a line “log size <number>” in the output for each commit, where <number> is the length of that commit’s message in bytes
  -L <start>,<end>:<file>, -L :<funcname>:<file> # Trace the evolution of the line range given by "<start>,<end>" (or the function name regex <funcname>) within the <file>
      <start> and <end> can take one of these forms:
      - number # If <start> or <end> is a number, it specifies an absolute line number (lines count from 1)
      - /regex/ # This form will use the first line matching the given POSIX regex
      - +offset or -offset # This is only valid for <end> and will specify a number of lines before or after the line given by <start>
  <revision range> # Show only commits in the specified revision range
  [--] <path>... # Show only commits that are enough to explain how the files that match the specified paths came to be. See History Simplification below for details and other simplification modes
  -<number>, -n <number>, --max-count=<number> # Limit the number of commits to output
  --skip=<number> # Skip number commits before starting to show the commit output
  --since=<date>, --after=<date> # Show commits more recent than a specific date
  --until=<date>, --before=<date> # Show commits older than a specific date
  --author=<pattern>, --committer=<pattern> # Limit the commits output to ones with author/committer header lines that match the specified pattern (regular expression)
  --grep-reflog=<pattern> # Limit the commits output to ones with reflog entries that match the specified pattern (regular expression)
  --grep=<pattern> # Limit the commits output to ones with log message that matches the specified pattern (regular expression)
  --all-match # Limit the commits output to ones that match all given --grep, instead of ones that match at least one
  --invert-grep # Limit the commits output to ones with log message that do not match the pattern specified with --grep=<pattern>
  -i, --regexp-ignore-case # Match the regular expression limiting patterns without regard to letter case
  --basic-regexp # Consider the limiting patterns to be basic regular expressions; this is the default
  -E, --extended-regexp # Consider the limiting patterns to be extended regular expressions instead of the default basic regular expressions
  -F, --fixed-strings # Consider the limiting patterns to be fixed strings (don’t interpret pattern as a regular expression)
  -P, --perl-regexp # Consider the limiting patterns to be Perl-compatible regular expressions
  --remove-empty # Stop when a given path disappears from the tree
  --merges # Print only merge commits
  --no-merges # Do not print commits with more than one parent
  --min-parents=<number>, --max-parents=<number>, --no-min-parents, --no-max-parents # Show only commits which have at least (or at most) that many parent commits
  --first-parent # Follow only the first parent commit upon seeing a merge commit
  --not # Reverses the meaning of the ^ prefix (or lack thereof) for all following revision specifiers, up to the next --not
  --all # Pretend as if all the refs in refs/, along with HEAD, are listed on the command line as <commit>
  --branches[=<pattern>] # Pretend as if all the refs in refs/heads are listed on the command line as <commit>
  --tags[=<pattern>] # Pretend as if all the refs in refs/tags are listed on the command line as <commit>
  --remotes[=<pattern>] # Pretend as if all the refs in refs/remotes are listed on the command line as <commit>
  --glob=<glob-pattern> # Pretend as if all the refs matching shell glob <glob-pattern> are listed on the command line as <commit>
  --exclude=<glob-pattern> # Do not include refs matching <glob-pattern> that the next --all, --branches, --tags, --remotes, or --glob would otherwise consider
  --reflog # Pretend as if all objects mentioned by reflogs are listed on the command line as <commit>
  --alternate-refs # Pretend as if all objects mentioned as ref tips of alternate repositories were listed on the command line
  --single-worktree # By default, all working trees will be examined by the following options when there are more than one (see git-worktree(1)): --all, --reflog and --indexed-objects
  --ignore-missing # Upon seeing an invalid object name in the input, pretend as if the bad input was not given
  --bisect # Pretend as if the bad bisection ref refs/bisect/bad was listed and as if it was followed by --not and the good bisection refs refs/bisect/good-* on the command line
  --stdin # In addition to the <commit> listed on the command line, read them from the standard input
  --cherry-mark # Like --cherry-pick (see below) but mark equivalent commits with = rather than omitting them, and inequivalent ones with +
  --cherry-pick # Omit any commit that introduces the same change as another commit on the “other side” when the set of commits are limited with symmetric difference
  --left-only, --right-only # List only commits on the respective side of a symmetric difference, i
  --cherry # A synonym for --right-only --cherry-mark --no-merges; useful to limit the output to the commits on our side and mark those that have been applied to the other side of a forked history with git log --cherry upstream
  -g, --walk-reflogs # Instead of walking the commit ancestry chain, walk reflog entries from the most recent one to older ones
  --merge # After a failed merge, show refs that touch files having a conflict and don’t exist on all heads to merge
  --boundary # Output excluded boundary commits
  <paths> # Commits modifying the given <paths> are selected
  --simplify-by-decoration # Commits that are referred by some branch or tag are selected
  --full-history # Same as the default mode, but does not prune some history
  --dense # Only the selected commits are shown, plus some to have a meaningful history
  --sparse # All commits in the simplified history are shown
  --simplify-merges # Additional option to --full-history to remove some needless merges from the resulting history, as there are no selected commits contributing to this merge
  --ancestry-path # When given a range of commits to display (e
  --full-history without parent rewriting # This mode differs from the default in one point: always follow all parents of a merge, even if it is TREESAME to one of them
  --full-history with parent rewriting # Ordinary commits are only included if they are !TREESAME (though this can be changed, see --sparse below)
  --dense # Commits that are walked are included if they are not TREESAME to any parent
  --sparse # All commits that are walked are included
  --simplify-merges # First, build a history graph in the same way that --full-history with parent rewriting does (see above)
  --ancestry-path # Limit the displayed commits to those directly on the ancestry chain between the “from” and “to” commits in the given commit range
  --date-order # Show no parents before all of its children are shown, but otherwise show commits in the commit timestamp order
  --author-date-order # Show no parents before all of its children are shown, but otherwise show commits in the author timestamp order
  --topo-order # Show no parents before all of its children are shown, and avoid showing commits on multiple lines of history intermixed
  --reverse # Output the commits chosen to be shown (see Commit Limiting section above) in reverse order
  --no-walk[=(sorted|unsorted)] # Only show the given commits, but do not traverse their ancestors
  --do-walk # Overrides a previous --no-walk

Commit Formatting

  --pretty[=<format>], --format=<format> # Pretty-print the contents of the commit logs in a given format, where <format> can be one of oneline, short, medium, full, fuller, reference, email, raw, format:<string> and tformat:<string>
  --abbrev-commit # Instead of showing the full 40-byte hexadecimal commit object name, show only a partial prefix
  --no-abbrev-commit # Show the full 40-byte hexadecimal commit object name
  --oneline # This is a shorthand for "--pretty=oneline --abbrev-commit" used together
  --encoding=<encoding> # The commit objects record the encoding used for the log message in their encoding header; this option can be used to tell the command to re-code the commit log message in the encoding preferred by the user
  --expand-tabs=<n>, --expand-tabs, --no-expand-tabs # Perform a tab expansion (replace each tab with enough spaces to fill to the next display column that is multiple of <n>) in the log message before showing it in the output
  --notes[=<ref>] # Show the notes (see git-notes(1)) that annotate the commit, when showing the commit log message
  --no-notes # Do not show notes
  --show-notes[=<ref>], --[no-]standard-notes # These options are deprecated
  --show-signature # Check the validity of a signed commit object by passing the signature to gpg --verify and show the output
  --relative-date # Synonym for --date=relative
  --date=<format> # Only takes effect for dates shown in human-readable format, such as when using --pretty
  --parents # Print also the parents of the commit (in the form "commit parent
  --children # Print also the children of the commit (in the form "commit child
  --left-right # Mark which side of a symmetric difference a commit is reachable from
  --graph # Draw a text-based graphical representation of the commit history on the left hand side of the output
  --show-linear-break[=<barrier>] # When --graph is not used, all history branches are flattened which can make it hard to see that the two consecutive commits do not belong to a linear branch

Diff Formatting

Listed below are options that control the formatting of diff output

  -c # With this option, diff output for a merge commit shows the differences from each of the parents to the merge result simultaneously instead of showing pairwise diff between a parent and the result one at a time
  --cc # This flag implies the -c option and further compresses the patch output by omitting uninteresting hunks whose contents in the parents have only two variants and the merge result picks one of them without modification
  --combined-all-paths # This flag causes combined diffs (used for merge commits) to list the name of the file from all parents
  -m # This flag makes the merge commits show the full diff like regular commits; for each merge parent, a separate log entry and diff is generated
  -r # Show recursive diffs
  -t # Show the tree objects in the diff output

PRETTY FORMATS

If the commit is a merge, and if the pretty-format is not oneline, email or raw, an additional line is inserted before the Author: line. This line begins with "Merge: " and the hashes of ancestral commits are printed, separated by spaces. Note that the listed commits may not necessarily be the list of the direct parent commits if you have limited your view of history: for example, if you are only interested in changes related to a certain directory or file

There are several built-in formats, and you can define additional formats by setting a pretty.<name> config option to either another format name, or a format: string, as described below (see git-config(1))
Here are the details of the built-in formats:

• oneline
• short
• medium
• full
• fuller
• reference
• email
• raw
• format:<string> # see man for details
• tformat:<string> # see man for details

COMMON DIFF OPTIONS

  -p, -u, --patch # Generate patch (see section on generating patches)
  -s, --no-patch # Suppress diff output
  -U<n>, --unified=<n> # Generate diffs with <n> lines of context instead of the usual three
  --output=<file> # Output to a specific file instead of stdout
  --output-indicator-new=<char>, --output-indicator-old=<char>, --output-indicator-context=<char> # Specify the character used to indicate new, old or context lines in the generated patch
  --raw # For each commit, show a summary of changes using the raw diff format
  --patch-with-raw # Synonym for -p --raw
  --indent-heuristic # Enable the heuristic that shifts diff hunk boundaries to make patches easier to read
  --no-indent-heuristic # Disable the indent heuristic
  --minimal # Spend extra time to make sure the smallest possible diff is produced
  --patience # Generate a diff using the "patience diff" algorithm
  --histogram # Generate a diff using the "histogram diff" algorithm
  --anchored=<text> # Generate a diff using the "anchored diff" algorithm
  --diff-algorithm={patience|minimal|histogram|myers} # Choose a diff algorithm
  The variants are as follows:
      default, myers # The basic greedy diff algorithm
      minimal # Spend extra time to make sure the smallest possible diff is produced
      patience # Use "patience diff" algorithm when generating patches
      histogram # This algorithm extends the patience algorithm to "support low-occurrence common elements"

  --stat[=<width>[,<name-width>[,<count>]]] # Generate a diffstat
  --compact-summary # Output a condensed summary of extended header information such as file creations or deletions ("new" or "gone", optionally "+l" if it’s a symlink) and mode changes ("+x" or "-x" for adding or removing executable bit respectively) in diffstat
  --numstat # Similar to --stat, but shows number of added and deleted lines in decimal notation and pathname without abbreviation, to make it more machine friendly
  --shortstat # Output only the last line of the --stat format containing total number of modified files, as well as number of added and deleted lines
  -X[<param1,param2,
  The following parameters are available:
      changes # Compute the dirstat numbers by counting the lines that have been removed from the source, or added to the destination
      lines # Compute the dirstat numbers by doing the regular line-based diff analysis, and summing the removed/added line counts
      files # Compute the dirstat numbers by counting the number of files changed
      cumulative # Count changes in a child directory for the parent directory as well
      <limit> # An integer parameter specifies a cut-off percent (3% bygit log [<options>] [<revision range>] [[--] <path>...] default)

      Example: The following will count changed files, while ignoring directories with less than 10% of the total amount of changed files, and accumulating child directory counts in the parent directories: --dirstat=files,10,cumulative

  --cumulative # Synonym for --dirstat=cumulative
  --summary # Output a condensed summary of extended header information such as creations, renames and mode changes
  --patch-with-stat # Synonym for -p --stat
  -z # Separate the commits with NULs instead of with new newlines
  --name-only # Show only names of changed files
  --name-status # Show only names and status of changed files
  --submodule[=<format>] # Specify how differences in submodules are shown
  --color[=<when>] # Show colored diff
  --no-color # Turn off colored diff
  --color-moved[=<mode>] # Moved lines of code are colored differently
  The mode must be one of:
      no # Moved lines are not highlighted
      default # Is a synonym for zebra
      plain # Any line that is added in one location and was removed in another location will be colored with color
      blocks # Blocks of moved text of at least 20 alphanumeric characters are detected greedily
      zebra # Blocks of moved text are detected as in blocks mode
      dimmed-zebra # Similar to zebra, but additional dimming of uninteresting parts of moved code is performed

  --no-color-moved # Turn off move detection
  --color-moved-ws=<modes> # This configures how whitespace is ignored when performing the move detection for --color-moved
  These modes can be given as a comma separated list:
      no # Do not ignore whitespace when performing move detection
      ignore-space-at-eol # Ignore changes in whitespace at EOL
      ignore-space-change # Ignore changes in amount of whitespace
      ignore-all-space # Ignore whitespace when comparing lines
      allow-indentation-change # Initially ignore any whitespace in the move detection, then group the moved code blocks only into a block if the change in whitespace is the same per line

  --no-color-moved-ws # Do not ignore whitespace when performing move detection
  --word-diff[=<mode>] # Show a word diff, using the <mode> to delimit changed words
  The <mode> defaults to plain, and must be one of:
      color # Highlight changed words using only colors
      plain # Show words as [-removed-] and {+added+}
      porcelain # Use a special line-based format intended for script consumption
      none # Disable word diff again

  --word-diff-regex=<regex> # Use <regex> to decide what a word is, instead of considering runs of non-whitespace to be a word
  --color-words[=<regex>] # Equivalent to --word-diff=color plus (if a regex was specified) --word-diff-regex=<regex>
  --no-renames # Turn off rename detection, even when the configuration file gives the default to do so
  --[no-]rename-empty # Whether to use empty blobs as rename source
  --check # Warn if changes introduce conflict markers or whitespace errors
  --ws-error-highlight=<kind> # Highlight whitespace errors in the context, old or new lines of the diff
  --full-index # Instead of the first handful of characters, show the full pre- and post-image blob object names on the "index" line when generating patch format output
  --binary # In addition to --full-index, output a binary diff that can be applied with git-apply
  --abbrev[=<n>] # Instead of showing the full 40-byte hexadecimal object name in diff-raw format output and diff-tree header lines, show only a partial prefix
  -B[<n>][/<m>], --break-rewrites[=[<n>][/<m>]] # Break complete rewrite changes into pairs of delete and create
  -M[<n>], --find-renames[=<n>] # If generating diffs, detect and report renames for each commit
  -C[<n>], --find-copies[=<n>] # Detect copies as well as renames
  --find-copies-harder # For performance reasons, by default, -C option finds copies only if the original file of the copy was modified in the same changeset
  -D, --irreversible-delete # Omit the preimage for deletes, i.e. print only the header but not the diff between the preimage and /dev/null
  -l<num> # The -M and -C options require O(n^2) processing time where n is the number of potential rename/copy targets
  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]] # Select only files that are Added (A), Copied (C), Deleted (D), Modified (M), Renamed (R), have their type (i.e. regular file, symlink, submodule, ...) changed (T), are Unmerged (U), are Unknown (X), or have had their pairing Broken (B)
  -S<string> # Look for differences that change the number of occurrences of the specified string (i.e. addition/deletion) in a file. Intended for the scripter’s use
  -G<regex> # Look for differences whose patch text contains added/removed lines that match <regex>
  --find-object=<object-id> # Look for differences that change the number of occurrences of the specified object
  --pickaxe-all # When -S or -G finds a change, show all the changes in that changeset, not just the files that contain the change in <string>
  --pickaxe-regex # Treat the <string> given to -S as an extended POSIX regular expression to match
  -O<orderfile> # Control the order in which files appear in the output
     <orderfile> is parsed as follows:
     - Blank lines are ignored, so they can be used as separators for readability
     - Lines starting with a hash ("#") are ignored, so they can be used for comments. Add a backslash ("\\") to the beginning of the pattern if it starts with a hash
     - Each other line contains a single pattern

  -R # Swap two inputs; that is, show differences from index or on-disk file to tree contents
  --relative[=<path>] # When run from a subdirectory of the project, it can be told to exclude changes outside the directory and show pathnames relative to it with this option
  -a, --text # Treat all files as text
  --ignore-cr-at-eol # Ignore carriage-return at the end of line when doing a comparison
  --ignore-space-at-eol # Ignore changes in whitespace at EOL
  -b, --ignore-space-change # Ignore changes in amount of whitespace
  -w, --ignore-all-space # Ignore whitespace when comparing lines
  --ignore-blank-lines # Ignore changes whose lines are all blank
  --inter-hunk-context=<lines> # Show the context between diff hunks, up to the specified number of lines, thereby fusing hunks that are close to each other
  -W, --function-context # Show whole surrounding functions of changes
  --ext-diff # Allow an external diff helper to be executed
  --no-ext-diff # Disallow external diff drivers
  --textconv, --no-textconv # Allow (or disallow) external text conversion filters to be run when comparing binary files
  --ignore-submodules[=<when>] # Ignore changes to submodules in the diff generation
  --src-prefix=<prefix> # Show the given source prefix instead of "a/"
  --dst-prefix=<prefix> # Show the given destination prefix instead of "b/"
  --no-prefix # Do not show any source or destination prefix
  --line-prefix=<prefix> # Prepend an additional prefix to every line of output
  --ita-invisible-in-index # By default entries added by "git add -N" appear as an existing empty file in "git diff" and a new file in "git diff --cached"

EXAMPLES

git log --no-merges
   Show the whole commit history, but skip any merges

git log v2.6.12.. include/scsi drivers/scsi
   Show all commits since version v2.6.12 that changed any file in the include/scsi or drivers/scsi subdirectories

git log --since="2 weeks ago" -- gitk
   Show the changes during the last two weeks to the file gitk. The -- is necessary to avoid confusion with the branch named gitk

git log --name-status release..test
   Show the commits that are in the "test" branch but not yet in the "release" branch, along with the list of paths each commit modifies

git log --follow builtin/rev-list.c
   Shows the commits that changed builtin/rev-list.c, including those commits that occurred before the file was given its present name

git log --branches --not --remotes=origin
   Shows all commits that are in any of local branches but not in any of remote-tracking branches for origin (what you have that origin doesn’t)

git log master --not --remotes=*/master
   Shows all commits that are in local master but not in any remote repository master branches

git log -p -m --first-parent
   Shows the history including change diffs, but only from the “main branch” perspective, skipping commits that come from merged branches, and showing full diffs of changes introduced by the merges. This makes sense only when following
   a strict policy of merging all topic branches when staying on a single integration branch

git log -L '/int main/',/^}/:main.c
   Shows how the function main() in the file main.c evolved over time

git log -3
   Limits the number of commits to show to 3

TRICK

# show all logs
git log
  -p -2 # show diff between two last commit
  -U1 --word-diff # show diff in line

  --stat # show statistics
  --pretty=oneline
  --pretty=short
  --pretty=full
  --pretty=fuller
  --pretty=format:"%h - %an, %ar : %s"

Switch branches or restore working tree files

# To prepare for working on <branch>, switch to it by updating the index and the files in the working tree, and by pointing HEAD at the branch
git checkout [<branch>]

#Specifying -b causes a new branch to be created as if git-branch(1) were called and then checked out
git checkout -b|-B <new_branch> [<start point>]

# Prepare to work on top of <commit>, by detaching HEAD at it (see "DETACHED HEAD" section), and updating the index and the files in the working tree
git checkout --detach [<branch>], git checkout [--detach] <commit>

# Overwrite the contents of the files that match the pathspec. When the <tree-ish> (most often a commit) is not given, overwrite working tree with the contents in the index
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <pathspec>..., git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] --pathspec-from-file=<file> [--pathspec-file-nul]

# similar to the previous mode, but lets you use the interactive interface to show the "diff" output and choose which hunks to use in the result
git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>...]

  -q, --quiet # Quiet, suppress feedback messages
  --progress, --no-progress # Progress status is reported on the standard error stream by default when it is attached to a terminal, unless --quiet is specified
  -f, --force # When switching branches, proceed even if the index or the working tree differs from HEAD. This is used to throw away local changes
  --ours, --theirs # When checking out paths from the index, check out stage #2 (ours) or #3 (theirs) for unmerged paths
  -b <new_branch> # Create a new branch named <new_branch> and start it at <start_point>
  -B <new_branch> # Creates the branch <new_branch> and start it at <start_point>; if it already exists, then reset it to <start_point>. This is equivalent to running "git branch" with "-f"
  -t, --track # When creating a new branch, set up "upstream" configuration. See "--track" in git-branch(1) for details. If no -b option is given, the name of the new branch will be derived from the remote-tracking branch, by looking at the local part of the refspec configured for the corresponding remote, and then stripping the initial part up to the "*"
  --no-track # Do not set up "upstream" configuration, even if the branch.autoSetupMerge configuration variable is true
  --guess, --no-guess # If <branch> is not found but there does exist a tracking branch in exactly one remote (call it <remote>) with a matching name, treat as equivalent to $ git checkout -b <branch> --track <remote>/<branch>
  -l # Create the new branch’s reflog
  --detach # Rather than checking out a branch to work on it, check out a commit for inspection and discardable experiments
  --orphan <new_branch> # Create a new orphan branch, named <new_branch>, started from <start_point> and switch to it
  --ignore-skip-worktree-bits # In sparse checkout mode, git checkout -- <paths> would update only entries matched by <paths> and sparse patterns in $GIT_DIR/info/sparse-checkout
  -m, --merge # a three-way merge between the current branch, your working tree contents, and the new branch is done, and you will be on the new branch
  --conflict=<style> # The same as --merge option above, but changes the way the conflicting hunks are presented, overriding the merge.conflictStyle configuration variable
  -p, --patch # Interactively select hunks in the difference between the <tree-ish> (or the index, if unspecified) and the working tree
  --ignore-other-worktrees # git checkout refuses when the wanted ref is already checked out by another worktree. This option makes it check the ref out anyway. In other words, the ref can be held by more than one worktree
  --overwrite-ignore, --no-overwrite-ignore # Silently overwrite ignored files when switching branches. This is the default behavior. Use --no-overwrite-ignore to abort the operation when the new branch contains ignored files
  --recurse-submodules, --no-recurse-submodules # Using --recurse-submodules will update the content of all initialized submodules according to the commit recorded in the superproject
  --overlay, --no-overlay # In the default overlay mode, git checkout never removes files from the index or the working tree
  --pathspec-from-file=<file> # Pathspec is passed in <file> instead of commandline args
  --pathspec-file-nul # Only meaningful with --pathspec-from-file. Pathspec elements are separated with NUL character and all other characters are taken literally (including newlines and quotes)
  <branch> # Branch to checkout; if it refers to a branch (i.e., a name that, when prepended with "refs/heads/", is a valid ref), then that branch is checked out. Otherwise, if it refers to a valid commit, your HEAD becomes "detached" and you are no longer on any branch
  <new_branch> # Name for the new branch
  <start_point> # The name of a commit at which to start the new branch. Defaults to HEAD
  <tree-ish> # Tree to checkout from (when paths are given). If not specified, the index will be used
  -- # Do not interpret any more arguments as options
  <pathspec>... # Limits the paths affected by the operation

USED

checkout a remote branch

In order to checkout a remote branch you have to first fetch the contents of the branch

git fetch --all
# or
# git fetch <repo> <branch>

Checkout the remote branch

# In modern versions of Git, you can then checkout the remote branch like a local branch
git checkout <remotebranch>

# Older versions of Git require the creation of a new branch based on the remote
git checkout <remotebranch> <repo>/<remotebranch>

Checkout the local branch

# Additionally you can checkout a new local branch and reset it to the remote branches last commit
git checkout -b <branch> && git reset --hard origin/<branch>

Show changes between commits, commit and working tree, etc

Show changes between the working tree and the index or a tree, changes between the index and a tree, changes between two trees, changes between two blob objects, or changes between two files on disk

# view the changes you made relative to the index (staging area for the next commit)
git diff [<options>] [--] [<path>...]

# compare the given two paths on the filesystem
git diff [<options>] --no-index [--] <path> <path>

# view the changes you staged for the next commit relative to the named <commit>
git diff [<options>] --cached [<commit>] [--] [<path>...]

# view the changes you have in your working tree relative to the named <commit>
git diff [<options>] <commit> [--] [<path>...]

# view the changes between two arbitrary <commit>
git diff [<options>] <commit> <commit> [--] [<path>...]
git diff [<options>] <commit>..<commit> [--] [<path>...]

# view the changes on the branch containing and up to the second <commit>, starting at a common ancestor of both <commit>
git diff [<options>] <commit>...<commit> [--] [<path>...]

  -p, -u, --patch # Generate patch (see section on generating patches). This is the default
  -s, --no-patch # Suppress diff output. Useful for commands like git show that show the patch by default, or to cancel the effect of --patch
  -U<n>, --unified=<n> # Generate diffs with <n> lines of context instead of the usual three. Implies --patch. Implies -p
  --output=<file> # Output to a specific file instead of stdout
  --output-indicator-new=<char>, --output-indicator-old=<char>, --output-indicator-context=<char> # Specify the character used to indicate new, old or context lines in the generated patch. Normally they are +, - and ' ' respectively
  --raw # Generate the diff in raw format
  --patch-with-raw # Synonym for -p --raw
  --indent-heuristic # Enable the heuristic that shifts diff hunk boundaries to make patches easier to read. This is the default
  --no-indent-heuristic # Disable the indent heuristic
  --minimal # Spend extra time to make sure the smallest possible diff is produced
  --patience # Generate a diff using the "patience diff" algorithm
  --histogram # Generate a diff using the "histogram diff" algorithm
  --anchored=<text> # Generate a diff using the "anchored diff" algorithm
  --diff-algorithm={patience|minimal|histogram|myers} # Choose a diff algorithm. The variants are as follows:
      default, myers # The basic greedy diff algorithm. Currently, this is the default
      minimal # Spend extra time to make sure the smallest possible diff is produced
      patience # Use "patience diff" algorithm when generating patches
      histogram # This algorithm extends the patience algorithm to "support low-occurrence common elements"
  --stat[=<width>[,<name-width>[,<count>]]] # Generate a diffstat
  --compact-summary # Output a condensed summary of extended header information such as file creations or deletions ("new" or "gone", optionally "+l" if it’s a symlink) and mode changes ("+x" or "-x" for adding or removing executable bit respectively) in diffstat
  --numstat # Similar to --stat, but shows number of added and deleted lines in decimal notation and pathname without abbreviation, to make it more machine friendly
  --shortstat # Output only the last line of the --stat format containing total number of modified files, as well as number of added and deleted lines
  -X[<param1,param2,...>], --dirstat[=<param1,param2,...>] # Output the distribution of relative amount of changes for each sub-directory. The behavior of --dirstat can be customized by passing it a comma separated list of parameters. The following parameters are available:
      changes #  # Compute the dirstat numbers by counting the lines that have been removed from the source, or added to the destination
      lines # Compute the dirstat numbers by doing the regular line-based diff analysis, and summing the removed/added line counts
      files # Compute the dirstat numbers by counting the number of files changed. Each changed file counts equally in the dirstat analysis
      cumulative # Count changes in a child directory for the parent directory as well
      <limit> # An integer parameter specifies a cut-off percent (3% by default)
  --dirstat-by-file[=<param1,param2>...] # Synonym for --dirstat=files,param1,param2...
  --summary # Output a condensed summary of extended header information such as creations, renames and mode changes
  --patch-with-stat # Synonym for -p --stat
  -z # When --raw, --numstat, --name-only or --name-status has been given, do not munge pathnames and use NULs as output field terminators
  --name-only # Show only names of changed files
  --name-status # Show only names and status of changed files. See the description of the --diff-filter option on what the status letters mean
  --submodule[=<format>] # Specify how differences in submodules are shown. When specifying --submodule=short the short format is used
  --color[=<when>] # Show colored diff.  --color (i.e. without =<when>) is the same as --color=always
  --no-color # Turn off colored diff. This can be used to override configuration settings. It is the same as --color=never
  --color-moved[=<mode>] # Moved lines of code are colored differently. <mode> defaults to no. The mode must be one of:
      no # Moved lines are not highlighted
      default # Is a synonym for zebra. This may change to a more sensible mode in the future
      plain # Any line that is added in one location and was removed in another location will be colored with color.diff.newMoved
      blocks # Blocks of moved text of at least 20 alphanumeric characters are detected greedily
      zebra # Blocks of moved text are detected as in blocks mode
      dimmed-zebra # Similar to zebra, but additional dimming of uninteresting parts of moved code is performed
  --no-color-moved-ws # Do not ignore whitespace when performing move detection. This can be used to override configuration settings
  --word-diff[=<mode>] # Show a word diff, using the <mode> to delimit changed words. The <mode> defaults to plain, and must be one of:
      color # Highlight changed words using only colors. Implies --color
      plain # Show words as [-removed-] and {+added+}
      porcelain # Use a special line-based format intended for script consumption
      none # Disable word diff again
  --word-diff-regex=<regex> # Use <regex> to decide what a word is, instead of considering runs of non-whitespace to be a word
  --color-words[=<regex>] # Equivalent to --word-diff=color plus (if a regex was specified) --word-diff-regex=<regex>
  --no-renames # Turn off rename detection, even when the configuration file gives the default to do so
  --[no-]rename-empty # Whether to use empty blobs as rename source
  --check # Warn if changes introduce conflict markers or whitespace errors. What are considered whitespace errors is controlled by core
  --ws-error-highlight=<kind> # Highlight whitespace errors in the context, old or new lines of the diff
  --full-index # Instead of the first handful of characters, show the full pre- and post-image blob object names on the "index" line when generating patch format output
  --binary # In addition to --full-index, output a binary diff that can be applied with git-apply. Implies --patch
  --abbrev[=<n>] # Instead of showing the full 40-byte hexadecimal object name in diff-raw format output and diff-tree header lines, show only a partial prefix
  -B[<n>][/<m>], --break-rewrites[=[<n>][/<m>]] # Break complete rewrite changes into pairs of delete and create
  -M[<n>], --find-renames[=<n>] # Detect renames. If n is specified, it is a threshold on the similarity index (i.e. amount of addition/deletions compared to the file’s size)
  -C[<n>], --find-copies[=<n>] # Detect copies as well as renames
  --find-copies-harder # For performance reasons, by default, -C option finds copies only if the original file of the copy was modified in the same changeset
  -D, --irreversible-delete # Omit the preimage for deletes, i.e. print only the header but not the diff between the preimage and /dev/null
  -l<num> # The -M and -C options require O(n^2) processing time where n is the number of potential rename/copy targets
  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]] # Select only files that are Added (A), Copied (C), Deleted (D), Modified (M), Renamed (R), have their type (i.e. regular file, symlink, submodule, ...) changed (T), are Unmerged (U), are Unknown (X), or have had their pairing Broken (B)
  -S<string> # Look for differences that change the number of occurrences of the specified string (i.e. addition/deletion) in a file
  -G<regex> # Look for differences whose patch text contains added/removed lines that match <regex>
  --find-object=<object-id> # Look for differences that change the number of occurrences of the specified object
  --pickaxe-all # When -S or -G finds a change, show all the changes in that changeset, not just the files that contain the change in <string>
  --pickaxe-regex # Treat the <string> given to -S as an extended POSIX regular expression to match
  -O<orderfile> # Control the order in which files appear in the output. <orderfile> is parsed as follows:
      - Blank lines are ignored, so they can be used as separators for readability
      - Lines starting with a hash ("#") are ignored, so they can be used for comments. Add a backslash ("\\") to the beginning of the pattern if it starts with a hash
      - Each other line contains a single pattern
  -R # Swap two inputs; that is, show differences from index or on-disk file to tree contents
  --relative[=<path>] # When run from a subdirectory of the project, it can be told to exclude changes outside the directory and show pathnames relative to it with this option
  -a, --text # Treat all files as text
  --ignore-cr-at-eol # Ignore carriage-return at the end of line when doing a comparison
  --ignore-space-at-eol # Ignore changes in whitespace at EOL
  --ignore-space-at-eol # Ignore changes in whitespace at EOL
  -b, --ignore-space-change # Ignore changes in amount of whitespace
  -w, --ignore-all-space # Ignore whitespace when comparing lines
  --ignore-blank-lines # Ignore changes whose lines are all blank
  --inter-hunk-context=<lines> # Show the context between diff hunks, up to the specified number of lines, thereby fusing hunks that are close to each other
  -W, --function-context # Show whole surrounding functions of changes
  --exit-code # Make the program exit with codes similar to diff(1). That is, it exits with 1 if there were differences and 0 means no differences
  --quiet # Disable all output of the program. Implies --exit-code
  --ext-diff # Allow an external diff helper to be executed. If you set an external diff driver with gitattributes(5), you need to use this option with git-log(1) and friends
  --no-ext-diff # Disallow external diff drivers
  --textconv, --no-textconv # Allow (or disallow) external text conversion filters to be run when comparing binary files
  --ignore-submodules[=<when>] # Ignore changes to submodules in the diff generation
  --src-prefix=<prefix> # Show the given source prefix instead of "a/"
  --dst-prefix=<prefix> # Show the given destination prefix instead of "b/"
  --no-prefix # Do not show any source or destination prefix
  --line-prefix=<prefix> # Prepend an additional prefix to every line of output
  --ita-invisible-in-index # By default entries added by "git add -N" appear as an existing empty file in "git diff" and a new file in "git diff --cached"
  -1 --base, -2 --ours, -3 --theirs # Compare the working tree with the "base" version (stage #1), "our branch" (stage #2) or "their branch" (stage #3)
  -0 # Omit diff output for unmerged entries and just show "Unmerged". Can be used only when comparing the working tree with the index
  <path>... # The <paths> parameters, when given, are used to limit the diff to the named paths (you can give directory names and get diff for all files under them)

USED

# show diff staged / repo
git diff --staged

Remove files from the working tree and from the index

Remove files from the index, or from the working tree and the index. git rm will not remove a file from just your working directory. (There is no option to remove a file only from the working tree and yet keep it in the index; use /bin/rm if you want to do that.) The files being removed have to be identical to the tip of the branch, and no updates to their contents can be staged in the index, though that default behavior can be overridden with the -f option. When --cached is given, the staged content has to match either the tip of the branch or the file on disk, allowing the file to be removed from just the index

git rm [-f | --force] [-n] [-r] [--cached] [--ignore-unmatch] [--quiet] [--] <file>...

  <file>... # Files to remove. Fileglobs (e.g.  *.c) can be given to remove all matching files. If you want Git to expand file glob characters, you may need to shell-escape them
  -f, --force # Override the up-to-date check
  -n, --dry-run # Don’t actually remove any file(s). Instead, just show if they exist in the index and would otherwise be removed by the command
  -r # Allow recursive removal when a leading directory name is given
  -- # This option can be used to separate command-line options from the list of files, (useful when filenames might be mistaken for command-line options)
  --cached # Use this option to unstage and remove paths only from the index. Working tree files, whether modified or not, will be left alone
  --ignore-unmatch # Exit with a zero status even if no files matched
  -q, --quiet # git rm normally outputs one line (in the form of an rm command) for each file removed. This option suppresses that output

Add file contents to the index

This command updates the index using the current content found in the working tree, to prepare the content staged for the next commit. It typically adds the current content of existing paths as a whole, but with some options it can also be used to add content with only part of the changes made to the working tree files applied, or remove paths that do not exist in the working tree anymore

git add [--verbose | -v] [--dry-run | -n] [--force | -f] [--interactive | -i] [--patch | -p] [--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]] [--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing] [--renormalize] [--chmod=(+|-)x] [--pathspec-from-file=<file> [--pathspec-file-nul]] [--] [<pathspec>...]

  <pathspec>... # Files to add content from. Fileglobs (e.g.  *.c) can be given to add all matching files
  -n, --dry-run # Don’t actually add the file(s), just show if they exist and/or will be ignored
  -v, --verbose # Be verbose
  -f, --force # Allow adding otherwise ignored files
  -i, --interactive # Add modified contents in the working tree interactively to the index. Optional path arguments may be supplied to limit operation to a subset of the working tree
  -p, --patch # Interactively choose hunks of patch between the index and the work tree and add them to the index
  -e, --edit # Open the diff vs. the index in an editor and let the user edit it
  -u, --update # Update the index just where it already has an entry matching <pathspec>
  -A, --all, --no-ignore-removal # Update the index not only where the working tree has a file matching <pathspec> but also where the index already has an entry
  --no-all, --ignore-removal # Update the index by adding new files that are unknown to the index and files modified in the working tree, but ignore files that have been removed from the working tree
  -N, --intent-to-add # Record only the fact that the path will be added later. An entry for the path is placed in the index with no content
  --refresh # Don’t add the file(s), but only refresh their stat() information in the index
  --ignore-errors # If some files could not be added because of errors indexing them, do not abort the operation, but continue adding the others
  --ignore-missing # This option can only be used together with --dry-run
  --no-warn-embedded-repo # By default, git add will warn when adding an embedded repository to the index without using git submodule add to create an entry in .gitmodules
  --renormalize # Apply the "clean" process freshly to all tracked files to forcibly add them again to the index
  --chmod=(+|-)x # Override the executable bit of the added files
  --pathspec-from-file=<file> # Pathspec is passed in <file> instead of commandline args
  --pathspec-file-nul # Only meaningful with --pathspec-from-file
  -- # This option can be used to separate command-line options from the list of files, (useful when filenames might be mistaken for command-line options)

SHOW

Show a reference to an object or a list of objects may be passed to examine those specific objects

Shows one or more objects (blobs, trees, tags and commits)

• For commits it shows the log message and textual diff. It also presents the merge commit in a special format as produced by git diff-tree --cc
• For tags, it shows the tag message and the referenced objects
• For trees, it shows the names (equivalent to git ls-tree with --name-only)
• For plain blobs, it shows the plain contents

git show [<options>] [<object>...]

  --pretty[=<format>] # displays more or less information depending on the format chosen: oneline, short, medium, full, fuller, email, raw, string. default is medium
  --abbrev-commit # shortens the length of output commit IDs. With --pretty=oneline can produce a highly succinct git log output
  --no-abbrev-commit # Show the full 40 character commit ID
  --oneline # uses the expanded command --pretty=oneline --abbrev-commit
  --encoding[=<encoding>] # Character encoding on Git log messages defaults to UTF-8
  --expand-tabs=<n> # replace tab characters with <n> spaces in the log message output 
  --expand-tabs # replace tab characters with 8 default spaces
  --no-expand-tabs # replace tab characters with 0 space
  --notes=<ref> # filters notes with <ref>
  --no-notes # hide notes in output
  --show-signature # show signature if commit are signed with gpg key

SHOW-BRANCH

Show branches and their commits

Shows the commit ancestry graph starting from the commits named with <rev>s or <glob>s (or all refs under refs/heads and/or refs/tags) semi-visually

git show-branch [-a|--all] [-r|--remotes] [--topo-order | --date-order] [--current] [--color[=<when>] | --no-color] [--sparse] [--more=<n> | --list | --independent | --merge-base] [--no-name | --sha1-name] [--topics] [(<rev> | <glob>)...]
git show-branch (-g|--reflog)[=<n>[,<base>]] [--list] [<ref>]

  <rev> # Arbitrary extended SHA-1 expression (see gitrevisions(7)) that typically names a branch head or a tag
  <glob> # A glob pattern that matches branch or tag names under refs/. For example, if you have many topic branches under refs/heads/topic, giving topic/* would show all of them
  -r, --remotes # Show the remote-tracking branches
  -a, --all # Show both remote-tracking branches and local branches
  --current # With this option, the command includes the current branch to the list of revs to be shown when it is not given on the command line
  --topo-order # By default, the branches and their commits are shown in reverse chronological order. This option makes them appear in topological order (i.e., descendant commits are shown before their parents)
  --date-order # This option is similar to --topo-order in the sense that no parent comes before all of its children, but otherwise commits are ordered according to their commit date
  --sparse # By default, the output omits merges that are reachable from only one tip being shown. This option makes them visible
  --more=<n> # Usually the command stops output upon showing the commit that is the common ancestor of all the branches. This flag tells the command to go <n> more common commits beyond that
  --list # Synonym to --more=-1
  --merge-base # Instead of showing the commit list, determine possible merge bases for the specified commits
  --independent # Among the <reference>s given, display only the ones that cannot be reached from any other <reference>
  --no-name # Do not show naming strings for each commit
  --sha1-name # Instead of naming the commits using the path to reach them from heads (e.g. "master~2" to mean the grandparent of "master"), name them with the unique prefix of their object names
  --topics # Shows only commits that are NOT on the first branch given. This helps track topic branches by hiding any commit that is already in the main line of development
  -g, --reflog[=<n>[,<base>]] [<ref>] # Shows <n> most recent ref-log entries for the given ref. If <base> is given, <n> entries going back from that entry. <base> can be specified as count or date. When no explicit <ref> parameter is given, it defaults to the current branch (or HEAD if it is detached)
  --color[=<when>] # Color the status sign (one of these: * !  + -) of each commit corresponding to the branch it’s in
  --no-color # Turn off colored output, even when the configuration file gives the default to color output

Clone a repository into a new directory

Clones a repository into a newly created directory, creates remote-tracking branches for each branch in the cloned repository (visible using git branch --remotes), and creates and checks out an initial branch that is forked from the cloned repository’s currently active branch

The following syntaxes may be used with them:

• ssh://[user@]host.xz[:port]/path/to/repo.git/
• git://host.xz[:port]/path/to/repo.git/
• http[s]://host.xz[:port]/path/to/repo.git/
• ftp[s]://host.xz[:port]/path/to/repo.git/

The ssh and git protocols additionally support ~username expansion:

• ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/
• git://host.xz[:port]/~[user]/path/to/repo.git/
• [user@]host.xz:/~[user]/path/to/repo.git/

For local repositories, the following syntaxes may be used:

• /path/to/repo.git/
• file:///path/to/repo.git/

git clone [--template=<template_directory>] [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror] [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>] [--dissociate] [--separate-git-dir <git dir>] [--depth <depth>] [--[no-]single-branch] [--no-tags] [--recurse-submodules[=<pathspec>]] [--[no-]shallow-submodules] [--[no-]remote-submodules] [--jobs <n>] [--sparse] [--] <repository> [<directory>]

  -l, --local # When the repository to clone from is on a local machine, this flag bypasses the normal "Git aware" transport mechanism and clones the repository by making a copy of HEAD and everything under objects and refs directories
  --no-hardlinks # Force the cloning process from a repository on a local filesystem to copy the files under the .git/objects directory instead of using hardlinks. This may be desirable if you are trying to make a back-up of your repository
  -s, --shared # When the repository to clone is on the local machine, instead of using hard links, automatically setup .git/objects/info/alternates to share the objects with the source repository
  --reference[-if-able] <repository> # If the reference repository is on the local machine, automatically setup .git/objects/info/alternates to obtain objects from the reference repository
  --dissociate # Borrow the objects from reference repositories specified with the --reference options only to reduce network transfer, and stop borrowing from them after a clone is made by making necessary local copies of borrowed objects
  -q, --quiet # Operate quietly. Progress is not reported to the standard error stream
  -v, --verbose # Run verbosely. Does not affect the reporting of progress status to the standard error stream
  --progress # Progress status is reported on the standard error stream by default when it is attached to a terminal, unless --quiet is specified. This flag forces progress status even if the standard error stream is not directed to a terminal
  --server-option=<option> # Transmit the given string to the server when communicating using protocol version 2. The given string must not contain a NUL or LF character
  -n, --no-checkout # No checkout of HEAD is performed after the clone is complete
  --bare # Make a bare Git repository. That is, instead of creating <directory> and placing the administrative files in <directory>/.git, make the <directory> itself the $GIT_DIR
  --sparse # Initialize the sparse-checkout file so the working directory starts with only the files in the root of the repository. The sparse-checkout file can be modified to grow the working directory as needed
  --mirror # Set up a mirror of the source repository
  -o <name>, --origin <name> # Instead of using the remote name origin to keep track of the upstream repository, use <name>
  -b <name>, --branch <name> # Instead of pointing the newly created HEAD to the branch pointed to by the cloned repository’s HEAD, point to <name> branch instead
  -u <upload-pack>, --upload-pack <upload-pack> # When given, and the repository to clone from is accessed via ssh, this specifies a non-default path for the command run on the other end
  --template=<template_directory> # Specify the directory from which templates will be used; (See the "TEMPLATE DIRECTORY" section of git-init(1).)
  -c <key>=<value>, --config <key>=<value> # Set a configuration variable in the newly-created repository; this takes effect immediately after the repository is initialized, but before the remote history is fetched or any files checked out
  --depth <depth> # Create a shallow clone with a history truncated to the specified number of commits
  --shallow-since=<date> # Create a shallow clone with a history after the specified time
  --shallow-exclude=<revision> # Create a shallow clone with a history, excluding commits reachable from a specified remote branch or tag. This option can be specified multiple times
  --[no-]single-branch # Clone only the history leading to the tip of a single branch, either specified by the --branch option or the primary branch remote’s HEAD points at. Further fetches into the resulting repository will only update the remote-tracking branch for the branch this option was used for the initial cloning. If the HEAD at the remote did not point at any branch when --single-branch clone was made, no remote-tracking branch is created
  --no-tags # Don’t clone any tags, and set remote.<remote>.tagOpt=--no-tags in the config, ensuring that future git pull and git fetch operations won’t follow any tags
  --recurse-submodules[=<pathspec] # After the clone is created, initialize and clone submodules within based on the provided pathspec
  --[no-]shallow-submodules # All submodules which are cloned will be shallow with a depth of 1
  --[no-]remote-submodules # All submodules which are cloned will use the status of the submodule’s remote-tracking branch to update the submodule, rather than the superproject’s recorded SHA-1. Equivalent to passing --remote to git submodule update
  --separate-git-dir=<git dir> # Instead of placing the cloned repository where it is supposed to be, place the cloned repository at the specified directory, then make a filesystem-agnostic Git symbolic link to there
  -j <n>, --jobs <n> # The number of submodules fetched at the same time. Defaults to the submodule.fetchJobs option
  <repository> # The (possibly remote) repository to clone from. See the GIT URLS section below for more information on specifying repositories
  <directory> # The name of a new directory to clone into. The "humanish" part of the source repository is used if no directory is explicitly given (repo for /path/to/repo.git and foo for host.xz:foo/.git)

USED

git://$urlrepo # clone a repository
git://$urlrepo <alias> # clone a repository & give it an alias

Get and set repository or global options

You can query/set/replace/unset options with this command. The name is actually the section and the key separated by a dot, and the value will be escaped

git config [<file-option>] [--type=<type>] [--show-origin] [-z|--null] name [value [value_regex]]
git config [<file-option>] [--type=<type>] --add name value
git config [<file-option>] [--type=<type>] --replace-all name value [value_regex]
git config [<file-option>] [--type=<type>] [--show-origin] [-z|--null] --get name [value_regex]
git config [<file-option>] [--type=<type>] [--show-origin] [-z|--null] --get-all name [value_regex]
git config [<file-option>] [--type=<type>] [--show-origin] [-z|--null] [--name-only] --get-regexp name_regex [value_regex]
git config [<file-option>] [--type=<type>] [-z|--null] --get-urlmatch name URL
git config [<file-option>] --unset name [value_regex]
git config [<file-option>] --unset-all name [value_regex]
git config [<file-option>] --rename-section old_name new_name
git config [<file-option>] --remove-section name
git config [<file-option>] [--show-origin] [-z|--null] [--name-only] -l | --list
git config [<file-option>] --get-color name [default]
git config [<file-option>] --get-colorbool name [stdout-is-tty]
git config [<file-option>] -e | --edit

  --local # write to the repository .git/config file
  --global # write to global ~/.gitconfig
  --system # write to system-wide $(prefix)/etc/gitconfig
  -e, --edit # opens an editor to modify the specified config file
  --replace-all # Default behavior is to replace at most one line. This replaces all lines matching the key
  --add # adds a new line to the option without altering any existing values
  --get key [value-regex] # print the value of the key where the key corresponds exactly and the value if necessary with the pattern
  --get-all key [value-regex] # same as --get but return all values
  --get-regexp key-regex [value-regex] # print all "key value" pairs whose key/value pair corresponds to its pattern
  --get-urlmatch section[.var] URL # when given a two-part name section.key, the value for section.<url>.key whose <url> part matches the best to the given URL is returned (if no such key exists, the value for section.key is used as a fallback)
  --worktree # similar to --local except that .git/config.worktree is read from or written to if extensions.worktreeConfig is present
  -f config-file, --file config-file # use the given config file instead of the one specified by GIT_CONFIG
  --blob blob # similar to --file but use the given blob instead of a file
  --remove-section # remove the given section from the configuration file
  --rename-section # rename the given section to a new name
  --unset # remove the line matching the key from config file
  --unset-all # remove all lines matching the key from config file
  -l, --list # list all variables set in config file, along with their values
  --type <type> # ensure that any input or output is valid under the given type constraint(s)
    bool / int / bool-or-int / path / expiry-date / color
  -z, --null # output values and/or keys, always end values with the null character (instead of a newline)
  --name-only # output only the names of config variables for --list or --get-regexp
  --show-origin # Augment the output of all queried config options with the origin type and the actual origin

USED

git config

  --system core.editor vim # set the default editor
  --system merge.tool meld # set the default editor/viewer for diff
  --global user.name "aguy tech" # set the name of user
  --global user.email "aguytech@free.fr" # set the email of user

  -l # print all configurations
  -l --system # print system configurations
  -l user.email # print values of configuration for a name
  --get-all core.editor # print all defined values (local, global, system) for the key 'core.editor'