3.5 Git förgreningar - Fjärrgrenar

När du vill dela grenar med världen, behöver du publicera dem på ett fjärrförvar dit du har skrivrättigheter. Dina lokala grenar synkroniseras inte automatiskt för fjärrservrarna som du skriver till — du måste explicit publicera grenarna som du vill dela. På så vis kan du använda privata grenar för arbete du inte vill dela och bara publicera de ämnesgrenar du vill samarbeta på.

Om du har en gren sopm heter serverfix som du vill arbeta på tillsammans med andra kan du publicera den på samma sätt som du publicerade din första gren. Kör git push <fjärrnamn> <gren>:

Detta är lite av en genväg. Git expanderar automatiskt grennamnet serverfix till refs/heades/serferfix:refs/heads/serverfix, som betyder “Ta min lokala gren serverfix och publicera den genom att uppdatera fjärrförvarets serverfix-gren.” Vi kommer gå igenom refs/heads/-delen i detalj i Git Internals, men i allmänhet kan du strunta i det. Du kan också köra git push origin serverfix:serverfix, som gör samma sak — den säger “Ta min serverfix-gren och gör den till fjärrförvarets serverfix-gren.” Du kan använda detta formatet för att publicera en lokal gren till en fjärrgren som heter något annat. Om du inte vill att den skall kallas serverfix på servern, kan du istället köra git push origin serverfix:grymgren för att publicera din lokala gren serverfix under namnet grymgren på servern.

Nästa gång någon av dina kollegor hämtar från servern, kommer de få en referens till var serverns version av serverfix är under fjärrgrenen origin/serverfix:

Det är viktigt att notera att när du hämtar information som för det med sig nya fjärrspårade grenar så får du inte automatiskt en lokal editerbar kopia av dem. Med andra ord kommer du inte i detta fallet ha en ny serverfix-gren — du har bara en origin/serverfix-pekare som du inte kan modifiera.

För att slå samman detta arbete in i din nuvarande arbetsgren kan du köra git merge origin/serverfix. Om du vill ha din egen serverfix-gren som du kan jobba med, kan du basera den på din fjärrspårade gren:

Detta ger dig en lokal gren som du kan jobba på som pekar dit origin/serverfix pekar.

Att checka ut en lokal gren från ett fjärrspårad gren skapar automatiskt det som kallas för en “följande gren” (och den gren den följer kallas för en “uppströmsgren”). Följande grenar är lokala grenar som har en direkt koppling till en fjärrgren. Om du är på en följande gren och skriver git pull, vet Git automatiskt vilken server den skall hämta data från och vilken gren den skall slå ihop ändringarna i.

När du klonar ett förvar skapas generellt en master-gren som följer origin/master. Du kan dock konfigurera andra följande grenar om du önskar — en som följer grenar i andra fjärrförvar, eller om du inte vill följa master-grenen. Det enkla fallet är exemplet du just såg, att köra git checkout -b <gren> <fjärrnamn>/<gren>. Detta är så vanligt förekommande att Git tillhandahåller kortkommandot --track:

Det är till och med så vanligt att det faktiskt finns en genväg till kortkommandot. Om grenen du försöker checka ut (a) inte existerar och (b) exakt matchar namnet på en gren endast i ett fjärrförvar, kommer Git att skapa en följande gren åt dig:

För att sätta upp en lokal gren med ett annat namn än fjärrgrenen kan du enkelt använda den första versionen med ett annat lokalt grennamn:

Nu kommer din lokala gren sf automatiskt uppdatera från origin/serverfix.

Om du redan har en lokal gren och vill konfigurera mot en fjärrgren du just hämtat hem eller vill byta ut den uppströmsgren du följer, kan du använda flaggan -u eller --set-upstream-to till kommandot git branch för att explicit ställa in denna när som helst.

Om du vill se vilka följande grenar du har inställda, kan du använda flaggan -vv till kommandot git branch. Detta kommer lista dina lokala grenar med mer information, inklusive vad varje gren följer och om din lokala gren ligger före, efter, eller bådadera.

Här kan du se att vår iss53-gren följer origin/iss53 och ligger “före” med två, vilket betyder att vi har två versioner lokalt som inte är publicerade på servern. Vi kan också se att vår master-gren följer origin/master och är uppdaterad. Vi kan även se att vår gren serverfix följer grenen server-fix-good på vår teamone-server och ligger före med tree och efter med en, vilket betyder att det finns en version på servern som vi inte har inkorporerat i vår lokala gren, och tre versioner lokalt som vi inte har publicerat. Slutligen kan vi se att vår gren testing inte följer någon fjärrgren.

Det är viktigt att notera att dessa siffror återspeglar hur det såg ut senast du hämnade information från varje server. Kommandot kontaktar inte servrarna, utan säger dig vad den kommer ihåg från senast du kontaktade dem. Om du vill vara fullständigt säker kring siffrorna, måste du kontakta alla fjärrförvar innan du kör detta. Du kan göra det såhär:

Medan kommandot git fetch hämtar alla ändringar från servern som du ännu inte har, kommer det inte att modifiera din arbetskatalog alls. Den kommer bara hämta data och låter dig slå samman ändringarna själv. Dock finns kommandot git pull som i praktiken är git fetch direkt följt av git merge, i de flesta fall. Om du har en följande gren konfigurerad så som demonstrerades i föregående avsnitt, antingen genom att uttryckligen sätta den eller att den skapades åt dig av kommandona clone eller checkout, kommer git pull kontrollera vilket fjärrförvar och gren din aktuella gren följer, hämta från förvaret och sedan försöka slå samman de inkommande ändringarna med din lokala gren.

Ofta är det bättre att helt enkelt använda kommandona fetch och merge explicit eftersom magin hos git pull ofta kan vara förvirrande.

Anta att du är klar med en fjärrgren — antag att du och dina kollegor är klara med en funktion och har slagit samman ändringarna in i ditt fjärrförvars master-gren (eller vilken gren din stabila kodbas finns i). Du kan ta bort en fjärrgren genom flaggan --delete till git push. Om du vill ta bort din serverfix-gren från servern kör du följande:

Vad detta gör i praktiken är att den tar pekaren från servern. Gitservern kommer generellt att behålla all data ett tag innan det körs en skräpsamlingsomgång, så om den togs bort oavsiktigen, är den ofta lätt att återskapa.