Удалённые репозитории: push и pull

удалённые репозитории позволяют синхронизировать код между разработчиками и хранить его на сервере.

Почему это важно: Без понимания remote, push и pull невозможно работать в команде, настроить CI/CD или деплоить код.

Главная идея

Удалённый репозиторий (remote) — это копия репозитория на сервере. push отправляет коммиты туда, pull — забирает оттуда.

Как это выглядит на практике

git remote add origin связывает локальный репозиторий с удалённым.
git push -u origin main отправляет ветку main на сервер.
Коллега делает git clone и получает полную копию репозитория.
git pull забирает новые коммиты с сервера и обновляет локальную ветку.

Что происходит под капотом

git fetch скачивает новые объекты с remote, но не изменяет рабочую ветку.
git pull = git fetch + git merge (или git rebase при --rebase).
origin — стандартное имя для основного remote; можно добавить несколько remote.
Tracking branches (origin/main) — локальные ссылки на состояние remote-веток.

Типичные ошибки и заблуждения

Ошибка: git push автоматически создаёт ветку на remote. Нужно явно указать -u origin при первом push.
Ошибка: pull всегда безопасен. Если в remote есть коммиты, которых нет локально, может возникнуть merge или конфликт.
Ошибка: git clone копирует только последнюю версию. clone скачивает всю историю.
Ошибка: force push (push --force) — нормальная операция. Это разрушительная команда, которая перезаписывает историю на remote.

Ключевые выводы

Remote — это просто URL и набор отслеживаемых веток.
git fetch безопасен: он только скачивает данные без изменения рабочих файлов.
git pull может вызвать конфликты — это нормально.
Никогда не force-push в общие ветки (main, develop).

Термины урока

Remote: именованный URL удалённого репозитория.

push: отправка локальных коммитов на remote.

pull: получение коммитов с remote и обновление ветки.

clone: полное копирование репозитория с историей.

Связь с работой backend-разработчика

В CI/CD пайплайне push в определённую ветку запускает автоматический деплой. Понимание push/pull критично для настройки процесса доставки кода.

Мини-разбор реальной ситуации

Разработчик делает git push, но получает rejected. Причина: remote содержит новые коммиты, которых нет локально. Решение: сначала git pull --rebase, разрешить конфликты (если есть), затем снова git push.

Что запомнить

Перед push всегда делайте git pull, чтобы синхронизировать историю.
git fetch безопасен, git pull — нет (может вызвать конфликт).
force push в main — критическая ошибка в командной разработке.

Итог

Удалённые репозитории — основа командной работы. Понимание разницы между fetch, pull и push делает совместную разработку предсказуемой.