Управление удаленными репозиториями
Узнайте, как работать с локальными репозиториями на компьютере и удаленными репозиториями, размещенными в GitHub.
Platform navigation
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/OWNER/REPOSITORY.git
$ git remote add origin https://github.com/OWNER/REPOSITORY.git # Set a new remote $ git remote -v # Verify new remote > origin https://github.com/OWNER/REPOSITORY.git (fetch) > origin https://github.com/OWNER/REPOSITORY.git (push)
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.
$ git remote add origin https://github.com/octocat/Spoon-Knife.git > fatal: remote origin already exists.
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:
https://github.com/OWNER/REPOSITORY.git- If you’re updating to use SSH, your URL might look like:
git@github.com:OWNER/REPOSITORY.gitSwitching remote URLs from SSH to HTTPS
- Open Terminal Terminal Git Bash .
- Change the current working directory to your local project.
- List your existing remotes in order to get the name of the remote you want to change.
$ git remote -v > origin git@github.com:OWNER/REPOSITORY.git (fetch) > origin git@github.com:OWNER/REPOSITORY.git (push)git remote set-url origin https://github.com/OWNER/REPOSITORY.git$ git remote -v # Verify new remote URL > origin https://github.com/OWNER/REPOSITORY.git (fetch) > origin https://github.com/OWNER/REPOSITORY.git (push)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. 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 «Managing your personal access tokens.»
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
- Open Terminal Terminal Git Bash .
- Change the current working directory to your local project.
- List your existing remotes in order to get the name of the remote you want to change.
$ git remote -v > origin https://github.com/OWNER/REPOSITORY.git (fetch) > origin https://github.com/OWNER/REPOSITORY.git (push)git remote set-url origin git@github.com:OWNER/REPOSITORY.git$ git remote -v # Verify new remote URL > origin git@github.com:OWNER/REPOSITORY.git (fetch) > origin git@github.com:OWNER/REPOSITORY.git (push)Troubleshooting: No such remote ‘[name]’
This error means that the remote you tried to change doesn’t exist:
$ git remote set-url sofake https://github.com/octocat/Spoon-Knife > fatal: No such remote 'sofake'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
Example of renaming a remote repository
These examples assume you’re cloning using HTTPS, which is recommended.
$ git remote -v # View existing remotes > origin https://github.com/OWNER/REPOSITORY.git (fetch) > origin https://github.com/OWNER/REPOSITORY.git (push) $ git remote rename origin destination # Change remote name from 'origin' to 'destination' $ git remote -v # Verify remote's new name > destination https://github.com/OWNER/REPOSITORY.git (fetch) > destination https://github.com/OWNER/REPOSITORY.git (push)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:
$ git remote -v # View existing remotes > origin https://github.com/OWNER/REPOSITORY.git (fetch) > origin https://github.com/OWNER/REPOSITORY.git (push)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.
Example of removing a remote repository
These examples assume you’re cloning using HTTPS, which is recommended.
$ git remote -v # View current remotes > origin https://github.com/OWNER/REPOSITORY.git (fetch) > origin https://github.com/OWNER/REPOSITORY.git (push) > destination https://github.com/FORKER/REPOSITORY.git (fetch) > destination https://github.com/FORKER/REPOSITORY.git (push) $ git remote rm destination # Remove remote $ git remote -v # Verify it's gone > origin https://github.com/OWNER/REPOSITORY.git (fetch) > origin https://github.com/OWNER/REPOSITORY.git (push)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:
$ git remote rm sofake > error: Could not remove config section 'remote.sofake'Check that you’ve correctly typed the remote name.
Further reading
Git — смена репозитория для загрузки
Продолжаю изучение темы Git и GitHub. На повестке дня стоит вопрос — каким образом можно изменить ссылку существующего репозитория?
Нет — не так! Попробую зайти с другой стороны и сказать иначе. Имеется готовый репозиторий Template, размещенный на сервере GitHub. Этот репозиторий является шаблоном (template starter) при создании разнообразных проектов. Нечто похожим на известный HTML5 Boilerplate.
Репозиторий Template клонируется на локальную машину с именем разрабатываемого проекта, такой командой:
$ git clone https://github.com/gearmobile/template.git projectЗатем в созданном репозитории Project разрабатывается требуемый проект.
Но есть одно НО — необходимо преобразовать видоизмененный репозиторий Project в отдельный, самостоятельный репозиторий. Конечно, по большому счету, это уже и есть отдельный, самостоятельный репозиторий.
Но вот ссылка у репозитория Project указывает на оригинал — репозиторий Template. И если произвести
push
на GitHub, то произойдет обновление репозитория Template.
А этого крайне нежелательно допустить, так как этот репозиторий является стартовым, чистым листом для всех новых проектов!
У меня же стоит такая задача — скопировать стартовый репозиторий Template на локальную машину, преобразовать его в конкретный проект, вновь залить на GitHub уже как самостоятельный репозиторий с именем проекта в качестве имени репозитория. Как поступить?
Можно решить вопрос несколькими способами. Ниже приведу пару из них — самых простых и доступных для моего понимания вечного newbie в Git\GitHub. Может быть, по мере освоения темы дополню статью более универсальным и грамотным способом.
Правка config
У клонированного на локальную машину репозитория ссылка на его удаленный оригинал размещена в конфигурационном файле
Как переключатся между удаленными репозитриями?
Не могу понять как работать когда я подключил несколько репозиториев:
Допустим у меня есть два репозитория(не ветки) (два разных проекта). Как мне переключаться между ними?
- Вопрос задан более трёх лет назад
- 5790 просмотров
Комментировать
Решения вопроса 1
Разные репозитории — разные директории.
Ответ написан более трёх лет назад
Комментировать
Нравится 6 Комментировать
Ответы на вопрос 2Это работает при условии что проект один и тот же, просто хранится в двух разных местах.
Добавить сервер к папке:
git remote add [сокращение] [url]Чтобы переключиться на ветку другого репозитория:
git fetch [сокращение] [ветка] git checkout -b [лок. ветка] [сокращение]/[ветка]Залить изменения на сервер:
git push [сокращение] [ветка]
Ответ написан более трёх лет назад
Комментировать
Нравится 2 Комментировать
Andreo @chupacabramiamor
Инженегр-программистДва разных проекта должны физически лежать в разных директориях и к каждому проекту подключен свой репозиторий. И не нужно ничего переключать. Это неправильно!
Git checkout
На этой странице рассматривается команда git checkout , включая примеры использования и пограничные случаи. В Git под термином checkout подразумевают переключение между различными версиями целевого объекта. Команда git checkout работает с тремя различными объектами: файлами, коммитами и ветками. Под переключением также обычно понимают действие, связанное с выполнением команды git checkout . В рамках темы «Отмена изменений» мы рассмотрели, каким образом команду git checkout можно использовать для просмотра старых коммитов. В этом документе основное внимание будет уделено операциям переключения на ветки.
Переключение веток аналогично переключению старых коммитов и файлов, в которых рабочий каталог обновляется в соответствии с выбранной веткой/ревизией; вместе с тем новые изменения сохраняются в истории проекта, то есть это не просто операция чтения.
Переключение веток
Команда git checkout позволяет перемещаться между ветками, созданными командой git branch . При переключении ветки происходит обновление файлов в рабочем каталоге в соответствии с версией, хранящейся в этой ветке, а Git начинает записывать все новые коммиты в этой ветке. Рассматривайте эту команду как способ выбрать направление своей разработки.
Наличие выделенной ветки для каждой новой функции сильно отличается от традиционного рабочего процесса в SVN. Это значительно облегчает проведение новых экспериментов без страха разрушить существующую функциональность и позволяет одновременно работать со множеством несвязанных функций. Кроме того, ветки облегчают ведение нескольких совместных рабочих процессов.
Иногда команду git checkout можно спутать с командой git clone . Разница между этими двумя командами заключается в том, что при клонировании (clone) выполняется извлечение кода из удаленного репозитория, тогда как при переключении (checkout) происходит переключение между версиями кода, который уже находится в локальной системе.

