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

https://www.atlassian.com/fr/git/tutorials
https://git-scm.com/docs

TOC

REFERENCE

^

URL

^

https://<fqdn>/<user>/<project> # https://github.com/aguytech/Shaarli
git@<fqdn>:<user>/<project>.git # git@github.com:aguytech/Shaarli.git

VALUES

^

git rev-parse --symbolic-full-name --abbrev-ref @{upstream} # print value for upstream
git rev-parse --symbolic-full-name --abbrev-ref @{push} # print value for push

git for-each-ref --format='%(refname:short) <- %(upstream:short)' refs/heads # show all upstream
git for-each-ref --format='%(upstream:short)' "$(git symbolic-ref -q HEAD)" # idem

git for-each-ref --format='%(refname:short) <- %(push:short)' refs/heads # show all upstream
git for-each-ref --format='%(push:short)' "$(git symbolic-ref -q HEAD)" # idem

USED

^

ADD

^

git add -i / --interactive # add with interactively mode
git add -u / --update # Update the index for already referred files (just where it already has an entry matching <pathspec>
gi add -A / --all / --no-ignore-removal # add all files

ARCHIVE

^

git archive -l # list available formats
git archive --format tar.gz -9 -o "$(git br --show-current).$(date +%s).tar.gz" <branch> # create an archive from local <branch> with best compression -9 & in format tar.gz

BRANCH

^

https://stackoverflow.com/questions/11266478/git-add-remote-branch

list

git branch / git br # print list of local branches
git br -v # print informations about local branches
git br -vv # print full information about local branches
git branch -a -vv # print full information about all branches
git br --show-current # show name of current branch

git br -r # print list of remote branches for all repositories
git br -rlv <remote>/<pattern> # list remote branches for <remote> repository & with name matched <pattern>

create/delete

git br <branch> # create a local branch
git br <branch> <remote>/<remote_branch> # create local branch from remote

git br -u <remote>/<remote_branch> <branch> # attach a local branch to remote existing one
git br --set-upstream-to=<remote>/<remote_branch> <branch> # idem
# Equal to: git checkout <branch> && git push --set-upstream <remote> <branch>

git br -m <branch> <new_branch># rename local branch && 'git push'

git br -d <branch> # delete local branch
git br -rd <remote>/<branch> # delete remote branch

CHECKOUT

^

git co -b <branch> # create a branch from HEAD and switch to it
git co -t <repo>/<branch> -b <branch> # create a local branch from <repo>/<branch>
git co --orphan=<branch> # create an orphan branch (whithout history)
git co --orphan=<branch> # create an orphan branch (whithout history)
git co --detach -b <branch> # check out a commit for inspection and discardable experiments

CLONE

^

git clone <url> # clone a repository
git clone <url> <alias> # clone a repository & give it an alias

git clone -b <branch> <url> # clone only one branch from repository

git clone -b v0.11-snippets --single-branch --no-tags git@github.com:aguytech/Shaarli.git shaarli-snippets # clone from a repository a single branch

COMMIT

^

# amend
git commit --amend --no-edit # amends a commit without changing its commit message
git commit --amend -m "message" # amends a commit with a new message

CONFIG

^

# amend
git config <variable> # show variable and his value
git config --global core.editor vim # set selected editor

git config -l # list all config variables
git config -l --show-origin # list all config variables with their origins
git config -l --name-only # list all names of system config variables

git config -l --local # list all config variables defined for user
git config -l --global # list all global config variables for global users
git config -l --system # list all system config variables for system

LOG

^

git log # show logs
git log -n3 <repo>/<branch> # show only last 23 lines of logs
git log --pretty=format:'%h' -n1 <repo>/<branch> # show short sha of last commit
git log --name-only # with file names
git log --name-status # with file names with its status
git log --stat # with file names with its statisticals

git reflog # show logs with a reference (sha) view

MERGE

^

git merge -m "message" <branch> # merge branch with actual one with a message to committing

git merge --allow-unrelated-histories <branch> # allows to merge branch with no common history

