跳转到主要内容

urls-remotes

GIT URLS ----------------

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

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

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

The following syntaxes may be used with them:

  • ssh://[<user>@]<host>[:<port>]/<path-to-git-repo>

  • git://<host>[:<port>]/<path-to-git-repo>

  • http[s]://<host>[:<port>]/<path-to-git-repo>

  • ftp[s]://<host>[:<port>]/<path-to-git-repo>

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

  • [<user>@]<host>:/<path-to-git-repo>

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

The ssh and git protocols additionally support ~<username> expansion:

  • ssh://[<user>@]<host>[:<port>]/~<user>/<path-to-git-repo>

  • git://<host>[:<port>]/~<user>/<path-to-git-repo>

  • [<user>@]<host>:~<user>/<path-to-git-repo>

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

  • /path/to/repo.git/

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

ifndef::git-clone[] These two syntaxes are mostly equivalent, except when cloning, when the former implies --local option. See linkgit:git-clone[1] for details. endif::git-clone[]

ifdef::git-clone[] These two syntaxes are mostly equivalent, except the former implies --local option. endif::git-clone[]

git clone, git fetch and git pull, but not git push, will also accept a suitable bundle file. See linkgit:git-bundle[1].

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

  • <transport>::<address>

where <address> may be a path, a server and path, or an arbitrary URL-like string recognized by the specific remote helper being invoked. See linkgit:gitremote-helpers[7] for details.

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

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

For example, with this:

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

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

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

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

For example, with this:

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

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

REMOTES ------------------

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

  • a remote in the Git configuration file: $GIT_DIR/config,

  • a file in the $GIT_DIR/remotes directory, or

  • a file in the $GIT_DIR/branches directory.

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

Named remote in configuration file ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

You can choose to provide the name of a remote which you had previously configured using linkgit:git-remote[1], linkgit: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>. Pushing to a remote affects all defined pushurls or all defined urls if no pushurls are defined. Fetch, however, will only fetch from the first defined url if multiple urls are defined.

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 formats
    Push: <refspec>
    Pull: <refspec>

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

Named file in $GIT_DIR/branches ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

    <URL>#<head>

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

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

git fetch uses:

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

git push uses:

    HEAD:refs/heads/<head>

UPSTREAM BRANCHES -----------------

Branches in Git can optionally have an upstream remote branch. Git defaults to using the upstream branch for remote operations, for example:

  • It’s the default for git pull or git fetch with no arguments.

  • It’s the default for git push with no arguments, with some exceptions. For example, you can use the branch.<name>.pushRemote option to push to a different remote than you pull from, and by default with push.default=simple the upstream branch you configure must have the same name.

  • Various commands, including git checkout and git status, will show you how many commits have been added to your current branch and the upstream since you forked from it, for example "Your branch and ’origin/main’ have diverged, and have 2 and 3 different commits each respectively".

The upstream is stored in .git/config, in the “remote” and “merge” fields. For example, if main’s upstream is origin/main:

[branch "main"]
   remote = origin
   merge = refs/heads/main

You can set an upstream branch explicitly with git push --set-upstream <remote> <branch> but Git will often automatically set the upstream for you, for example:

  • When you clone a repository, Git will automatically set the upstream for the default branch.

  • If you have the push.autoSetupRemote configuration option set, git push will automatically set the upstream the first time you push a branch.

  • Checking out a remote-tracking branch with git checkout <branch> will automatically create a local branch with that name and set the upstream to the remote branch.

Upstream branches are sometimes referred to as "tracking information", as in "set the branch’s tracking information".

这篇文档对你有帮助吗？
想留言或继续讨论？请到 Cyberforums 赛博论坛参与。 参与讨论 / 回复