Git Reference---Sharing and Updating Projects

来源：互联网发布：windows未能启动成功编辑：程序博客网时间：2024/04/24 18:51

NAME

git-remote - Manage set of tracked repositories

SYNOPSIS

git remote [-v | --verbose]git remote add [-t <branch>] [-m <master>] [-f] [--[no-]tags] [--mirror=<fetch|push>] <name> <url>git remote rename <old> <new>git remote remove <name>git remote set-head <name> (-a | --auto | -d | --delete | <branch>)git remote set-branches [--add] <name> <branch>…git remote set-url [--push] <name> <newurl> [<oldurl>]git remote set-url --add [--push] <name> <newurl>git remote set-url --delete [--push] <name> <url>git remote [-v | --verbose] show [-n] <name>…git remote prune [-n | --dry-run] <name>…git remote [-v | --verbose] update [-p | --prune] [(<group> | <remote>)…]

DESCRIPTION

Manage the set of repositories ("remotes") whose branches you track.

OPTIONS

-v
--verbose: Be a little more verbose and show remote url after name. NOTE: This must be placed betweenremote and subcommand.

COMMANDS

With no arguments, shows a list of existing remotes. Several subcommands are available to perform operations on the remotes.

add: Adds a remote named <name> for the repository at <url>. The command git fetch <name>can then be used to create and update remote-tracking branches <name>/<branch>.
With -f option, git fetch <name> is run immediately after the remote information is set up.
With --tags option, git fetch <name> imports every tag from the remote repository.
With --no-tags option, git fetch <name> does not import tags from the remote repository.
By default, only tags on fetched branches are imported (see git-fetch[1]).
With -t <branch> option, instead of the default glob refspec for the remote to track all branches under the refs/remotes/<name>/ namespace, a refspec to track only <branch> is created. You can give more than one -t <branch> to track multiple branches without grabbing all branches.
With -m <master> option, a symbolic-ref refs/remotes/<name>/HEAD is set up to point at remote’s <master> branch. See also the set-head command.
When a fetch mirror is created with --mirror=fetch, the refs will not be stored in therefs/remotes/ namespace, but rather everything in refs/ on the remote will be directly mirrored into refs/ in the local repository. This option only makes sense in bare repositories, because a fetch would overwrite any local commits.
When a push mirror is created with --mirror=push, then git push will always behave as if--mirror was passed.
rename: Rename the remote named <old> to <new>. All remote-tracking branches and configuration settings for the remote are updated.
In case <old> and <new> are the same, and <old> is a file under $GIT_DIR/remotes or$GIT_DIR/branches, the remote is converted to the configuration file format.
remove
rm: Remove the remote named <name>. All remote-tracking branches and configuration settings for the remote are removed.
set-head: Sets or deletes the default branch (i.e. the target of the symbolic-refrefs/remotes/<name>/HEAD) for the named remote. Having a default branch for a remote is not required, but allows the name of the remote to be specified in lieu of a specific branch. For example, if the default branch for origin is set to master, then origin may be specified wherever you would normally specify origin/master.
With -d or --delete, the symbolic ref refs/remotes/<name>/HEAD is deleted.
With -a or --auto, the remote is queried to determine its HEAD, then the symbolic-refrefs/remotes/<name>/HEAD is set to the same branch. e.g., if the remote HEAD is pointed atnext, "git remote set-head origin -a" will set the symbolic-refrefs/remotes/origin/HEAD to refs/remotes/origin/next. This will only work ifrefs/remotes/origin/next already exists; if not it must be fetched first.
Use <branch> to set the symbolic-ref refs/remotes/<name>/HEAD explicitly. e.g., "git remote set-head origin master" will set the symbolic-ref refs/remotes/origin/HEAD torefs/remotes/origin/master. This will only work if refs/remotes/origin/masteralready exists; if not it must be fetched first.
set-branches: Changes the list of branches tracked by the named remote. This can be used to track a subset of the available remote branches after the initial setup for a remote.
The named branches will be interpreted as if specified with the -t option on the git remote addcommand line.
With --add, instead of replacing the list of currently tracked branches, adds to that list.
set-url: Changes URLs for the remote. Sets first URL for remote <name> that matches regex <oldurl> (first URL if no <oldurl> is given) to <newurl>. If <oldurl> doesn’t match any URL, an error occurs and nothing is changed.
With --push, push URLs are manipulated instead of fetch URLs.
With --add, instead of changing existing URLs, new URL is added.
With --delete, instead of changing existing URLs, all URLs matching regex <url> are deleted for remote <name>. Trying to delete all non-push URLs is an error.
Note that the push URL and the fetch URL, even though they can be set differently, must still refer to the same place. What you pushed to the push URL should be what you would see if you immediately fetched from the fetch URL. If you are trying to fetch from one place (e.g. your upstream) and push to another (e.g. your publishing repository), use two separate remotes.
show: Gives some information about the remote <name>.
With -n option, the remote heads are not queried first with git ls-remote <name>; cached information is used instead.
prune: Deletes all stale remote-tracking branches under <name>. These stale branches have already been removed from the remote repository referenced by <name>, but are still locally available in "remotes/<name>".
With --dry-run option, report what branches will be pruned, but do not actually prune them.
update: Fetch updates for a named set of remotes in the repository as defined by remotes.<group>. If a named group is not specified on the command line, the configuration parameter remotes.default will be used; if remotes.default is not defined, all remotes which do not have the configuration parameter remote.<name>.skipDefaultUpdate set to true will be updated. (See git-config[1]).
With --prune option, prune all the remotes that are updated.