PULL

^

If you tried a pull which resulted in complex conflicts and would want to start over, you can recover with git reset

git pull # Update actual local branch from current remote
git pull <remote> # Update actual local branch from a selected remote

git pull <remote> <branch> # Merge into the current branch the remote branch
<=>
git fetch origin
git merge origin/next

git pull --rebase # pull automatically last modifications on remote (with fetch + merge) & put your validation on head directly

pull all submodules

git submodule foreach git pull
git submodule foreach git pull origin master
git submodule foreach 'git pull origin master || true' # for some submodules without updates"

PUSH

^

git push -u <remote> <branch> # set upstream for actual local branch & push it to remote (create one if needed), while you created a local branch to local and you want to push to another repository !
git push --tags # push tags also

git push -d <remote> <branch> # delete remote branch

REMOTE

^

git remote rename <name> <new_name> # rename a remote source
git remote add <name> <url> # add a remote source to repository
git remote add -t <branch> <name> <url> # add only a branch from a repository like source
git remote remove <name> # remove/delete a remote source to repository

RESET

^

git reset --merge # resets the index and updates the files in the working tree that are different between <commit> and HEAD

git reset --hard <commit_sha> # reset branch to commit_sha, 'git reflog' is an better way to find commit_sha
git reset --hard HEAD~1

SWITCH

^

TAG

^

git tag -l # List all tags
git tag -a -m "message" # Defines an unsigned, annoted tag
git tag -s "tag" -m "message" # Creates a signed tag with message (define the default key with git config --global user.signingkey before)
git tag -s <tag> -u <keyid> -m <message> # Creates a signed tag with a specified key user

git tag -d <tag> # Delete existing tags with the given names
git tag -v <tag> # Verify the GPG signature of the given tag names

git push --delete origin <tag> # delete tag in origin

# rename tag
git tag new old
git tag -d old
git push origin new :old
git pull --prune --tags # for coworkers

SUBMODULE

^

git submodule add <url> # add submodule to actual repository

GITHUB

^

create a local git repository and publish it to github

touch README.md
git init
git add *
git status
git commit -m "First commit"
git remote add origin <url>
git push -u origin master

GPG

^

https://kamarada.github.io/en/2019/07/14/using-git-with-ssh-keys/

GITHUB

1. import public to github

2. test

   ssh -T git@github.com # test ssh connection
   ssh -T -p 443 git@ssh.github.com # test ssh connection over https

3. set the default key

   git config --global user.signingkey <keyid>

change remote url for remote existing repository

git remote -v # print https://github.com/user/project
git remote set-url origin git@github.com:user/project.git # change the connection url to use ssh
git remote -v # print git@github.com:user/project.git

delete tags

git tag -d [tag];
git push origin :[tag]

git tag -d [tag]
git push origin :refs/tags/[tag]

GITIGNORE

^

https://www.atlassian.com/git/tutorials/saving-changes/gitignore

pattern

**/path # match directories anywhere in the repository, relative definition
*.pattern # matches zero or more characters
!pattern # mark to a pattern negates it
/pattern # matches files only in the repository root
path/ # appending a slash indicates the pattern is a directory
debug?.log # a question mark matches exactly one character
debug[0-9].log # Square brackets matches a single character from a specified range like [01] [a-z] [A-Z]
debug[!01].log # an exclamation mark matches any character except one from the specified set
logs/**/debug.log # a double asterisk matches zero or more directories like logs/*day/debug.log

example

*.ba[kt]
*~
!myfile.a # include file in repo
tmp/ # exclude all files in directory tmp
head/**/*.tmp # exclude all files *.tmp in subdirectory of head

TRICKS

^

create orphan repo from another

Create origin to remote server

repo_local="shaarli-snippets"
tmp_branch="dev"

origin="github"
url_origin="git@github.com:aguytech/Shaarli-snippets.git"

upstream="shaarli"
url_upstream="git@github.com:aguytech/Shaarli.git"
upstream_branch="v0.11-snippets" # remote branch to track

