Push — шта је то, како ради git push и када је потребан

Шта је push у Git-у

Git push је команда која преноси комитове из локалног репозиторијума у удаљени. За разлику од комита, који чува промене само на локалној машини програмера, push објављује те промене за цео тим. Push је обавезан корак пре креирања Pull Request-а и деплоја.

Архитектура Git-а претпоставља да сваки програмер ради у свом локалном репозиторијуму. Комитови се креирају локално и акумулирају се док програмер не одлучи да их push-ује. То даје слободу: могуће је радити много локалних комитова, експериментисати и преписивати историју без утицаја на колеге.

# 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

Након пуша, удаљени репозиторијум ажурира refs (референце на гране) тако да показују на нове комитове. Други програмери могу добити те промене путем git pull или git fetch. Управо ова размена комитова чини основу колаборативног развоја.

Како ради git push

Команда git push упоређује локалне и удаљене гране и преноси само недостајуће комитове. Git не шаље све фајлове испочетка — преноси само делту, што чини push брзим чак и код великих репозиторијума. Git протокол користи smart transfer, који минимизује количину пренетих података.

Ако удаљена грана садржи комитове којих нема локално, push ће бити одбијен. То је заштитни механизам који спречава губитак промена. У таквој ситуацији програмер треba прво да изврши git pull, споји промене и тек онда поново push-ује. Алтернатива је force push, који преписује удаљену грану, али га треба користити опрезно.

Разумевање удаљених репозиторијума је кључ за правилан push. Обично се користи origin — подразумевано име удаљеног репозиторијума. Команда git remote -v приказује листу удаљених репозиторијума и њихове URL-ове. Могуће је додати више remote-ова (нпр. origin за главни репозиторијум и upstream за форк).

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

Основно правило: push-овати треба након сваке логички завршене фазе рада. Ако је програмер завршио задатак или његов део — време је за push. Међутим, push-овање незавршеног рада који ломи билд се не препоручује. Неполомљен билд је минимални услов за push у било коју грану.

У тимском развоју прихваћен је следећи ритам: ујутру — git pull да би се добиле промене колега, током дана — неколико комитова и један или два пуша, увече — финални push свих завршених задатака. Што чешће програмер push-ује, мањи је ризик од конфликата при спајању грана и прозирнији је напредак рада.

• Након завршетка задатка — комитовати и push-овати коначно решење у feature грану
• Пре одласка — push-овати незавршен рад у feature грану (не у main!)
• Пре креирања PR — уверити се да су сви комитови push-овани и доступни за ревизију
• Након rebase-а — push-овати са --force-with-lease у своју feature грану

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

Сигуран push је скуп правила који спречавају губитак података и конфликте у тиму. Прво и најважније правило: никада не push-овати директно у main или master грану, ако у пројекту није подешен директан деплој. У савременим тимовима заштита main гране се подешава на нивоу GitHub branch protection.

Друго правило: пре пуша синхронизовати се са удаљеном граном. Извршити git pull --rebase да би се избегао merge комит при спајању. То поједностављује историју и чини је линеарном. Ако је push одбијен — не користити голи force push, већ прво проверити који су комитови се појавили на удаљеној грани.

Треће правило: подесити pre-push хукове који аутоматски покрећу тестове и линтер пре слања. Ако тестови падну — push је блокиран. Такви хукови се подешавају кроз Husky или Git hooks (pre-push фајл у .git/hooks).

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

Шта радити ако push није прошао

Најчешћи разлог неуспешног пуша — удаљена грана садржи комитове којих нема локално. То се дешава када је други програмер 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.

Трећи разлог — проблеми са аутентификацијом. Застарели credentials, прелазак на SSH или промена personal access token-а. Решење: проверити remote URL (git remote -v) и ажурирати credentials. Од 2021. GitHub је укинуо аутентификацију лозинком за HTTPS — користи се лични токен или SSH кључ.