Push-ване — какво е, как работи git push и кога е необходимо

Какво е push в Git

Git push е команда, която прехвърля commits от локалното хранилище към отдалеченото. За разлика от commit, който запазва промените само на локалната машина на разработчика, push публикува тези промени за целия екип. Push е задължителна стъпка преди създаване на Pull Request и внедряване.

Архитектурата на Git предполага, че всеки разработчик работи в свое собствено локално хранилище. Commits се създават локално и се натрупват, докато разработчикът реши да ги push-не. Това дава свобода: можете да правите много локални commits, да експериментирате и да пренаписвате историята без да влияете на колегите.

# Push към origin remote, main клон
git push origin main

# Push на текущия клон към remote с upstream
git push -u origin feature/new-dashboard

# Push на всички клонове с съответстващи имена
git push --all origin

# Force push с lease (безопасен force push)
git push --force-with-lease

След push отдалеченото хранилище актуализира refs (препратки към клонове), така че да сочат към новите commits. Други разработчици могат да получат тези промени чрез git pull или git fetch. Именно този обмен на commits формира основата на съвместната разработка.

Как работи git push

Командата git push сравнява локални и отдалечени клонове и прехвърля само липсващите commits. Git не изпраща всички файлове отново — прехвърля само делта, което прави push бърз дори при големи хранилища. Git протоколът използва smart transfer, който минимизира обема на прехвърляните данни.

Ако отдалеченият клон съдържа commits, които не съществуват локално, push ще бъде отхвърлен. Това е защитен механизъм, предотвратяващ загуба на промени. В такава ситуация разработчикът трябва първо да изпълни git pull, да обедини промените и едва тогава да push-не отново. Алтернатива е force push, който презаписва отдалечения клон, но трябва да се използва внимателно.

Разбирането на отдалечени хранилища е ключът към правилния push. Обикновено се използва origin — името по подразбиране на отдалеченото хранилище. Командата git remote -v показва списък на отдалечените хранилища и техните URL адреси. Могат да се добавят няколко remote (например origin за основното хранилище и upstream за fork).

Кога трябва да push-нете промени

Основното правило: трябва да push-вате след всеки логически завършен етап от работата. Ако разработчикът е завършил задача или част от нея — време е за push. Въпреки това, push-ване на незавършена работа, която чупи build-а, не се препоръчва. Работещ build е минималното изискване за push към който и да е клон.

В екипната разработка се приема следният ритъм: сутрин — git pull за получаване на промените на колегите, през деня — няколко commits и един-два push-а, вечер — финален push на всички завършени задачи. Колкото по-често разработчикът push-ва, толкова по-малък е рискът от конфликти при обединяване на клонове и толкова по-прозрачен е напредъкът на работата.

• След завършване на задача — commit-нете и push-нете крайното решение във feature клон
• Преди да си тръгнете — push-нете незавършената работа във feature клон (не в main!)
• Преди създаване на PR — уверете се, че всички commits са push-нати и достъпни за преглед
• След rebase — push-нете с --force-with-lease в своя feature клон

Правила за безопасен push

Безопасният push е набор от правила, предотвратяващи загуба на данни и конфликти в екипа. Първото и най-важно правило: никога не push-вайте директно в main или master клон, освен ако в проекта не е конфигурирано директно внедряване. В съвременните екипи защитата на main клона се конфигурира на ниво GitHub branch protection.

Второ правило: преди push се синхронизирайте с отдалечения клон. Изпълнете git pull --rebase, за да избегнете merge commit при обединяване. Това опростява историята и я прави линейна. Ако push бъде отхвърлен — не използвайте гол force push, а първо проверете какви commits са се появили в отдалечения клон.

Трето правило: конфигурирайте pre-push куки, които автоматично пускат тестове и linter преди изпращане. Ако тестовете се провалят — push се блокира. Такива куки се конфигурират чрез Husky или Git hooks (файл pre-push в .git/hooks).

Четвърто правило: не push-вайте големи бинарни файлове. Git не е предназначен за съхранение на бинарни артефакти — те надуват хранилището и забавят операциите. За големи файлове се използва Git LFS (Large File Storage). Ако бинарен файл вече е push-нат и е попаднал в историята, трябва да бъде премахнат чрез git filter-branch.

Какво да правите, ако push не успее

Най-честата причина за неуспешен push — отдалеченият клон съдържа commits, които не съществуват локално. Това се случва, когато друг разработчик е push-нал своите промени в същия клон. Решение: изпълнете git pull, разрешете възможните конфликти и повторете push-а.

# Push отхвърлен — първо fetch и rebase
git fetch origin
git rebase origin/main
# Разрешаване на конфликти, след това:
git push --force-with-lease

# Или просто обединяване на отдалечени промени
git pull origin main
git push

Втора причина — липса на права за запис в клона. Ако main клонът е защитен от правило branch protection, директните push-ове са забранени. Решение: push-вайте във feature клон и създайте Pull Request. Настройките за защита обикновено се администрират чрез GitHub settings или GitLab protected branches.

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