DISCUSSION

The remote configuration is achieved using the remote.origin.url andremote.origin.fetch configuration variables. (See git-config[1]).

Examples

Add a new remote, fetch, and check out a branch from it

$ git remoteorigin$ git branch -r  origin/HEAD -> origin/master  origin/master$ git remote add staging git://git.kernel.org/.../gregkh/staging.git$ git remoteoriginstaging$ git fetch staging...From git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging * [new branch]      master     -> staging/master * [new branch]      staging-linus -> staging/staging-linus * [new branch]      staging-next -> staging/staging-next$ git branch -r  origin/HEAD -> origin/master  origin/master  staging/master  staging/staging-linus  staging/staging-next$ git checkout -b staging staging/master...

Imitate git clone but track only selected branches

$ mkdir project.git$ cd project.git$ git init$ git remote add -f -t master -m master origin git://example.com/git.git/$ git merge origin

GIT

Part of the git[1] suite

NAME

git-remote - Manage set of tracked repositories

SYNOPSIS

git remote [-v | --verbose]git remote add [-t <branch>] [-m <master>] [-f] [--[no-]tags] [--mirror=<fetch|push>] <name> <url>git remote rename <old> <new>git remote remove <name>git remote set-head <name> (-a | --auto | -d | --delete | <branch>)git remote set-branches [--add] <name> <branch>…git remote set-url [--push] <name> <newurl> [<oldurl>]git remote set-url --add [--push] <name> <newurl>git remote set-url --delete [--push] <name> <url>git remote [-v | --verbose] show [-n] <name>…git remote prune [-n | --dry-run] <name>…git remote [-v | --verbose] update [-p | --prune] [(<group> | <remote>)…]

DESCRIPTION

Manage the set of repositories ("remotes") whose branches you track.

OPTIONS

-v
--verbose: Be a little more verbose and show remote url after name. NOTE: This must be placed betweenremote and subcommand.

COMMANDS

With no arguments, shows a list of existing remotes. Several subcommands are available to perform operations on the remotes.

add: Adds a remote named <name> for the repository at <url>. The command git fetch <name>can then be used to create and update remote-tracking branches <name>/<branch>.
With -f option, git fetch <name> is run immediately after the remote information is set up.
With --tags option, git fetch <name> imports every tag from the remote repository.
With --no-tags option, git fetch <name> does not import tags from the remote repository.
By default, only tags on fetched branches are imported (see git-fetch[1]).
With -t <branch> option, instead of the default glob refspec for the remote to track all branches under the refs/remotes/<name>/ namespace, a refspec to track only <branch> is created. You can give more than one -t <branch> to track multiple branches without grabbing all branches.
With -m <master> option, a symbolic-ref refs/remotes/<name>/HEAD is set up to point at remote’s <master> branch. See also the set-head command.
When a fetch mirror is created with --mirror=fetch, the refs will not be stored in therefs/remotes/ namespace, but rather everything in refs/ on the remote will be directly mirrored into refs/ in the local repository. This option only makes sense in bare repositories, because a fetch would overwrite any local commits.
When a push mirror is created with --mirror=push, then git push will always behave as if--mirror was passed.
rename: Rename the remote named <old> to <new>. All remote-tracking branches and configuration settings for the remote are updated.
In case <old> and <new> are the same, and <old> is a file under $GIT_DIR/remotes or$GIT_DIR/branches, the remote is converted to the configuration file format.
remove
rm: Remove the remote named <name>. All remote-tracking branches and configuration settings for the remote are removed.
set-head: Sets or deletes the default branch (i.e. the target of the symbolic-refrefs/remotes/<name>/HEAD) for the named remote. Having a default branch for a remote is not required, but allows the name of the remote to be specified in lieu of a specific branch. For example, if the default branch for origin is set to master, then origin may be specified wherever you would normally specify origin/master.
With -d or --delete, the symbolic ref refs/remotes/<name>/HEAD is deleted.
With -a or --auto, the remote is queried to determine its HEAD, then the symbolic-refrefs/remotes/<name>/HEAD is set to the same branch. e.g., if the remote HEAD is pointed atnext, "git remote set-head origin -a" will set the symbolic-refrefs/remotes/origin/HEAD to refs/remotes/origin/next. This will only work ifrefs/remotes/origin/next already exists; if not it must be fetched first.
Use <branch> to set the symbolic-ref refs/remotes/<name>/HEAD explicitly. e.g., "git remote set-head origin master" will set the symbolic-ref refs/remotes/origin/HEAD torefs/remotes/origin/master. This will only work if refs/remotes/origin/masteralready exists; if not it must be fetched first.
set-branches: Changes the list of branches tracked by the named remote. This can be used to track a subset of the available remote branches after the initial setup for a remote.
The named branches will be interpreted as if specified with the -t option on the git remote addcommand line.
With --add, instead of replacing the list of currently tracked branches, adds to that list.
set-url: Changes URLs for the remote. Sets first URL for remote <name> that matches regex <oldurl> (first URL if no <oldurl> is given) to <newurl>. If <oldurl> doesn’t match any URL, an error occurs and nothing is changed.
With --push, push URLs are manipulated instead of fetch URLs.
With --add, instead of changing existing URLs, new URL is added.
With --delete, instead of changing existing URLs, all URLs matching regex <url> are deleted for remote <name>. Trying to delete all non-push URLs is an error.
Note that the push URL and the fetch URL, even though they can be set differently, must still refer to the same place. What you pushed to the push URL should be what you would see if you immediately fetched from the fetch URL. If you are trying to fetch from one place (e.g. your upstream) and push to another (e.g. your publishing repository), use two separate remotes.
show: Gives some information about the remote <name>.
With -n option, the remote heads are not queried first with git ls-remote <name>; cached information is used instead.
prune: Deletes all stale remote-tracking branches under <name>. These stale branches have already been removed from the remote repository referenced by <name>, but are still locally available in "remotes/<name>".
With --dry-run option, report what branches will be pruned, but do not actually prune them.
update: Fetch updates for a named set of remotes in the repository as defined by remotes.<group>. If a named group is not specified on the command line, the configuration parameter remotes.default will be used; if remotes.default is not defined, all remotes which do not have the configuration parameter remote.<name>.skipDefaultUpdate set to true will be updated. (See git-config[1]).
With --prune option, prune all the remotes that are updated.

