Как настроить git remote

Managing remote repositories

In this article

Learn to work with your local repositories on your computer and remote repositories hosted on GitHub.

Adding a remote repository

To add a new remote, use the git remote add command on the terminal, in the directory your repository is stored at.

The git remote add command takes two arguments:

  • A remote name, for example, origin
  • A remote URL, for example, https://github.com/user/repo.git

For more information on which URL to use, see «About remote repositories.»

Troubleshooting: Remote origin already exists

This error means you’ve tried to add a remote with a name that already exists in your local repository.

To fix this, you can:

  • Use a different name for the new remote.
  • Rename the existing remote repository before you add the new remote. For more information, see «Renaming a remote repository» below.
  • Delete the existing remote repository before you add the new remote. For more information, see «Removing a remote repository» below.

Changing a remote repository’s URL

The git remote set-url command changes an existing remote repository URL.

Tip: For information on the difference between HTTPS and SSH URLs, see «About remote repositories.»

The git remote set-url command takes two arguments:

  • An existing remote name. For example, origin or upstream are two common choices.
  • A new URL for the remote. For example:
    • If you’re updating to use HTTPS, your URL might look like:
    • If you’re updating to use SSH, your URL might look like:

Switching remote URLs from SSH to HTTPS

  1. Open Terminal Terminal Git Bash .
  2. Change the current working directory to your local project.
  3. List your existing remotes in order to get the name of the remote you want to change.
  4. Change your remote’s URL from SSH to HTTPS with the git remote set-url command.
  5. Verify that the remote URL has changed.

The next time you git fetch , git pull , or git push to the remote repository, you’ll be asked for your GitHub username and password. When Git prompts you for your password, enter your personal access token (PAT). Alternatively, you can use a credential helper like Git Credential Manager. Password-based authentication for Git has been removed in favor of more secure authentication methods. For more information, see «Creating a personal access token.»

You can use a credential helper so Git will remember your GitHub username and personal access token every time it talks to GitHub.

Switching remote URLs from HTTPS to SSH

  1. Open Terminal Terminal Git Bash .
  2. Change the current working directory to your local project.
  3. List your existing remotes in order to get the name of the remote you want to change.
  4. Change your remote’s URL from HTTPS to SSH with the git remote set-url command.
  5. Verify that the remote URL has changed.

Troubleshooting: No such remote ‘[name]’

This error means that the remote you tried to change doesn’t exist:

Check that you’ve correctly typed the remote name.

Renaming a remote repository

Use the git remote rename command to rename an existing remote.

The git remote rename command takes two arguments:

  • An existing remote name, for example, origin
  • A new name for the remote, for example, destination

These examples assume you’re cloning using HTTPS, which is recommended.

Troubleshooting: Could not rename config section ‘remote.[old name]’ to ‘remote.[new name]’

This error means that the old remote name you typed doesn’t exist.

You can check which remotes currently exist with the git remote -v command:

Troubleshooting: Remote [new name] already exists

This error means that the remote name you want to use already exists. To solve this, either use a different remote name, or rename the original remote.

Removing a remote repository

Use the git remote rm command to remove a remote URL from your repository.

The git remote rm command takes one argument:

  • A remote name, for example, destination

Removing the remote URL from your repository only unlinks the local and remote repositories. It does not delete the remote repository.

These examples assume you’re cloning using HTTPS, which is recommended.

Note: git remote rm does not delete the remote repository from the server. It simply removes the remote and its references from your local repository.

Troubleshooting: Could not remove config section ‘remote.[name]’

This error means that the remote you tried to delete doesn’t exist:

Check that you’ve correctly typed the remote name.

Help us make these docs great!

All GitHub docs are open source. See something that’s wrong or unclear? Submit a pull request.

Читайте также:  Как настроить canon usm

Источник

2.5 Git Basics — Working with Remotes

Working with Remotes

To be able to collaborate on any Git project, you need to know how to manage your remote repositories. Remote repositories are versions of your project that are hosted on the Internet or network somewhere. You can have several of them, each of which generally is either read-only or read/write for you. Collaborating with others involves managing these remote repositories and pushing and pulling data to and from them when you need to share work. Managing remote repositories includes knowing how to add remote repositories, remove remotes that are no longer valid, manage various remote branches and define them as being tracked or not, and more. In this section, we’ll cover some of these remote-management skills.