Связанные материалы
Расширенный журнал Git
СМ. РЕШЕНИЕ
Изучите Git с помощью Bitbucket Cloud
Использование: существующие ветки
Если предположить, что ваш рабочий репозиторий уже содержит существующие ветки, вы можете переключаться между этими ветками с помощью команды git checkout . Чтобы узнать, какие ветки доступны и как называется текущая ветка, выполните команду git branch .
$> git branch
main
another_branch
feature_inprogress_branch
$> git checkout feature_inprogress_branchВ вышеприведенном примере показано, как просмотреть список доступных веток с помощью команды git branch и переключиться на конкретную ветку (в данном случае — на ветку feature_inprogress_branch ).
Новые ветки
Команда git checkout часто используется вместе с командой git branch. С помощью команды git branch можно создать новую ветку. Когда вы захотите начать работу над новой функцией, создайте новое ответвление от ветки main с помощью команды git branch new_branch . Затем переключитесь на новую ветку с помощью команды git checkout new_branch . Команда git checkout также принимает аргумент -b , который действует как вспомогательный метод, позволяя создать новую ветку и сразу переключиться на нее. Вы можете работать сразу с несколькими функциями в одном репозитории, переключаясь между ними с помощью git checkout .
git checkout -b <new-branch>В вышеприведенном примере одновременно создается ветка и сразу же выполняется переключение на нее. Опция -b — это удобный способ сообщить системе Git, чтобы она выполнила команду git branch перед выполнением команды git checkout .
git checkout -b <new-branch> <existing-branch>По умолчанию команда git checkout -b создает ветку новая-ветка от текущего указателя HEAD . Команде git checkout можно передать необязательный параметр с указанием ветки. В приведенном выше примере передается < существующая-ветка> , поэтому новая-ветка будет создана от ветки существующая-ветка , а не от текущего указателя HEAD .
Переключение веток
Переключение веток — простая операция. При выполнении следующей команды указатель HEAD будет перенесен на последний коммит ветки .
git checkout <branchname>Git отслеживает историю операций переключения в журнале ссылок reflog. Чтобы просмотреть эту историю, выполните команду git reflog .
Переключение на удаленную ветку
При совместной работе команды нередко используют удаленные репозитории. Такие репозитории могут размещаться на сервере с предоставлением общего доступа либо это может быть локальная копия другого коллеги. Каждый удаленный репозиторий содержит собственный набор веток. Для переключения на удаленную ветку нужно сначала извлечь содержимое этой ветки.
git fetch --allВ современных версиях Git переключение на удаленную ветку не отличается от переключения на локальную ветку.
git checkout <remotebranch>В старых версиях Git необходимо создавать новую ветку на основе удаленного репозитория ( remote ).
git checkout -b <remotebranch> origin/<remotebranch>Кроме того, можно переключиться на новую локальную ветку и сбросить ее до последнего коммита удаленной ветки.
git checkout -b <branchname>
git reset --hard origin/<branchname>Открепленные указатели HEAD
Теперь, когда мы рассмотрели три основных варианта использования команды git checkout на ветках, важно обсудить состояние detached HEAD , или состояние открепленного указателя HEAD. Помните, что HEAD — это указатель на текущий снимок в Git. По сути дела, команда git checkout просто обновляет указатель HEAD , чтобы он ссылался на указанную ветку или коммит. Когда HEAD указывает на ветку, Git молчит, но при попытке переключиться на коммит система переходит в состояние detached HEAD (открепленный указатель HEAD).
Это сообщение предупреждает о том, что вся текущая работа «откреплена» от остальной части вашего проекта. Если вы начнете разрабатывать функцию, находясь в состоянии открепленного указателя HEAD , у вас не будет ветки, которая позволила бы вам вернуться к этой функции. Когда вы неизбежно переключитесь на другую ветку (например, чтобы слить код своей функции), вы уже никак не сможете сослаться на свою функцию:
Всегда ведите разработку на ветке, а не на открепленном указателе HEAD . Это гарантия того, что у вас всегда будет ссылка на ваши новые коммиты. Вместе с тем при просмотре предыдущего коммита состояние указателя HEAD не имеет значения: он может быть как откреплен, так и нет.
Резюме
На этой странице было рассмотрено использование команды git checkout при смене ветки. В общем и целом при использовании команды git checkout на ветках происходит изменение позиции указателя HEAD . С помощью этой команды можно создавать ветки, менять текущую ветку и переключаться на удаленные ветки. Команда git checkout — важный инструмент при стандартной работе в Git. Она представляет собой аналог команды git merge. Команды git checkout и git merge критически важны для реализации рабочих процессов Git.