Запушити — що це, як працює 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 не відправляє всі файли заново — він передає лише дельту, що робить пуш швидким навіть при великих репозиторіях. Протокол 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-ключ.