Pusholni — mi ez, hogyan működik a git push és mikor kell

Mi az a push a Gitben

A Git push egy parancs, amely átviszi a commitokat a helyi repozitóriumból a távoliba. Ellentétben a committal, amely csak a fejlesztő helyi gépén menti el a változtatásokat, a push publikálja ezeket a változtatásokat az egész csapat számára. Push kötelező lépés a Pull Request létrehozása és a telepítés előtt.

A Git architektúrája feltételezi, hogy minden fejlesztő a saját helyi repozitóriumában dolgozik. A commitok helyben jönnek létre és halmozódnak fel, amíg a fejlesztő úgy nem dönt, hogy pusholja őket. Ez szabadságot ad: sok helyi commitot lehet készíteni, kísérletezni és átírni a történetet anélkül, hogy befolyásolná a kollégákat.

# Push az origin remote-ba, main ágba
git push origin main

# Aktuális ág pusholása remote-ba upstream-pel
git push -u origin feature/new-dashboard

# Összes ág pusholása egyező nevekkel
git push --all origin

# Force push lease-szel (biztonságos force push)
git push --force-with-lease

A push után a távoli repozitórium frissíti a refs-eket (ágakra mutató hivatkozásokat) úgy, hogy az új commitokra mutassanak. Más fejlesztők ezeket a változtatásokat a git pull vagy git fetch segítségével szerezhetik meg. Éppen ez a commitcsere képezi az együttműködésen alapuló fejlesztés alapját.

Hogyan működik a git push

A git push parancs összehasonlítja a helyi és távoli ágakat, és csak a hiányzó commitokat továbbítja. A Git nem küldi el újra az összes fájlt — csak a deltát továbbítja, ami gyorssá teszi a push-t még nagy repozitóriumok esetén is. Git Protokoll smart transfer-t használ, amely minimalizálja az átvitt adatok mennyiségét.

Ha a távoli ág olyan commitokat tartalmaz, amelyek helyben nem léteznek, a push elutasításra kerül. Ez egy védelmi mechanizmus, amely megakadályozza a változtatások elvesztését. Ilyen helyzetben a fejlesztőnek először git pull-t kell végrehajtania, egyesítenie a változtatásokat, és csak azután pusholnia újra. Alternatíva a force push, amely felülírja a távoli ágat, de óvatosan kell használni.

A távoli repozitóriumok megértése a kulcs a helyes push-hoz. Általában az origin-t használjuk — a távoli repozitórium alapértelmezett nevét. A git remote -v parancs megjeleníti a távoli repozitóriumok listáját és azok URL-jeit. Több remote is hozzáadható (például origin a fő repozitóriumhoz és upstream a fork-hoz).

Mikor kell pusholni a változtatásokat

Az alapszabály: pusholni kell minden logikailag befejezett munkaszakasz után. Ha egy fejlesztő elvégzett egy feladatot vagy annak egy részét — itt az ideje pusholni. Azonban a befejezetlen munka pusholása, amely elrontja a build-et, nem ajánlott. Működő build a minimális követelmény a push-hoz bármely ágba.

A csapatmunkában a következő ritmus elfogadott: reggel — git pull a kollégák változtatásainak lekéréséhez, napközben — néhány commit és egy-két push, este — az összes befejezett feladat végső push-ja. Minél gyakrabban pushol egy fejlesztő, annál kisebb a konfliktusok kockázata az ágak egyesítésekor és annál átláthatóbb a munka előrehaladása.

• A feladat befejezése után — commitolni és pusholni a végső megoldást a feature ágba
• Távozás előtt — pusholni a befejezetlen munkát a feature ágba (nem a main-be!)
• PR létrehozása előtt — meggyőződni, hogy minden commit pusholva van és elérhető a review-hoz
• Rebase után — pusholni --force-with-lease-szel a saját feature ágba

A biztonságos push szabályai

A biztonságos push szabályok összessége, amelyek megakadályozzák az adatvesztést és a konfliktusokat a csapatban. Az első és legfontosabb szabály: soha ne pusholjunk közvetlenül a main vagy master ágba, hacsak a projektben nincs beállítva közvetlen telepítés. Modern csapatokban a main ág védelmét GitHub branch protection szinten konfigurálják.

Második szabály: push előtt szinkronizáljunk a távoli ággal. Hajtsuk végre a git pull --rebase-t, hogy elkerüljük a merge commit-ot az egyesítésnél. Ez leegyszerűsíti a történetet és lineárissá teszi. Ha a push elutasításra kerül — ne használjunk puszta force push-t, hanem először ellenőrizzük, milyen commitok jelentek meg a távoli ágban.

Harmadik szabály: állítsunk be pre-push horgokat, amelyek automatikusan futtatják a teszteket és a linter-t a küldés előtt. Ha a tesztek megbuknak — a push blokkolásra kerül. Az ilyen horgokat a Husky vagy Git hooks (pre-push fájl a .git/hooks-ban) segítségével lehet konfigurálni.

Negyedik szabály: ne pusholjunk nagy bináris fájlokat. A Git nem bináris artefaktumok tárolására készült — felduzzasztják a repozitóriumot és lelassítják a műveleteket. Nagy fájlokhoz Git LFS (Large File Storage) használatos. Ha egy bináris fájl már pusholva van és bekerült a történetbe, a git filter-branch segítségével kell eltávolítani.

Mit tegyünk, ha a push nem sikerült

A sikertelen push leggyakoribb oka — a távoli ág olyan commitokat tartalmaz, amelyek helyben nem léteznek. Ez akkor történik, amikor egy másik fejlesztő pusholta a változtatásait ugyanabba az ágba. Megoldás: hajtsuk végre a git pull-t, oldjuk meg az esetleges konfliktusokat, és ismételjük meg a push-t.

# Push elutasítva — először fetch és rebase
git fetch origin
git rebase origin/main
# Konfliktusok megoldása, majd:
git push --force-with-lease

# Vagy egyszerűen a távoli változtatások egyesítése
git pull origin main
git push

Második ok — írási jogosultság hiánya az ágban. Ha a main ág branch protection szabállyal védett, a közvetlen push-ok tiltottak. Megoldás: pusholjunk feature ágba és hozzunk létre Pull Request-et. A védelmi beállításokat általában a GitHub settings vagy GitLab protected branches segítségével kezelik.

Harmadik ok — hitelesítési problémák. Elavult hitelesítő adatok, SSH-ra váltás vagy personal access token megváltozása. Megoldás: ellenőrizzük a remote URL-t (git remote -v) és frissítsük a hitelesítő adatokat. 2021-től a GitHub megszüntette a jelszóval történő hitelesítést HTTPS-hez — személyes token vagy SSH-kulcs használatos.