DISCUSSION

The remote configuration is achieved using the remote.origin.url andremote.origin.fetch configuration variables. (See git-config[1]).

Examples

Add a new remote, fetch, and check out a branch from it

$ git remoteorigin$ git branch -r  origin/HEAD -> origin/master  origin/master$ git remote add staging git://git.kernel.org/.../gregkh/staging.git$ git remoteoriginstaging$ git fetch staging...From git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging * [new branch]      master     -> staging/master * [new branch]      staging-linus -> staging/staging-linus * [new branch]      staging-next -> staging/staging-next$ git branch -r  origin/HEAD -> origin/master  origin/master  staging/master  staging/staging-linus  staging/staging-next$ git checkout -b staging staging/master...

Imitate git clone but track only selected branches

$ mkdir project.git$ cd project.git$ git init$ git remote add -f -t master -m master origin git://example.com/git.git/$ git merge origin

GIT

Part of the git[1] suite

NAME

git-remote - Manage set of tracked repositories

SYNOPSIS

git remote [-v | --verbose]git remote add [-t <branch>] [-m <master>] [-f] [--[no-]tags] [--mirror=<fetch|push>] <name> <url>git remote rename <old> <new>git remote remove <name>git remote set-head <name> (-a | --auto | -d | --delete | <branch>)git remote set-branches [--add] <name> <branch>…git remote set-url [--push] <name> <newurl> [<oldurl>]git remote set-url --add [--push] <name> <newurl>git remote set-url --delete [--push] <name> <url>git remote [-v | --verbose] show [-n] <name>…git remote prune [-n | --dry-run] <name>…git remote [-v | --verbose] update [-p | --prune] [(<group> | <remote>)…]

DESCRIPTION

Manage the set of repositories ("remotes") whose branches you track.

OPTIONS

-v
--verbose: Be a little more verbose and show remote url after name. NOTE: This must be placed betweenremote and subcommand.

COMMANDS

With no arguments, shows a list of existing remotes. Several subcommands are available to perform operations on the remotes.

add: Adds a remote named <name> for the repository at <url>. The command git fetch <name>can then be used to create and update remote-tracking branches <name>/<branch>.
With -f option, git fetch <name> is run immediately after the remote information is set up.
With --tags option, git fetch <name> imports every tag from the remote repository.
With --no-tags option, git fetch <name> does not import tags from the remote repository.
By default, only tags on fetched branches are imported (see git-fetch[1]).
With -t <branch> option, instead of the default glob refspec for the remote to track all branches under the refs/remotes/<name>/ namespace, a refspec to track only <branch> is created. You can give more than one -t <branch> to track multiple branches without grabbing all branches.
With -m <master> option, a symbolic-ref refs/remotes/<name>/HEAD is set up to point at remote’s <master> branch. See also the set-head command.
When a fetch mirror is created with --mirror=fetch, the refs will not be stored in therefs/remotes/ namespace, but rather everything in refs/ on the remote will be directly mirrored into refs/ in the local repository. This option only makes sense in bare repositories, because a fetch would overwrite any local commits.
When a push mirror is created with --mirror=push, then git push will always behave as if--mirror was passed.
rename: Rename the remote named <old> to <new>. All remote-tracking branches and configuration settings for the remote are updated.
In case <old> and <new> are the same, and <old> is a file under $GIT_DIR/remotes or$GIT_DIR/branches, the remote is converted to the configuration file format.
remove
rm: Remove the remote named <name>. All remote-tracking branches and configuration settings for the remote are removed.
set-head: Sets or deletes the default branch (i.e. the target of the symbolic-refrefs/remotes/<name>/HEAD) for the named remote. Having a default branch for a remote is not required, but allows the name of the remote to be specified in lieu of a specific branch. For example, if the default branch for origin is set to master, then origin may be specified wherever you would normally specify origin/master.
With -d or --delete, the symbolic ref refs/remotes/<name>/HEAD is deleted.
With -a or --auto, the remote is queried to determine its HEAD, then the symbolic-refrefs/remotes/<name>/HEAD is set to the same branch. e.g., if the remote HEAD is pointed atnext, "git remote set-head origin -a" will set the symbolic-refrefs/remotes/origin/HEAD to refs/remotes/origin/next. This will only work ifrefs/remotes/origin/next already exists; if not it must be fetched first.
Use <branch> to set the symbolic-ref refs/remotes/<name>/HEAD explicitly. e.g., "git remote set-head origin master" will set the symbolic-ref refs/remotes/origin/HEAD torefs/remotes/origin/master. This will only work if refs/remotes/origin/masteralready exists; if not it must be fetched first.
set-branches: Changes the list of branches tracked by the named remote. This can be used to track a subset of the available remote branches after the initial setup for a remote.
The named branches will be interpreted as if specified with the -t option on the git remote addcommand line.
With --add, instead of replacing the list of currently tracked branches, adds to that list.
set-url: Changes URLs for the remote. Sets first URL for remote <name> that matches regex <oldurl> (first URL if no <oldurl> is given) to <newurl>. If <oldurl> doesn’t match any URL, an error occurs and nothing is changed.
With --push, push URLs are manipulated instead of fetch URLs.
With --add, instead of changing existing URLs, new URL is added.
With --delete, instead of changing existing URLs, all URLs matching regex <url> are deleted for remote <name>. Trying to delete all non-push URLs is an error.
Note that the push URL and the fetch URL, even though they can be set differently, must still refer to the same place. What you pushed to the push URL should be what you would see if you immediately fetched from the fetch URL. If you are trying to fetch from one place (e.g. your upstream) and push to another (e.g. your publishing repository), use two separate remotes.
show: Gives some information about the remote <name>.
With -n option, the remote heads are not queried first with git ls-remote <name>; cached information is used instead.
prune: Deletes all stale remote-tracking branches under <name>. These stale branches have already been removed from the remote repository referenced by <name>, but are still locally available in "remotes/<name>".
With --dry-run option, report what branches will be pruned, but do not actually prune them.
update: Fetch updates for a named set of remotes in the repository as defined by remotes.<group>. If a named group is not specified on the command line, the configuration parameter remotes.default will be used; if remotes.default is not defined, all remotes which do not have the configuration parameter remote.<name>.skipDefaultUpdate set to true will be updated. (See git-config[1]).
With --prune option, prune all the remotes that are updated.

