Pusha — vad är det, hur fungerar git push och när behövs det

Vad är push i Git

Git push är ett kommando som överför commits från det lokala förrådet till fjärrförrådet. Till skillnad från commit, som sparar ändringar endast på utvecklarens lokala maskin, publicerar push dessa ändringar för hela teamet. Push är ett obligatoriskt steg innan man skapar en Pull Request och genomför driftsättning.

Gits arkitektur förutsätter att varje utvecklare arbetar i sitt eget lokala förråd. Commits skapas lokalt och ackumuleras tills utvecklaren bestämmer sig för att pusha dem. Detta ger frihet: man kan göra många lokala commits, experimentera och skriva om historien utan att påverka kollegor.

# Push till origin remote, main-gren
git push origin main

# Pusha aktuell gren till remote med upstream
git push -u origin feature/new-dashboard

# Pusha alla grenar med matchande namn
git push --all origin

# Force push med lease (säker force push)
git push --force-with-lease

Efter pushen uppdaterar fjärrförrådet refs (referenser till grenar) så att de pekar på nya commits. Andra utvecklare kan hämta dessa ändringar via git pull eller git fetch. Det är just detta utbyte av commits som utgör grunden för samarbetsbaserad utveckling.

Hur fungerar git push

Kommandot git push jämför lokala och fjärrgrenar och överför endast de commits som saknas. Git skickar inte alla filer på nytt — det överför endast deltat, vilket gör push snabb även för stora förråd. Git-protokollet använder smart överföring som minimerar mängden överförd data.

Om fjärrgrenen innehåller commits som inte finns lokalt kommer pushen att avvisas. Detta är en skyddsmekanism som förhindrar förlust av ändringar. I en sådan situation bör utvecklaren först utföra git pull, slå samman ändringarna och först därefter pusha igen. Alternativet är force push, som skriver över fjärrgrenen, men bör användas med försiktighet.

Att förstå fjärrförråd är nyckeln till korrekt push. Vanligtvis används origin — standardnamnet för fjärrförrådet. Kommandot git remote -v visar en lista över fjärrförråd och deras URL:er. Man kan lägga till flera remote (t.ex. origin för huvudförrådet och upstream för fork).

När ska man pusha ändringar

Grundregeln: man bör pusha efter varje logiskt avslutad arbetsfas. Om en utvecklare har slutfört en uppgift eller en del av den — är det dags att pusha. Att pusha oavslutat arbete som bryter bygget rekommenderas dock inte. Ett fungerande bygge är minimikravet för att pusha till vilken gren som helst.

I teamutveckling accepteras följande rytm: på morgonen — git pull för att hämta kollegors ändringar, under dagen — några commits och en eller två pushes, på kvällen — slutlig push av alla slutförda uppgifter. Ju oftare en utvecklare pushar, desto mindre är risken för konflikter vid sammanslagning av grenar och desto mer transparent är arbetsframsteget.

• Efter slutförande av uppgift — committa och pusha den slutliga lösningen till feature-grenen
• Före avresa — pusha oavslutat arbete till feature-grenen (inte till main!)
• Före skapande av PR — försäkra dig om att alla commits är pushade och tillgängliga för granskning
• Efter rebase — pusha med --force-with-lease till din egen feature-gren

Regler för säker push

Säker push är en uppsättning regler som förhindrar dataförlust och konflikter i teamet. Den första och viktigaste regeln: pusha aldrig direkt till main- eller master-grenen om inte direkt driftsättning har konfigurerats i projektet. I moderna team konfigureras skyddet av main-grenen på nivån av GitHub branch protection.

Andra regeln: före pushen, synkronisera med fjärrgrenen. Utför git pull --rebase för att undvika en merge-commit vid sammanslagning. Detta förenklar historien och gör den linjär. Om pushen avvisas — använd inte bar force push, utan undersök först vilka commits som har dykt upp i fjärrgrenen.

Tredje regeln: konfigurera pre-push hooks som automatiskt kör tester och linter före sändning. Om testerna misslyckas — blockeras pushen. Sådana hooks konfigureras via Husky eller Git hooks (pre-push-fil i .git/hooks).

Fjärde regeln: pusha inte stora binära filer. Git är inte avsett för lagring av binära artefakter — de sväller förrådet och saktar ner operationer. För stora filer används Git LFS (Large File Storage). Om en binär fil redan har pushats och har kommit in i historien måste den tas bort via git filter-branch.

Vad gör man om pushen misslyckas

Den vanligaste orsaken till en misslyckad push — fjärrgrenen innehåller commits som inte finns lokalt. Detta händer när en annan utvecklare har pushat sina ändringar till samma gren. Lösning: utför git pull, lös eventuella konflikter och upprepa pushen.

# Push avvisad — hämta och rebasa först
git fetch origin
git rebase origin/main
# Lös konflikter, sedan:
git push --force-with-lease

# Eller slå helt enkelt samman fjärrändringar
git pull origin main
git push

Andra orsaken — brist på skrivrättigheter till grenen. Om main-grenen skyddas av en branch protection-regel är direkta pushes förbjudna. Lösning: pusha till feature-grenen och skapa en Pull Request. Skyddsinställningarna administreras vanligtvis via GitHub settings eller GitLab protected branches.

Tredje orsaken — autentiseringsproblem. Föråldrade inloggningsuppgifter, övergång till SSH eller ändring av personal access token. Lösning: kontrollera remote-URL:en (git remote -v) och uppdatera inloggningsuppgifterna. Sedan 2021 har GitHub avskaffat lösenordsautentisering för HTTPS — personlig token eller SSH-nyckel används.