It is entirely possible that you can be working with a “remote” repository that is, in fact, on the same host you are. The word “remote” does not necessarily imply that the repository is somewhere else on the network or Internet, only that it is elsewhere. Working with such a remote repository would still involve all the standard pushing, pulling and fetching operations as with any other remote.

Showing Your Remotes

To see which remote servers you have configured, you can run the git remote command. It lists the shortnames of each remote handle you’ve specified. If you’ve cloned your repository, you should at least see origin — that is the default name Git gives to the server you cloned from:

You can also specify -v , which shows you the URLs that Git has stored for the shortname to be used when reading and writing to that remote:

If you have more than one remote, the command lists them all. For example, a repository with multiple remotes for working with several collaborators might look something like this.

This means we can pull contributions from any of these users pretty easily. We may additionally have permission to push to one or more of these, though we can’t tell that here.

Notice that these remotes use a variety of protocols; we’ll cover more about this in Getting Git on a Server.

Adding Remote Repositories

We’ve mentioned and given some demonstrations of how the git clone command implicitly adds the origin remote for you. Here’s how to add a new remote explicitly. To add a new remote Git repository as a shortname you can reference easily, run git remote add :

Now you can use the string pb on the command line in lieu of the whole URL. For example, if you want to fetch all the information that Paul has but that you don’t yet have in your repository, you can run git fetch pb :

Paul’s master branch is now accessible locally as pb/master — you can merge it into one of your branches, or you can check out a local branch at that point if you want to inspect it. We’ll go over what branches are and how to use them in much more detail in Git Branching.

Fetching and Pulling from Your Remotes

As you just saw, to get data from your remote projects, you can run:

The command goes out to that remote project and pulls down all the data from that remote project that you don’t have yet. After you do this, you should have references to all the branches from that remote, which you can merge in or inspect at any time.

If you clone a repository, the command automatically adds that remote repository under the name “origin”. So, git fetch origin fetches any new work that has been pushed to that server since you cloned (or last fetched from) it. It’s important to note that the git fetch command only downloads the data to your local repository — it doesn’t automatically merge it with any of your work or modify what you’re currently working on. You have to merge it manually into your work when you’re ready.

If your current branch is set up to track a remote branch (see the next section and Git Branching for more information), you can use the git pull command to automatically fetch and then merge that remote branch into your current branch. This may be an easier or more comfortable workflow for you; and by default, the git clone command automatically sets up your local master branch to track the remote master branch (or whatever the default branch is called) on the server you cloned from. Running git pull generally fetches data from the server you originally cloned from and automatically tries to merge it into the code you’re currently working on.

Читайте также:  Как настроить местоположение на часах детских геозон

From git version 2.27 onward, git pull will give a warning if the pull.rebase variable is not set. Git will keep warning you until you set the variable.

If you want the default behavior of git (fast-forward if possible, else create a merge commit): git config —global pull.rebase «false»

If you want to rebase when pulling: git config —global pull.rebase «true»

Pushing to Your Remotes

When you have your project at a point that you want to share, you have to push it upstream. The command for this is simple: git push
. If you want to push your master branch to your origin server (again, cloning generally sets up both of those names for you automatically), then you can run this to push any commits you’ve done back up to the server:

This command works only if you cloned from a server to which you have write access and if nobody has pushed in the meantime. If you and someone else clone at the same time and they push upstream and then you push upstream, your push will rightly be rejected. You’ll have to fetch their work first and incorporate it into yours before you’ll be allowed to push. See Git Branching for more detailed information on how to push to remote servers.

Inspecting a Remote

If you want to see more information about a particular remote, you can use the git remote show command. If you run this command with a particular shortname, such as origin , you get something like this:

It lists the URL for the remote repository as well as the tracking branch information. The command helpfully tells you that if you’re on the master branch and you run git pull , it will automatically merge the remote’s master branch into the local one after it has been fetched. It also lists all the remote references it has pulled down.

That is a simple example you’re likely to encounter. When you’re using Git more heavily, however, you may see much more information from git remote show :

This command shows which branch is automatically pushed to when you run git push while on certain branches. It also shows you which remote branches on the server you don’t yet have, which remote branches you have that have been removed from the server, and multiple local branches that are able to merge automatically with their remote-tracking branch when you run git pull .

Renaming and Removing Remotes