mkdir -p "$repo_local"
cd "$repo_local"

git init

# remote
git remote add "$origin" "$url_origin"
git remote add -t "$upstream_branch" "$upstream" "$url_upstream"
git remote -v
git config --get-regexp '^remote'

# upstream
git fetch "$upstream"
git co --orphan="$tmp_branch" "$upstream"/"$upstream_branch"
git st
git ci -m "Initialize branch from $upstream/$upstream_branch $(git log --pretty=format:'%h' -n 1 "$upstream"/"$upstream_branch")"

# origin
git push --set-upstream "$origin" "$tmp_branch"
git co -b master
git push --set-upstream "$origin" master
git br -vv
git br -rlv github/*

# archive
git archive --format tar.gz -9 -o "master.$(date +%s).tar.gz" master

add a submodule

git submodule add $url
git diff --cached $submodule
git diff --cached --submodule
git commit -m "Add $submodule module"

clone with submodules

git clone --recurse-submodules 

https://git-scm.com/book/fr/v2/Utilitaires-Git-Sous-modules

Inspects, updates and manages submodules

git submodule
  add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--depth <depth>] [--] <repository> [<path>] # add the given repository as a submodule at the given path to the changeset to be committed next to the current project: the current project is termed the "superproject"

add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--depth <depth>] [--] <repository> [<path>] # Add the given repository as a submodule at the given path to the changeset to be committed next to the current project: the current project is termed the "superproject".
status [--cached] [--recursive] [--] [<path>...] # Show the status of the submodules. This will print the SHA-1 of the currently checked out commit for each submodule, along with the submodule path and the output of git describe for the SHA-1.
init [--] [<path>...] # Initialize the submodules recorded in the index (which were added and committed elsewhere) by setting submodule.$name.url in .git/config.
deinit [-f|--force] (--all|[--] <path>...) # Unregister the given submodules, i.e. remove the whole submodule.$name section from .git/config together with their work tree.
update [--init] [--remote] [-N|--no-fetch] [--[no-]recommend-shallow] [-f|--force] [--checkout|--rebase|--merge] [--reference <repository>] [--depth <depth>] [--recursive] [--jobs <n>] # Update the registered submodules to match what the superproject expects by cloning missing submodules, fetching missing commits in submodules and updating the working tree of the submodules.
    checkout # the commit recorded in the superproject will be checked out in the submodule on a detached HEAD.
    rebase # the current branch of the submodule will be rebased onto the commit recorded in the superproject.
    merge # the commit recorded in the superproject will be merged into the current branch in the submodule.
    none # the submodule is not updated.
set-branch (-b|--branch) <branch> [--] <path>, set-branch (-d|--default) [--] <path> # Sets the default remote tracking branch for the submodule.
set-url [--] <path> <newurl> # Sets the URL of the specified submodule to <newurl>. Then, it will automatically synchronize the submodule’s new remote URL configuration.
summary [--cached|--files] [(-n|--summary-limit) <n>] [commit] [--] [<path>...] # Show commit summary between the given commit (defaults to HEAD) and working tree/index.
foreach [--recursive] <command> # Evaluates an arbitrary shell command in each checked out submodule.
sync [--recursive] [--] [<path>...] # Synchronizes submodules' remote URL configuration setting to the value specified in .gitmodules.
absorbgitdirs # If a git directory of a submodule is inside the submodule, move the git directory of the submodule into its superproject’s $GIT_DIR/modules path and then connect the git directory and its working directory by setting the core.worktree and adding a .git file pointing to the git directory embedded in the superprojects git directory.

Fetch from and integrate with another repository or a local branch

Incorporates changes from a remote repository into the current branch. In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD

More precisely, git pull runs git fetch with the given parameters and calls git merge to merge the retrieved branch heads into the current branch. With
--rebase, it runs git rebase instead of git merge

<repository> should be the name of a remote repository as passed to git-fetch(1). <refspec> can name an arbitrary remote ref (for example, the name of a tag) or even a collection of refs with corresponding remote-tracking branches (e.g., refs/heads/:refs/remotes/origin/), but usually it is the name of a branch in the remote repository

Default values for <repository> and <branch> are read from the "remote" and "merge" configuration for the current branch as set by git-branch(1) --track.

Assume the following history exists and the current branch is "master":

         A---B---C master on origin
        /
   D---E---F---G master
       ^
       origin/master in your repository

Then "git pull" will fetch and replay the changes from the remote master branch since it diverged from the local master (i.e., E) until its current commit (C) on top of master and record the result in a new commit along with the names of the two parent commits and a log message from the user describing the changes.

         A---B---C origin/master
        /         \
   D---E---F---G---H master

See git-merge(1) for details, including how conflicts are presented and handled.

In Git 1.7.0 or later, to cancel a conflicting merge, use git reset --merge. Warning: In older versions of Git, running git pull with uncommitted changes is discouraged: while possible, it leaves you in a state that may be hard to back out of in the case of a conflict.

If any of the remote changes overlap with local uncommitted changes, the merge will be automatically canceled and the work tree untouched. It is generally best to get any local changes in working order before pulling or stash them away with git-stash(1).

git pull [<options>] [<repository> [<refspec>...]]

  -q, --quiet # This is passed to both underlying git-fetch to squelch reporting of during transfer, and underlying git-merge to squelch output during merging
  -v, --verbose # Pass --verbose to git-fetch and git-merge
  --[no-]recurse-submodules[=yes|on-demand|no] # This option controls if new commits of all populated submodules should be fetched and updated, too

  Options related to merging

  --commit, --no-commit # Perform the merge and commit the result
  --edit, -e, --no-edit # Invoke an editor before committing successful mechanical merge to further edit the auto-generated merge message, so that the user can explain and justify the merge
  --cleanup=<mode> # This option determines how the merge message will be cleaned up before committing
  --ff, --no-ff, --ff-only # Specifies how a merge is handled when the merged-in history is already a descendant of the current history
  -S[<keyid>], --gpg-sign[=<keyid>] # GPG-sign the resulting merge commit
  --log[=<n>], --no-log # In addition to branch names, populate the log message with one-line descriptions from at most <n> actual commits that are being merged
  --signoff, --no-signoff # Add Signed-off-by line by the committer at the end of the commit log message
  --stat, -n, --no-stat # Show a diffstat at the end of the merge
  --squash, --no-squash # Produce the working tree and index state as if a real merge happened (except for the merge information), but do not actually make a commit, move the
  --no-verify # This option bypasses the pre-merge and commit-msg hooks
  -s <strategy>, --strategy=<strategy> # Use the given merge strategy; can be supplied more than once to specify them in the order they should be tried
  -X <option>, --strategy-option=<option> # Pass merge strategy specific option through to the merge strategy
  --verify-signatures, --no-verify-signatures # Verify that the tip commit of the side branch being merged is signed with a valid key, i
  --summary, --no-summary # Synonyms to --stat and --no-stat; these are deprecated and will be removed in the future
  --allow-unrelated-histories # By default, git merge command refuses to merge histories that do not share a common ancestor
  -r, --rebase[=false|true|merges|preserve|interactive] # When true, rebase the current branch on top of the upstream branch after fetching
  --no-rebase # Override earlier --rebase
  --autostash, --no-autostash # Before starting rebase, stash local modifications away (see git-stash(1)) if needed, and apply the stash entry when done

Options related to fetching

  --all # Fetch all remotes
  -a, --append # Append ref names and object names of fetched refs to the existing contents of 
  --depth=<depth> # Limit fetching to the specified number of commits from the tip of each remote branch history
  --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
  --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 
  --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
  -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 of the git-fetch(1) documentation
  -k, --keep # Keep downloaded pack
  --no-tags # By default, tags that point at objects that are downloaded from the remote repository are fetched and stored locally
  -u, --update-head-ok # By default git fetch refuses to update the head which corresponds to the current branch
  --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
  --progress # Progress status is reported on the standard error stream by default when it is attached to a terminal, unless -q is specified
  -o <option>, --server-option=<option> # Transmit the given string to the server when communicating using protocol version 2
  --show-forced-updates # By default, git checks if a branch is force-updated during fetch
  --no-show-forced-updates # By default, git checks if a branch is force-updated during fetch
  -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
  <refspec> # Specifies which refs to fetch and which local refs to update

examples

Update the remote-tracking branches for the repository you cloned from, then merge one of them into your current branch:

git pull
git pull origin

Normally the branch merged in is the HEAD of the remote repository, but the choice is determined by the branch.<name>.remote and branch.<name>.merge
options; see git-config(1) for details.

Merge into the current branch the remote branch next:

git pull origin next

This leaves a copy of next temporarily in FETCH_HEAD, but does not update any remote-tracking branches. Using remote-tracking branches, the same can be
done by invoking fetch and merge:

git fetch origin
git merge origin/next

If you tried a pull which resulted in complex conflicts and would want to start over, you can recover with git reset

Update remote refs along with associated objects

Updates remote refs using local refs, while sending objects necessary to complete the given refs

You can make interesting things happen to a repository every time you push into it, by setting up hooks there. See documentation for git-receive-
pack(1)

When the command line does not specify where to push with the <repository> argument, branch.*.remote configuration for the current branch is
consulted to determine where to push. If the configuration is missing, it defaults to origin

When the command line does not specify what to push with <refspec>... arguments or --all, --mirror, --tags options, the command finds the default
<refspec> by consulting remote.*.push configuration, and if it is not found, honors push.default configuration to decide what to push (See git-
config(1) for the meaning of push.default)

When neither the command-line nor the configuration specify what to push, the default behavior is used, which corresponds to the simple value for
push.default: the current branch is pushed to the corresponding upstream branch, but as a safety measure, the push is aborted if the upstream
branch does not have the same name as the local one

git push [--all | --mirror | --tags] [--follow-tags] [--atomic] [-n | --dry-run] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-d | --delete] [--prune] [-v | --verbose] [-u | --set-upstream] [-o <string> | --push-option=<string>] [--[no-]signed|--signed=(true|false|if-asked)] [--force-with-lease[=<refname>[:<expect>]]] [--no-verify] [<repository> [<refspec>...]]

  <repository> # The "remote" repository that is destination of a push operation. This parameter can be either a URL (see the section GIT URLS below) or the name of a remote (see the section REMOTES below)

  <refspec>... # Specify what destination ref to update with what source object. The format of a <refspec> parameter is an optional plus +, followed by the source object <src>, followed by a colon :, followed by the destination ref <dst>
  --all # Push all branches (i.e. refs under refs/heads/); cannot be used with other <refspec>

  --prune # Remove remote branches that don’t have a local counterpart. For example a remote branch tmp will be removed if a local branch with the same name doesn’t exist any more. This also respects refspecs, e.g.  git push --prune remote refs/heads/*:refs/tmp/* would make sure that remote refs/tmp/foo will be removed if refs/heads/foo doesn’t exist

  --mirror # Instead of naming each ref to push, specifies that all refs under refs/ (which includes but is not limited to refs/heads/, refs/remotes/, and refs/tags/) be mirrored to the remote repository. Newly created local refs will be pushed to the remote end, locally updated refs will be force updated on the remote end, and deleted refs will be removed from the remote end. This is the default if the configuration option remote.<remote>.mirror is set

  -n, --dry-run # Do everything except actually send the updates

  --porcelain # Produce machine-readable output. The output status line for each ref will be tab-separated and sent to stdout instead of stderr. The full symbolic names of the refs will be given

  -d, --delete # All listed refs are deleted from the remote repository. This is the same as prefixing all refs with a colon

  --tags # All refs under refs/tags are pushed, in addition to refspecs explicitly listed on the command line

  --follow-tags # Push all the refs that would be pushed without this option, and also push annotated tags in refs/tags that are missing from the remote but are pointing at commit-ish that are reachable from the refs being pushed. This can also be specified with configuration variable push.followTags. For more information, see push.followTags in git-config(1)

  --[no-]signed, --signed=(true|false|if-asked) # GPG-sign the push request to update refs on the receiving side, to allow it to be checked by the hooks and/or be logged. If false or --no-signed, no signing will be attempted. If true or --signed, the push will fail if the server does not support signed pushes. If set to if-asked, sign if and only if the server supports signed pushes. The push will also fail if the actual call to gpg --sign fails. See git-receive-pack(1) for the details on the receiving end

  --[no-]atomic # Use an atomic transaction on the remote side if available. Either all refs are updated, or on error, no refs are updated. If the server does not support atomic pushes the push will fail

  -o <option>, --push-option=<option> # Transmit the given string to the server, which passes them to the pre-receive as well as the post-receive hook. The given string must not contain a NUL or LF character. When multiple --push-option=<option> are given, they are all sent to the other side in the order listed on the command line. When no --push-option=<option> is given from the command line, the values of configuration variable push.pushOption are used instead

  --receive-pack=<git-receive-pack>, --exec=<git-receive-pack> # Path to the git-receive-pack program on the remote end. Sometimes useful when pushing to a remote repository over ssh, and you do not have the program in a directory on the default $PATH

  --[no-]force-with-lease, --force-with-lease=<refname>, --force-with-lease=<refname>:<expect> # Usually, "git push" refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it. This option overrides this restriction if the current value of the remote ref is the expected value. "git push" fails otherwise

  -f, --force # Usually, the command refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it. Also, when --force-with-lease option is used, the command refuses to update a remote ref whose current value does not match what is expected
  --repo=<repository> # This option is equivalent to the <repository> argument. If both are specified, the command-line argument takes precedence

  -u, --set-upstream # For every branch that is up to date or successfully pushed, add upstream (tracking) reference, used by argument-less git-pull(1) and other commands. For more information, see branch.<name>.merge in git-config(1)

  --[no-]thin # These options are passed to git-send-pack(1). A thin transfer significantly reduces the amount of sent data when the sender and receiver share many of the same objects in common. The default is --thin

  -q, --quiet # Suppress all output, including the listing of updated refs, unless an error occurs. Progress is not reported to the standard error stream

  -v, --verbose # Run verbosely

  --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

  --no-recurse-submodules, --recurse-submodules=check|on-demand|only|no # May be used to make sure all submodule commits used by the revisions to be pushed are available on a remote-tracking branch. If check is used Git will verify that all submodule commits that changed in the revisions to be pushed are available on at least one remote of the submodule. If any commits are missing the push will be aborted and exit with non-zero status. If on-demand is used all submodules that changed in the revisions to be pushed will be pushed. If on-demand was not able to push all necessary revisions it will also be aborted and exit with non-zero status. If only is used all submodules will be recursively pushed while the superproject is left unpushed. A value of no or using --no-recurse-submodules can be used to override the push.recurseSubmodules configuration variable when no submodule recursion is required

  --[no-]verify # Toggle the pre-push hook (see githooks(5)). The default is --verify, giving the hook a chance to prevent the push. With --no-verify, the hook is bypassed completely

  -4, --ipv4 # Use IPv4 addresses only, ignoring IPv6 addresses

  -6, --ipv6 # Use IPv6 addresses only, ignoring IPv4 addresses

OUTPUT

The output of "git push" depends on the transport method used; this section describes the output when pushing over the Git protocol (either
locally or via ssh)

The status of the push is output in tabular form, with each line representing the status of a single ref. Each line is of the form:

• <flag> <summary> <from> -> <to> (<reason>)

If --porcelain is used, then each line of the output is of the form:

• <flag> \t <from>:<to> \t <summary> (<reason>)

The status of up-to-date refs is shown only if --porcelain or --verbose option is used

flag

(space) # for a successfully pushed fast-forward;
+ # for a successful forced update;
- # for a successfully deleted ref;
* # for a successfully pushed new ref;
! # for a ref that was rejected or failed to push; and
= # for a ref that was up to date and did not need pushing

summary

For a successfully pushed ref
the summary shows the old and new values of the ref in a form suitable for using as an argument to git log (this is <old>..<new> in most cases, and <old>...<new> for forced non-fast-forward updates)

For a failed update, more details are given:

rejected # Git did not try to send the ref at all, typically because it is not a fast-forward and you did not force the update
remote rejected # The remote end refused the update. Usually caused by a hook on the remote side, or because the remote repository has one of the following safety options in effect: receive.denyCurrentBranch (for pushes to the checked out branch), receive.denyNonFastForwards (for forced non-fast-forward updates), receive.denyDeletes or receive.denyDeleteCurrent
remote failure # The remote end did not report the successful update of the ref, perhaps because of a temporary error on the remote side, a break in the network connection, or other transient error
from # The name of the local ref being pushed, minus its refs/<type>/ prefix. In the case of deletion, the name of the local ref is omitted
to # The name of the remote ref being updated, minus its refs/<type>/ prefix
reason # A human-readable explanation. In the case of successfully pushed refs, no explanation is needed. For a failed ref, the reason for failure is
described

examples

git push
# Works like git push <remote>, where <remote> is the current branch’s remote (or origin, if no remote is configured for the current branch)

git push origin
# Without additional configuration, pushes the current branch to the configured upstream (remote.origin.merge configuration variable) if it has the same name as the current branch, and errors out without pushing otherwise

#The default behavior of this command when no <refspec> is given can be configured by setting the push option of the remote, or the push.default configuration variable

# For example, to default to pushing only the current branch to origin use git config remote.origin.push HEAD. Any valid <refspec> (like the ones in the examples below) can be configured as the default for git push origin

git push origin:
# Push "matching" branches to origin. See <refspec> in the OPTIONS section above for a description of "matching" branches

git push origin master
# Find a ref that matches master in the source repository (most likely, it would find refs/heads/master), and update the same ref (e.g. refs/heads/master) in origin repository with it. If master did not exist remotely, it would be created

git push origin HEAD
# A handy way to push the current branch to the same name on the remote

git push mothership master:satellite/master dev:satellite/dev
# Use the source ref that matches master (e.g.  refs/heads/master) to update the ref that matches satellite/master (most probably refs/remotes/satellite/master) in the mothership repository; do the same for dev and satellite/dev

# See the section describing <refspec>...  above for a discussion of the matching semantics

# This is to emulate git fetch run on the mothership using git push that is run in the opposite direction in order to integrate the work done on satellite, and is often necessary when you can only make connection in one way (i.e. satellite can ssh into mothership but mothership cannot initiate connection to satellite because the latter is behind a firewall or does not run sshd)

# After running this git push on the satellite machine, you would ssh into the mothership and run git merge there to complete the emulation of git pull that were run on mothership to pull changes made on satellite

git push origin HEAD:master
# Push the current branch to the remote ref matching master in the origin repository. This form is convenient to push the current branch without thinking about its local name

git push origin master:refs/heads/experimental
# Create the branch experimental in the origin repository by copying the current master branch. This form is only needed to create a new branch or tag in the remote repository when the local name and the remote name are different; otherwise, the ref name on its own will work

git push origin :experimental
# Find a ref that matches experimental in the origin repository (e.g.  refs/heads/experimental), and delete it

git push origin +dev:master
# Update the origin repository’s master branch with the dev branch, allowing non-fast-forward updates.  This can leave unreferenced commits dangling in the origin repository.  Consider the following situation, where a fast-forward is not possible:

               o---o---o---A---B  origin/master
                        \
                         X---Y---Z  dev

The above command would change the origin repository to

                         A---B  (unnamed branch)
                        /
               o---o---o---X---Y---Z  master

# Commits A and B would no longer belong to a branch with a symbolic name, and so would be unreachable. As such, these commits would be removed by a git gc command on the origin repository