Запушить — что это, как работает git push и когда нужно

Что такое пуш в Git

Git push — это команда, которая передаёт коммиты из локального репозитория в удалённый. В отличие от коммита, который сохраняет изменения только на локальной машине разработчика, пуш публикует эти изменения для всей команды. Push — обязательный шаг перед созданием Pull Request и деплоем.

Архитектура Git предполагает, что каждый разработчик работает в своём локальном репозитории. Коммиты создаются локально и накапливаются до тех пор, пока разработчик не решит их запушить. Это даёт свободу: можно делать много локальных коммитов, экспериментировать и переписывать историю без влияния на коллег.

# Push to origin remote, main branch
git push origin main

# Push current branch to remote with upstream
git push -u origin feature/new-dashboard

# Push all branches with matching names
git push --all origin

# Force push with lease (safe force push)
git push --force-with-lease

После пуша удалённый репозиторий обновляет refs (ссылки на ветки) так, чтобы они указывали на новые коммиты. Другие разработчики могут получить эти изменения через git pull или git fetch. Именно этот обмен коммитами составляет основу коллаборативной разработки.

Как работает git push

Команда git push сравнивает локальные и удалённые ветки и передаёт только недостающие коммиты. Git не отправляет все файлы заново — он передаёт только дельту, что делает пуш быстрым даже при больших репозиториях. Protocol Git использует smart transfer, который минимизирует объём передаваемых данных.

Если удалённая ветка содержит коммиты, которых нет локально, пуш будет отклонён. Это защитный механизм, предотвращающий потерю изменений. В такой ситуации разработчик должен сначала выполнить git pull, объединить изменения и только потом повторно запушить. Альтернатива — force push, который перезаписывает удалённую ветку, но использовать его нужно с осторожностью.

Понимание remote репозиториев — ключ к правильному пушу. Обычно используется origin — имя удалённого репозитория по умолчанию. Команда git remote -v показывает список удалённых репозиториев и их URL. Можно добавить несколько remote (например, origin для основного репозитория и upstream для форка).

Когда нужно пушить изменения

Основное правило: пушить нужно после каждого логически завершённого этапа работы. Если разработчик завершил задачу или её часть — пора запушить. Однако пушить незавершённую работу, которая ломает билд, не рекомендуется. Не сломанный билд — минимальное требование для пуша в любую ветку.

В командной разработке принят следующий ритм: утром — git pull чтобы получить изменения коллег, в течение дня — несколько коммитов и один или два пуша, вечером — финальный пуш всех завершённых задач. Чем чаще разработчик пушит, тем меньше риск конфликтов при слиянии веток и тем прозрачнее прогресс работы.

• После завершения задачи — закоммитить и запушить финальное решение в feature-ветку
• Перед уходом — запушить незавершённую работу в feature-ветку (не в main!)
• Перед созданием PR — убедиться, что все коммиты запущены и доступны для ревью
• После rebase — запушить с --force-with-lease в свою feature-ветку

Правила безопасного пуша

Безопасный пуш — это набор правил, предотвращающих потерю данных и конфликты в команде. Первое и главное правило: никогда не пушить напрямую в main или master ветку, если в проекте не настроен прямой деплой. В современных командах защита main-ветки настраивается на уровне GitHub branch protection.

Второе правило: перед пушем синхронизироваться с удалённой веткой. Выполнить git pull --rebase, чтобы избежать merge commit при слиянии. Это упрощает историю и делает её линейной. Если пуш отклонён — не использовать голый force push, а сначала разобраться, какие коммиты появились на удалённой ветке.

Третье правило: настроить pre-push хуки, которые автоматически запускают тесты и линтер перед отправкой. Если тесты падают — пуш блокируется. Такие хуки настраиваются через Husky или Git hooks (pre-push файл в .git/hooks).

Четвёртое правило: не пушить большие бинарные файлы. Git не предназначен для хранения бинарных артефактов — они раздувают репозиторий и замедляют операции. Для больших файлов используют Git LFS (Large File Storage). Если бинарник уже запущен и попал в историю, его нужно удалить через git filter-branch.

Что делать, если пуш не прошёл

Самая частая причина неудачного пуша — удалённая ветка содержит коммиты, которых нет локально. Это случается, когда другой разработчик запушил свои изменения в ту же ветку. Решение: выполнить git pull, разрешить возможные конфликты и повторить пуш.

# Push rejected — fetch and rebase first
git fetch origin
git rebase origin/main
# Resolve conflicts, then:
git push --force-with-lease

# Or simply merge remote changes
git pull origin main
git push

Вторая причина — отсутствие прав на запись в ветку. Если main-ветка защищена branch protection rule, прямые пуши запрещены. Решение: пушить в feature-ветку и создавать Pull Request. Настройки защиты обычно администрируются через GitHub settings или GitLab protected branches.

Третья причина — проблемы с аутентификацией. Устаревшие credentials, переход на SSH или изменение personal access token. Решение: проверить remote URL (git remote -v) и обновить credentials. С 2021 года GitHub отменил аутентификацию по паролю для HTTPS — используется персональный токен или SSH-ключ.