Удалённый репозиторий в Git: практический пример
Подключим локальный проект к удалённому репозиторию, отправим первый коммит и разберём, что делать при расхождении истории. Пример подходит для Git 2.x и не привязан к конкретному хостингу.

Если проект уже хранится на вашем компьютере, удалённый репозиторий поможет отправить его копию на сервер и синхронизировать работу с другими людьми. Ниже — практический сценарий для Git 2.x: создаём пустой репозиторий на хостинге, связываем его с локальной папкой и отправляем ветку. Команды одинаковы для GitHub, GitLab и собственного Git-сервера; адрес репозитория будет отличаться.
Что понадобится
Проверьте, что Git установлен, а на выбранном хостинге вы создали пустой репозиторий. Если локальный проект уже содержит коммиты, не добавляйте при создании удалённого репозитория README, лицензию или файл .gitignore: хостинг может создать отдельную историю, и первый push придётся разруливать вручную.
- Git 2.x и терминал.
- Локальная папка проекта, в которой уже есть Git-репозиторий. Проверить это можно командой
git status. - Адрес репозитория, скопированный со страницы хостинга. Это может быть HTTPS- или SSH-адрес.
- Настроенная аутентификация: для HTTPS хостинг может требовать токен вместо пароля, для SSH — ключ. Не вставляйте токен в команду или публичный файл.
Удалённый репозиторий1 — сохранённая в Git ссылка на другой репозиторий. Имя origin — распространённое, но не обязательное: можно выбрать любое.
Подключаем проект и отправляем ветку
Перейдите в папку проекта. Если Git ещё не инициализирован, сначала создайте репозиторий и сделайте начальный коммит. В этом примере предполагается, что локальная история уже есть.
- Посмотрите текущую ветку и состояние проекта. Выполните
git status. В сообщении должна быть указана текущая ветка, напримерmain, и не должно быть неожиданных изменений. Если Git сообщает, что это не репозиторий, проверьте, в ту ли папку вы перешли. - Добавьте адрес сервера. Подставьте адрес из настроек репозитория вместо заглушки и выполните команду:
git remote add origin YOUR_REPOSITORY_URL
Здесьorigin— выбранное вами имя удалённого репозитория. Проверьте результат командойgit remote -v: адрес должен появиться для fetch и push. - Проверьте локальные коммиты. Выполните
git log -1 --oneline. Git должен показать последний коммит. Если коммитов нет, сначала добавьте нужные файлы черезgit add, затем создайте коммит командойgit commit -m "Initial commit". Повторная проверка должна показать созданный коммит. - Отправьте текущую ветку. Узнайте её имя через
git branch --show-current, затем используйте его в команде:git push -u origin YOUR_BRANCH
Например, если команда показалаmain, отправляйтеgit push -u origin main. Успех — Git сообщил, что ветка отправлена, а страница репозитория показывает ваши файлы и коммиты. - Проверьте связь после отправки. Выполните
git status. Если локальная ветка теперь отслеживаетorigin/mainили другую указанную ветку и изменений нет, связь настроена. В дальнейшем для отправки новых коммитов обычно достаточноgit push.
Флаг -u задаёт upstream: связь локальной ветки с веткой на сервере. После первой отправки Git запоминает эту пару, поэтому не приходится каждый раз указывать и сервер, и ветку.
Если удалённый репозиторий пустой, первый push обычно прост. Если на сервере уже есть собственный коммит, сначала выясните, какую историю вы хотите сохранить: бездумный push может закончиться отказом, а принудительная отправка — удалить доступные на сервере изменения.
Какой адрес выбрать: HTTPS или SSH
Это два способа аутентифицироваться на сервере, а не два формата Git-истории. HTTPS часто проще начать использовать: вход обычно проходит через браузер или менеджер учётных данных. SSH удобен при постоянной работе с сервером, когда ключ уже установлен и зарегистрирован в аккаунте. Поддержка конкретного способа зависит от настроек хостинга.
| Способ | Когда удобен | Что проверить |
|---|---|---|
| HTTPS | Первое подключение или доступ через корпоративную сеть | Требует ли хостинг токен, настроен ли менеджер учётных данных |
| SSH | Регулярная работа с серверами и несколькими репозиториями | Добавлен ли публичный ключ в аккаунт и совпадает ли SSH-адрес |
Не храните токен в URL удалённого репозитория и не отправляйте его в переписке. Если доступ отозвали, обновите учётные данные способом, который рекомендует ваш хостинг.
Что делать, если push не проходит
Git сообщает, что репозиторий не найден
Проверьте адрес командой git remote -v: в нём могут быть опечатка, лишний путь или ссылка на другой проект. Убедитесь также, что у вашей учётной записи есть доступ. Исправить адрес можно командой git remote set-url origin YOUR_REPOSITORY_URL, затем повторите git remote -v.
Ошибка аутентификации
Сначала выясните, каким адресом вы подключились: HTTPS или SSH. Для HTTPS проверьте требования хостинга к токенам и сохранённым учётным данным; для SSH — добавлен ли публичный ключ к нужному аккаунту. Не пытайтесь исправить ошибку, добавляя секрет в команду или конфигурационный файл проекта.
Отказ из-за непохожей истории
Сообщение вроде rejected или fetch first часто означает, что на сервере уже есть коммиты, которых нет локально. Это бывает, если при создании репозитория хостинг добавил README. Сначала получите изменения командой git fetch origin и сравните ветки через git log --oneline --graph --decorate --all. После этого выберите, как объединять истории. Если в обеих ветках есть нужные изменения, не используйте git push --force как быстрый способ убрать отказ.
Локальная ветка называется иначе
Если Git пишет, что указанной ветки нет, выполните git branch --show-current и подставьте фактическое имя в команду push. Название ветки на сервере задаётся последним аргументом команды, поэтому оно не обязано автоматически совпадать с именем локальной.
Когда что выбирать
Для нового проекта с пустым удалённым репозиторием достаточно добавить remote и выполнить push. Если вы только скачиваете существующий проект, начинайте с git clone: эта команда сама создаёт локальную копию и настраивает связь с сервером. Если сервер уже содержит коммиты, сначала получите их и разберите расхождение истории; не переписывайте её принудительной отправкой, пока не убедились, что это безопасно для остальных участников.
Главная проверка после настройки — не только успешное сообщение push. Убедитесь, что на сервере появилась нужная ветка, а следующий git status показывает ожидаемую связь. Если над проектом работают другие люди, договоритесь, кто и когда отправляет изменения, чтобы не перезаписывать чужую работу.
Следующий шаг: настройте привычный цикл
После первого push внесите небольшое изменение, создайте коммит и отправьте его ещё раз. Затем проверьте, что изменение видно на странице репозитория. Если вы работаете в команде, до следующей отправки получите актуальные изменения с сервера: Git не синхронизирует файлы автоматически. Инвалидация или восстановление удалённых веток — отдельные задачи; здесь разобрали только подключение и обычную первую отправку.
1 В Git удалённый репозиторий — не обязательно отдельный сервер: это может быть другой каталог или сервис хостинга, доступный по настроенному адресу.
Юрист-консультант (ГК/ТК/НК РФ): Правовые консультации, претензии, локальные нормативные акты.
Спросить за 20 ₽Источники: Git — Working with Remotes, Git — git-push Documentation
Частые вопросы
Нужно ли называть удалённый репозиторий origin?
Что делать, если на хостинге уже есть README?
Можно ли работать без SSH-ключа?
Почему команда git push без аргументов не срабатывает?
Что делать, если push отклонён, а я не успеваю разобраться?
Можно ли подключить несколько удалённых репозиториев?
Материал носит информационный характер и подготовлен редакцией «Агентуры». Он не является офертой, рекламой или индивидуальной консультацией. Упомянутые продукты, компании и торговые знаки принадлежат их правообладателям. Перед принятием решений, влекущих юридические или финансовые последствия, обратитесь к профильному специалисту.