DISCUSSION

The remote configuration is achieved using the remote.origin.url andremote.origin.fetch configuration variables. (See git-config[1]).

Examples

Add a new remote, fetch, and check out a branch from it

$ git remoteorigin$ git branch -r  origin/HEAD -> origin/master  origin/master$ git remote add staging git://git.kernel.org/.../gregkh/staging.git$ git remoteoriginstaging$ git fetch staging...From git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging * [new branch]      master     -> staging/master * [new branch]      staging-linus -> staging/staging-linus * [new branch]      staging-next -> staging/staging-next$ git branch -r  origin/HEAD -> origin/master  origin/master  staging/master  staging/staging-linus  staging/staging-next$ git checkout -b staging staging/master...

Imitate git clone but track only selected branches

$ mkdir project.git$ cd project.git$ git init$ git remote add -f -t master -m master origin git://example.com/git.git/$ git merge origin

GIT

Part of the git[1] suite

NAME

git-fetch - Download objects and refs from another repository

SYNOPSIS

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

DESCRIPTION

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. (See git-config[1]).

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

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>: Deepen or shorten the history of a shallow repository created by git clone with --depth=<depth> option (see git-clone[1]) to the specified number of commits from the tip of each remote branch history. Tags for the deepened commits are not fetched.
--unshallow: If the source repository is complete, convert a shallow repository to a complete one, removing all the limitations imposed by shallow repositories.
If the source repository is shallow, fetch as much as possible so that the current repository has the same history as the source repository.
--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.
--dry-run: Show what would be done, without making any changes.
-f
--force: When git fetch is used with <rbranch>:<lbranch> refspec, it refuses to update the local branch<lbranch> unless the remote branch <rbranch> it fetches is a descendant of <lbranch>. 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.
-p
--prune: After 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.
-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. See git-config[1].
--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.*.fetchconfiguration variables for the remote repository. See section on "Configured Remote-tracking Branches" for details.
-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.
--no-recurse-submodules: Disable recursive fetching of submodules (this has the same effect as using the --recurse-submodules=no option).
--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.

<repository>: The "remote" repository that is the source of a fetch or pull 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).
<group>: A name referring to a list of repositories as the value of remotes.<group> in the configuration file. (See git-config[1]).
<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 (see CONFIGURED REMOTE-TRACKING BRANCHES below).
The format of a <refspec> parameter is an optional plus +, followed by the source ref <src>, followed by a colon :, followed by the destination ref <dst>. The colon can be omitted when <dst> is empty.
tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag>; it requests fetching everything up to the given tag.
The remote ref that matches <src> is fetched, and if <dst> is not empty string, the local ref that matches it is fast-forwarded using <src>. If the optional plus + is used, the local ref is updated even if it does not result in a fast-forward update.
Note
When the remote branch you want to fetch is known to be rewound and rebased regularly, it is expected that its new tip will not be descendant of its previous tip (as stored in your remote-tracking branch the last time you fetched). You would want to use the + sign to indicate non-fast-forward updates will be needed for such branches. There is no way to determine or declare that a branch will be made available in a repository with this behavior; the pulling user simply must know this is the expected usage pattern for a branch.

urls.txt

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 formatPush: <refspec>Pull: <refspec>

Push: lines are used by git push and Pull: lines are used by git pull and git fetch. MultiplePush: 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>