You can run git remote rename to change a remote’s shortname. For instance, if you want to rename pb to paul , you can do so with git remote rename :

It’s worth mentioning that this changes all your remote-tracking branch names, too. What used to be referenced at pb/master is now at paul/master .

If you want to remove a remote for some reason — you’ve moved the server or are no longer using a particular mirror, or perhaps a contributor isn’t contributing anymore — you can either use git remote remove or git remote rm :

Once you delete the reference to a remote this way, all remote-tracking branches and configuration settings associated with that remote are also deleted.

Источник

Как настроить git remote

Check your version of git by running

git-remote — Manage set of tracked repositories

SYNOPSIS

DESCRIPTION

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

OPTIONS

Be a little more verbose and show remote url after name. For promisor remotes, also show which filter ( blob:none etc.) are configured. NOTE: This must be placed between remote and subcommand.

COMMANDS

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

Add a remote named for the repository at . The command git fetch can then be used to create and update remote-tracking branches /
.

With -f option, git fetch is run immediately after the remote information is set up.

With —tags option, git fetch imports every tag from the remote repository.

With —no-tags option, git fetch does not import tags from the remote repository.

By default, only tags on fetched branches are imported (see git-fetch[1]).

With -t
option, instead of the default glob refspec for the remote to track all branches under the refs/remotes/ / namespace, a refspec to track only
is created. You can give more than one -t
to track multiple branches without grabbing all branches.

With -m option, a symbolic-ref refs/remotes/ /HEAD is set up to point at remote’s branch. See also the set-head command.

When a fetch mirror is created with —mirror=fetch , the refs will not be stored in the refs/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 the remote named

    to . All remote-tracking branches and configuration settings for the remote are updated.

In case

    and are the same, and
      is a file under $GIT_DIR/remotes or $GIT_DIR/branches , the remote is converted to the configuration file format.

    Remove the remote named . All remote-tracking branches and configuration settings for the remote are removed.

    Sets or deletes the default branch (i.e. the target of the symbolic-ref refs/remotes/ /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/ /HEAD is deleted.

    With -a or —auto , the remote is queried to determine its HEAD , then the symbolic-ref refs/remotes/ /HEAD is set to the same branch. e.g., if the remote HEAD is pointed at next , git remote set-head origin -a will set the symbolic-ref refs/remotes/origin/HEAD to refs/remotes/origin/next . This will only work if refs/remotes/origin/next already exists; if not it must be fetched first.

    Use
    to set the symbolic-ref refs/remotes/ /HEAD explicitly. e.g., git remote set-head origin master will set the symbolic-ref refs/remotes/origin/HEAD to refs/remotes/origin/master . This will only work if refs/remotes/origin/master already exists; if not it must be fetched first.

    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 add command line.

    With —add , instead of replacing the list of currently tracked branches, adds to that list.

    Retrieves the URLs for a remote. Configurations for insteadOf and pushInsteadOf are expanded here. By default, only the first URL is listed.

    With —push , push URLs are queried rather than fetch URLs.

    With —all , all URLs for the remote will be listed.

    Changes URLs for the remote. Sets first URL for remote that matches regex

      (first URL if no
        is given) to . If
          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 are deleted for remote . 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.

        Gives some information about the remote .

        With -n option, the remote heads are not queried first with git ls-remote ; cached information is used instead.

        Deletes stale references associated with . By default, stale remote-tracking branches under are deleted, but depending on global configuration and the configuration of the remote we might even prune local tags that haven’t been pushed there. Equivalent to git fetch —prune , except that no new references will be fetched.

        See the PRUNING section of git-fetch[1] for what it’ll prune depending on various configuration.

        With —dry-run option, report what branches would be pruned, but do not actually prune them.

        Fetch updates for remotes or remote groups in the repository as defined by remotes. . If neither group nor remote is 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. .skipDefaultUpdate set to true will be updated. (See git-config[1]).

        With —prune option, run pruning against all the remotes that are updated.

        DISCUSSION

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

        EXIT STATUS

        On success, the exit status is 0 .

        When subcommands such as add, rename, and remove can’t find the remote in question, the exit status is 2 . When the remote already exists, the exit status is 3 .

        On any other error, the exit status may be any other non-zero value.

        EXAMPLES

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

        Imitate git clone but track only selected branches

        Источник

Поделиться с друзьями
Инструкции360