CONFIGURED REMOTE-TRACKING BRANCHES

You often interact with the same remote repository by regularly and repeatedly fetching from it. In order to keep track of the progress of such a remote repository, git fetch allows you to configure remote.<repository>.fetch configuration variables.

Typically such a variable may look like this:

[remote "origin"]fetch = +refs/heads/*:refs/remotes/origin/*

This configuration is used in two ways:

When git fetch is run without specifying what branches and/or tags to fetch on the command line, e.g. git fetch origin or git fetch, remote.<repository>.fetchvalues are used as the refspecs—they specify which refs to fetch and which local refs to update. The example above will fetch all branches that exist in the origin (i.e. any ref that matches the left-hand side of the value, refs/heads/*) and update the corresponding remote-tracking branches in the refs/remotes/origin/* hierarchy.
When git fetch is run with explicit branches and/or tags to fetch on the command line, e.g.git fetch origin master, the <refspec>s given on the command line determine what are to be fetched (e.g. master in the example, which is a short-hand for master:, which in turn means "fetch the master branch but I do not explicitly say what remote-tracking branch to update with it from the command line"), and the example command will fetch only the masterbranch. The remote.<repository>.fetch values determine which remote-tracking branch, if any, is updated. When used in this way, the remote.<repository>.fetch values do not have any effect in deciding what gets fetched (i.e. the values are not used as refspecs when the command-line lists refspecs); they are only used to decide where the refs that are fetched are stored by acting as a mapping.

The latter use of the remote.<repository>.fetch values can be overridden by giving the --refmap=<refspec> parameter(s) on the command line.

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 is 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 atgit://git.kernel.org/pub/scm/git/git.git and the second command usesFETCH_HEAD to examine the branch with git-log[1]. The fetched objects will eventually be removed by git’s built-in housekeeping (see git-gc[1]).

BUGS

Using --recurse-submodules can only fetch new commits in already checked out submodules right now. When e.g. upstream added a new submodule in the just fetched commits of the superproject the submodule itself can not be fetched, making it impossible to check out that submodule later without having to do a fetch again. This is expected to be fixed in a future Git version.

GIT

Part of the git[1] suite

NAME

git-pull - Fetch from and integrate with another repository or a local branch

SYNOPSIS

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

DESCRIPTION

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 cancelled 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].

OPTIONS

-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 too (see git-config[1] and gitmodules[5]). That might be necessary to get the data needed for merging submodule commits, a feature Git learned in 1.7.3. Notice that the result of a merge will not be checked out in the submodule, "git submodule update" has to be called afterwards to bring the work tree up to date with the merge result.

Options related to merging

--commit
--no-commit: Perform the merge and commit the result. This option can be used to override --no-commit.
With --no-commit perform the merge but pretend the merge failed and do not autocommit, to give the user a chance to inspect and further tweak the merge result before committing.
--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. The --no-editoption can be used to accept the auto-generated message (this is generally discouraged).
Older scripts may depend on the historical behaviour of not allowing the user to edit the merge log message. They will see an editor opened when they run git merge. To make it easier to adjust such scripts to the updated behaviour, the environment variable GIT_MERGE_AUTOEDIT can be set to no at the beginning of them.
--ff: When the merge resolves as a fast-forward, only update the branch pointer, without creating a merge commit. This is the default behavior.
--no-ff: Create a merge commit even when the merge resolves as a fast-forward. This is the default behaviour when merging an annotated (and possibly signed) tag.
--ff-only: Refuse to merge and exit with a non-zero status unless the current HEAD is already up-to-date or the merge can be resolved as a fast-forward.
--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. See also git-fmt-merge-msg[1].
With --no-log do not list one-line descriptions from the actual commits being merged.
--stat
-n
--no-stat: Show a diffstat at the end of the merge. The diffstat is also controlled by the configuration option merge.stat.
With -n or --no-stat do not 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 HEAD, or record$GIT_DIR/MERGE_HEAD (to cause the next git commit command to create a merge commit). This allows you to create a single commit on top of the current branch whose effect is the same as merging another branch (or more in case of an octopus).
With --no-squash perform the merge and commit the result. This option can be used to override --squash.
-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. If there is no -s option, a built-in list of strategies is used instead (git merge-recursive when merging a single head, git merge-octopus otherwise).
-X <option>
--strategy-option=<option>: Pass merge strategy specific option through to the merge strategy.
--verify-signatures
--no-verify-signatures: Verify that the commits being merged have good and trusted GPG signatures and abort the merge in case they do not.
--summary
--no-summary: Synonyms to --stat and --no-stat; these are deprecated and will be removed in the future.

-r
--rebase[=false|true|preserve]: When true, rebase the current branch on top of the upstream branch after fetching. If there is a remote-tracking branch corresponding to the upstream branch and the upstream branch was rebased since last fetched, the rebase uses that information to avoid rebasing non-local changes.
When set to preserve, rebase with the --preserve-merges option passed to git rebase so that locally created merge commits will not be flattened.
When false, merge the current branch into the upstream branch.
See pull.rebase, branch.<name>.rebase and branch.autoSetupRebase in git-config[1]if you want to make git pull always use --rebase instead of merging.
Note
This is a potentially dangerous mode of operation. It rewrites history, which does not bode well when you published that history already. Donot use this option unless you have read git-rebase[1] carefully.
--no-rebase: Override earlier --rebase.

Options related to fetching

--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>: Deepen or shorten the history of a shallow repository created by git clone with --depth=<depth> option (see git-clone[1]) to the specified number of commits from the tip of each remote branch history. Tags for the deepened commits are not fetched.
--unshallow: If the source repository is complete, convert a shallow repository to a complete one, removing all the limitations imposed by shallow repositories.
If the source repository is shallow, fetch as much as possible so that the current repository has the same history as the source repository.
--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.
-f
--force: When git fetch is used with <rbranch>:<lbranch> refspec, it refuses to update the local branch<lbranch> unless the remote branch <rbranch> it fetches is a descendant of <lbranch>. This option overrides that check.
-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. This option disables this automatic tag following. The default behavior for a remote may be specified with the remote.<name>.tagOpt setting. See git-config[1].
-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.
--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.

<repository>: The "remote" repository that is the source of a fetch or pull 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>: 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 (see git-fetch[1]).
The format of a <refspec> parameter is an optional plus +, followed by the source ref <src>, followed by a colon :, followed by the destination ref <dst>. The colon can be omitted when <dst> is empty.
tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag>; it requests fetching everything up to the given tag.
The remote ref that matches <src> is fetched, and if <dst> is not empty string, the local ref that matches it is fast-forwarded using <src>. If the optional plus + is used, the local ref is updated even if it does not result in a fast-forward update.
Note
When the remote branch you want to fetch is known to be rewound and rebased regularly, it is expected that its new tip will not be descendant of its previous tip (as stored in your remote-tracking branch the last time you fetched). You would want to use the + sign to indicate non-fast-forward updates will be needed for such branches. There is no way to determine or declare that a branch will be made available in a repository with this behavior; the pulling user simply must know this is the expected usage pattern for a branch.
Note
There is a difference between listing multiple <refspec> directly on git pull command line and having multiple remote.<repository>.fetch entries in your configuration for a <repository> and running a git pull command without any explicit <refspec> parameters. <refspec>s listed explicitly on the command line are always merged into the current branch after fetching. In other words, if you list more than one remote ref, git pull will create an Octopus merge. On the other hand, if you do not list any explicit <refspec> parameter on the command line, git pull will fetch all the <refspec>s it finds in theremote.<repository>.fetch configuration and merge only the first <refspec> found into the current branch. This is because making an Octopus from remote refs is rarely done, while keeping track of multiple remote heads in one-go by fetching more than one is often useful.

urls.txt

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

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

URL: one of the above URL formatPush: <refspec>Pull: <refspec>

Push: lines are used by git push and Pull: lines are used by git pull and git fetch. MultiplePush: 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.

git fetch uses:

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

git push uses:

HEAD:refs/heads/<head>

MERGE STRATEGIES

The merge mechanism (git merge and git pull commands) allows the backend merge strategies to be chosen with -s option. Some strategies can also take their own options, which can be passed by giving -X<option> arguments to git merge and/or git pull.

resolve

This can only resolve two heads (i.e. the current branch and another branch you pulled from) using a 3-way merge algorithm. It tries to carefully detect criss-cross merge ambiguities and is considered generally safe and fast.

recursive

This can only resolve two heads using a 3-way merge algorithm. When there is more than one common ancestor that can be used for 3-way merge, it creates a merged tree of the common ancestors and uses that as the reference tree for the 3-way merge. This has been reported to result in fewer merge conflicts without causing mismerges by tests done on actual merge commits taken from Linux 2.6 kernel development history. Additionally this can detect and handle merges involving renames. This is the default merge strategy when pulling or merging one branch.

The recursive strategy can take the following options:

ours

This option forces conflicting hunks to be auto-resolved cleanly by favoring our version. Changes from the other tree that do not conflict with our side are reflected to the merge result. For a binary file, the entire contents are taken from our side.

This should not be confused with the ours merge strategy, which does not even look at what the other tree contains at all. It discards everything the other tree did, declaring our history contains all that happened in it.

theirs

This is the opposite of ours.

patience

With this option, merge-recursive spends a little extra time to avoid mismerges that sometimes occur due to unimportant matching lines (e.g., braces from distinct functions). Use this when the branches to be merged have diverged wildly. See also git-diff[1] --patience.

diff-algorithm=[patience|minimal|histogram|myers]

Tells merge-recursive to use a different diff algorithm, which can help avoid mismerges that occur due to unimportant matching lines (such as braces from distinct functions). See also git-diff[1] --diff-algorithm.

ignore-space-change

ignore-all-space

ignore-space-at-eol

Treats lines with the indicated type of whitespace change as unchanged for the sake of a three-way merge. Whitespace changes mixed with other changes to a line are not ignored. See also git-diff[1] -b, -w, and --ignore-space-at-eol.

If their version only introduces whitespace changes to a line, our version is used;
If our version introduces whitespace changes but their version includes a substantial change,their version is used;
Otherwise, the merge proceeds in the usual way.

renormalize

This runs a virtual check-out and check-in of all three stages of a file when resolving a three-way merge. This option is meant to be used when merging branches with different clean filters or end-of-line normalization rules. See "Merging branches with differing checkin/checkout attributes" in gitattributes[5] for details.

no-renormalize

Disables the renormalize option. This overrides the merge.renormalize configuration variable.

rename-threshold=<n>

Controls the similarity threshold used for rename detection. See also git-diff[1] -M.

subtree[=<path>]

This option is a more advanced form of subtree strategy, where the strategy makes a guess on how two trees must be shifted to match with each other when merging. Instead, the specified path is prefixed (or stripped from the beginning) to make the shape of two trees to match.

octopus

This resolves cases with more than two heads, but refuses to do a complex merge that needs manual resolution. It is primarily meant to be used for bundling topic branch heads together. This is the default merge strategy when pulling or merging more than one branch.

ours

This resolves any number of heads, but the resulting tree of the merge is always that of the current branch head, effectively ignoring all changes from all other branches. It is meant to be used to supersede old development history of side branches. Note that this is different from the -Xours option to the recursive merge strategy.

subtree

This is a modified recursive strategy. When merging trees A and B, if B corresponds to a subtree of A, B is first adjusted to match the tree structure of A, instead of reading the trees at the same level. This adjustment is also done to the common ancestor tree.

With the strategies that use 3-way merge (including the default, recursive), if a change is made on both branches, but later reverted on one of the branches, that change will be present in the merged result; some people find this behavior confusing. It occurs because only the heads and the merge base are considered when performing a merge, not the individual commits. The merge algorithm therefore considers the reverted change as no change at all, and substitutes the changed version instead.

DEFAULT BEHAVIOUR

Often people use git pull without giving any parameter. Traditionally, this has been equivalent to saying git pull origin. However, when configuration branch.<name>.remote is present while on branch <name>, that value is used instead of origin.

In order to determine what URL to use to fetch from, the value of the configuration remote.<origin>.url is consulted and if there is not any such variable, the value on URL: ` line in `$GIT_DIR/remotes/<origin> file is used.

In order to determine what remote branches to fetch (and optionally store in the remote-tracking branches) when the command is run without any refspec parameters on the command line, values of the configuration variable remote.<origin>.fetch are consulted, and if there aren’t any,$GIT_DIR/remotes/<origin> file is consulted and its `Pull: ` lines are used. In addition to the refspec formats described in the OPTIONS section, you can have a globbing refspec that looks like this:

refs/heads/*:refs/remotes/origin/*

A globbing refspec must have a non-empty RHS (i.e. must store what were fetched in remote-tracking branches), and its LHS and RHS must end with /*. The above specifies that all remote branches are tracked using remote-tracking branches in refs/remotes/origin/ hierarchy under the same name.

The rule to determine which remote branch to merge after fetching is a bit involved, in order not to break backward compatibility.

If explicit refspecs were given on the command line of git pull, they are all merged.

When no refspec was given on the command line, then git pull uses the refspec from the configuration or $GIT_DIR/remotes/<origin>. In such cases, the following rules apply:

If branch.<name>.merge configuration for the current branch <name> exists, that is the name of the branch at the remote site that is merged.
If the refspec is a globbing one, nothing is merged.
Otherwise the remote branch of the first refspec is merged.

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.

BUGS

GIT

Part of the git[1] suite

NAME

git-push - Update remote refs along with associated objects

SYNOPSIS

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

DESCRIPTION

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 uphooks 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 consultingremote.*.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).

OPTIONS

<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>.
The <src> is often the name of the branch you would want to push, but it can be any arbitrary "SHA-1 expression", such as master~4 or HEAD (see gitrevisions[7]).
The <dst> tells which ref on the remote side is updated with this push. Arbitrary expressions cannot be used here, an actual ref must be named. If git push [<repository>] without any<refspec> argument is set to update some ref at the destination with <src> with remote.<repository>.push configuration variable, :<dst> part can be omitted—such a push will update a ref that <src> normally updates without any <refspec> on the command line. Otherwise, missing :<dst> means to update the same ref as the <src>.
The object referenced by <src> is used to update the <dst> reference on the remote side. By default this is only allowed if <dst> is not a tag (annotated or lightweight), and then only if it can fast-forward <dst>. By having the optional leading +, you can tell Git to update the <dst> ref even if it is not allowed by default (e.g., it is not a fast-forward.) This does not attempt to merge <src> into <dst>. See EXAMPLES below for details.
tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag>.
Pushing an empty <src> allows you to delete the <dst> ref from the remote repository.
The special refspec : (or +: to allow non-fast-forward updates) directs Git to push "matching" branches: for every branch that exists on the local side, the remote side is updated if a branch of the same name already exists on the remote side.
--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 tmpwill 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.
--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 inrefs/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
--sign=(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.
--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.
Imagine that you have to rebase what you have already published. You will have to bypass the "must fast-forward" rule in order to replace the history you originally published with the rebased history. If somebody else built on top of your original history while you are rebasing, the tip of the branch at the remote may advance with her commit, and blindly pushing with --force will lose her work.
This option allows you to say that you expect the history you are updating is what you rebased and want to replace. If the remote ref still points at the commit you specified, you can be sure that no other people did anything to the ref. It is like taking a "lease" on the ref without explicitly locking it, and the remote ref is updated only if the "lease" is still valid.
--force-with-lease alone, without specifying the details, will protect all remote refs that are going to be updated by requiring their current value to be the same as the remote-tracking branch we have for them.
--force-with-lease=<refname>, without specifying the expected value, will protect the named ref (alone), if it is going to be updated, by requiring its current value to be the same as the remote-tracking branch we have for it.
--force-with-lease=<refname>:<expect> will protect the named ref (alone), if it is going to be updated, by requiring its current value to be the same as the specified value <expect> (which is allowed to be different from the remote-tracking branch we have for the refname, or we do not even have to have such a remote-tracking branch when this form is used).
Note that all forms other than --force-with-lease=<refname>:<expect> that specifies the expected current value of the ref explicitly are still experimental and their semantics may change as we gain experience with this feature.
"--no-force-with-lease" will cancel all the previous --force-with-lease on the command line.
-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.
This flag disables these checks, and can cause the remote repository to lose commits; use it with care.
Note that --force applies to all the refs that are pushed, hence using it with push.defaultset to matching or with multiple push destinations configured with remote.*.push may overwrite refs other than the current branch (including local refs that are strictly behind their remote counterpart). To force a push to only one branch, use a + in front of the refspec to push (e.g git push origin +master to force a push to the master branch). See the<refspec>... section above for details.
--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>.mergein 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.
--recurse-submodules=check|on-demand: 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.
--[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.

urls.txt

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

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

URL: one of the above URL formatPush: <refspec>Pull: <refspec>

Push: lines are used by git push and Pull: lines are used by git pull and git fetch. MultiplePush: 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.

git fetch uses:

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

git push uses:

HEAD:refs/heads/<head>

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

A single character indicating the status of the ref:

(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. See git-config[1].
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.

Note about fast-forwards

When an update changes a branch (or more in general, a ref) that used to point at commit A to point at another commit B, it is called a fast-forward update if and only if B is a descendant of A.

In a fast-forward update from A to B, the set of commits that the original commit A built on top of is a subset of the commits the new commit B builds on top of. Hence, it does not lose any history.

In contrast, a non-fast-forward update will lose history. For example, suppose you and somebody else started at the same commit X, and you built a history leading to commit B while the other person built a history leading to commit A. The history looks like this:

      B     / ---X---A

Further suppose that the other person already pushed changes leading to A back to the original repository from which you two obtained the original commit X.

The push done by the other person updated the branch that used to point at commit X to point at commit A. It is a fast-forward.

But if you try to push, you will attempt to update the branch (that now points at A) with commit B. This does not fast-forward. If you did so, the changes introduced by commit A will be lost, because everybody will now start building on top of B.

The command by default does not allow an update that is not a fast-forward to prevent such loss of history.

If you do not want to lose your work (history from X to B) or the work by the other person (history from X to A), you would need to first fetch the history from the repository, create a history that contains changes done by both parties, and push the result back.

You can perform "git pull", resolve potential conflicts, and "git push" the result. A "git pull" will create a merge commit C between commits A and B.

      B---C     /   / ---X---A

Updating A with the resulting merge commit will fast-forward and your push will be accepted.

Alternatively, you can rebase your change between X and B on top of A, with "git pull --rebase", and push the result back. The rebase will create a new commit D that builds the change between X and B on top of A.

      B   D     /   / ---X---A

Again, updating A with this commit will fast-forward and your push will be accepted.

There is another common situation where you may encounter non-fast-forward rejection when you try to push, and it is possible even when you are pushing into a repository nobody else pushes into. After you push commit A yourself (in the first picture in this section), replace it with "git commit --amend" to produce commit B, and you try to push it out, because forgot that you have pushed A out already. In such a case, and only if you are certain that nobody in the meantime fetched your earlier commit A (and started building on top of it), you can run "git push --force" to overwrite it. In other words, "git push --force" is a method reserved for a case where you do mean to lose history.

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 thepush 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 findrefs/heads/master), and update the same ref (e.g. refs/heads/master) in originrepository 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 themothership repository; do the same for dev and satellite/dev.

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 themothership 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 masterbranch. 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.

GIT

Part of the git[1] suite

0 0

Git Reference---Sharing and Updating Projects

NAME

SYNOPSIS

DESCRIPTION

OPTIONS

COMMANDS

DISCUSSION

Examples

SEE ALSO

GIT

NAME

SYNOPSIS

DESCRIPTION

OPTIONS

COMMANDS

DISCUSSION

Examples

SEE ALSO

GIT

NAME

SYNOPSIS

DESCRIPTION

OPTIONS

COMMANDS

DISCUSSION

Examples

SEE ALSO

GIT

NAME

SYNOPSIS

DESCRIPTION

OPTIONS

REMOTES

Named remote in configuration file

Named file in $GIT_DIR/remotes

Named file in $GIT_DIR/branches

CONFIGURED REMOTE-TRACKING BRANCHES

EXAMPLES

BUGS

SEE ALSO

GIT

NAME

SYNOPSIS

DESCRIPTION

OPTIONS

Options related to merging

Options related to fetching

REMOTES

Named remote in configuration file

Named file in $GIT_DIR/remotes

Named file in $GIT_DIR/branches

MERGE STRATEGIES

DEFAULT BEHAVIOUR

EXAMPLES

BUGS

SEE ALSO

GIT

NAME

SYNOPSIS

DESCRIPTION

OPTIONS

REMOTES

Named remote in configuration file

Named file in $GIT_DIR/remotes

Named file in $GIT_DIR/branches

OUTPUT

Note about fast-forwards

Examples

GIT

Named file in `$GIT_DIR/remotes`

Named file in `$GIT_DIR/branches`

Named file in `$GIT_DIR/remotes`

Named file in `$GIT_DIR/branches`

Named file in `$GIT_DIR/remotes`

Named file in `$GIT_DIR/branches`