5.2 Distribuerade Git - Medverka i ett projekt

Innan vi går in på användarfallen kommer en kort kommentar om incheckningsmeddelanden. Att ha bra riktlinjer för incheckningar, och att hålla sig till dem, gör det betydligt enklare att använda Git tillsammans med andra. I Git-projektet finns ett dokument med flera bra tips på saker att tänka på för att göra incheckningar till en patch. Du hittar det i filen Documentation/SubmittingPatches i Gits källkod.

Först av allt, så bör dina bidrag inte ha några felaktiga mellanslag. Git har ett lätt sätt att kontrollera det — innan du gör en incheckning, kör kommandot git diff --check. Det ger dig en lista över möjliga mellanslag som kan vara felaktiga.

Kör kommandot innan en incheckning för att snabbt kontrollera om du är på väg att checka in mellanslag som kan irritera andra utvecklare.

För det andra, försök att göra varje incheckning till logiskt separat enhet. Om du kan, försök att hålla dina ändringar lättsmälta - koda inte en hel helg på fem olika uppgifter, för att sen skicka dem som en enda gigantisk incheckning på måndan. Även om du inte har checkat in på en hel helg, använd köområdet för att dela upp ditt arbete i minst fem incheckningar på måndagen, med ett tydligt meddelande per incheckning. Om några av ändringarna är i samma fil, försök att använda git add --patch för att delvis köa filer (läs mer i Interactive Staging). Projektets ögonblicksbild längst ut på grenen kommer att se likadan ut oavsett om du gör en incheckning eller fem, så länge som alla ändringar läggs till förr eller senare. Försök därför att göra det så enkelt som möjligt för dina kollegor när de ska granska dina ändringar.

Med det tillvägagångssättet blir det också enklare att dra ut eller återställa någon av ändringarna i efterhand, om det skulle behövas. I avsnittet Rewriting History finns en mängd användbara tips för att skriva om Git-historiken och interaktivt köa filer — använd dessa verktyg för att få en logisk och förståelig historik innan du skickar arbetet vidare till någon annan.

Slutligen behövs en struktur för incheckningsmeddelandet. Med vanan att alltid skriva bra meddelanden blir användningen av - och samarbetet i - Git betydligt enklare. Tumregeln är att dina meddelanden ska börja med en mening på max 50 tecken som sammanfattar ändringen, följt av en blank rad och en mer detaljerad beskrivning. Git-projektet gör gällande att beskrivningen bör inkludera anledningen till ändringen och en jämförelse med tidigare beteende — det är en bra riktlinje att följa. Det är också bra att skriva i imperativ form. Med andra ord, ge order. Istället för “Jag lade till test för” eller “Lägger till test för,” skriv “Lägg till test för” Här är en mall ursprungligen skriven av Tim Pope:

Om alla dina incheckningsmeddelande följer den här mallen kommer det att bli lättare, både för dig och dem du samarbetar med. Git-projektet har välformatterade incheckningsmeddelanden — kör git log --no-merges där för att få inspiration till hur en väl formatterad incheckningshistorik kan se ut.

Det enklaste arbetssättet du sannolikt kommer stöta på är ett privat projekt med en eller två involverade utvecklare. I den här kontexten betyder “privat” sluten källkod — den är inte tillgänglig för någon utomstående. Du och de andra utvecklarna har skrivbehörigheter till arkivet.

I den här uppsättningen liknar arbetssättet det som du kanske stöter på när du använder Subversion eller något annat centraliserat versionshanteringssystem. Du behåller fördelarna med saker som att kunna checka in offline, en betydligt enklare förgrening och sammanslagning, men arbetsprocesserna är mycket lika; den största skillnaden är att sammanslagningar sker i klienten istället för från servern vid incheckning. Låt oss ta ett exempel på hur det kan gå till när två utvecklare börjar samarbeta i ett gemensamt arkiv. Den första utvecklaren, John, klonar arkivet och gör en ändring som checkas in lokalt. (Informationsmeddelandena har ersatts med ... för att korta ner exemplen.)

Jessika, den andra utvecklaren, gör samma sak — klonar arkivet och checkar in en ändring:

Sen skickar Jessika sina ändringar till servern, vilket funkar bra:

Den sista raden i outputen är ett användbart meddelande från sändningen. Formateringen är <gammalref>..<nyref> frånref -> tillref, där gammalref betyder tidigare referens, nyref är den nya referensen, frånref är namnet på den lokala referens som ändringen kommer från och tillref är fjärreferensen som har blivit uppdaterad. Du kommer att se liknande output i exemplen nedanför, en grundförståelse kommer göra det lättare att förstå innebörden av arkivens varierade stadier. Mer detaljer finns i git-push dokumentation.

För att fortsätta med det här exemeplet — kort efteråt gör John några ändringar, checkar in dem lokalt och försöker skicka dem till samma server som Jessika:

I det här fallet kan John inte skicka sina incheckningar på grund av Jessikas tidigare incheckning av sina ändringar. Det här är särskilt viktigt att förstå om du tidigare har använt Subversion, för du kommer att märka att de två utvecklarna inte ändrade i samma fil. Subversion gör en sammanslagning automatiskt på servern om olika filer har ändrats, men med Git behöver du själv först sammanfoga incheckningarna lokalt. Med andra ord, John måste först hämta Jessikas ändringar i fjärrarkivet och sammanfoga dem i sitt lokala arkiv innan han kommer att få tillåtelse att skicka ändringarna.

Som ett första steg hämtar John Jessikas ändringar(Jessikas ändringar hämtas bara, de slås inte ihop med hans filer):

Johns arkiv ser nu ut ungefär så här:

Nu kan John slå ihop de ändringar han hämtade av Jessika med filerna på sin dator:

Om den lokala sammanslagningen går smidigt kommer Johns uppdaterade historik se ut ungefär så här:

Nu kanske John vill testa den nya koden för att vara helt säker på att ingen av Jessikas ändringar påverkat hans, och om allt går bra kan han slutligen skicka sina sammanslagna ändringar till servern:

Till sist ser Johns incheckningshistorik ut så här:

Under tiden har Jessika skapat en ny gren med namnet issue54, och gjort tre incheckningar till den nya grenen. Hon har inte hämtat Johns ändringar än, så hennes incheckningshistorik ser ut så här:

Plötsligt får Jessika veta att John har skickat nya ändringar till servern och vill kika på dem, så hon hämtar alla ändringar från servern med kommandot:

Nu hämtas Johns incheckade ändringar ner. Jessikas historik kommer att se ut så här:

Jessika tycker att ändringarna på hennes nya gren är klara, men hon vill veta vilka delar av Johns arbete som hon måste slå ihop med sitt arbete så att hon kan skicka dem. Hon kör git log för att få reda på det:

Syntaxen issue54..origin/master används för att filtrera loggar. Git ombeds att bara visa de incheckningar i den senare referensen (origin/master i det här fallet) som inte finns på den första referensen (här issue54). Vi kommer att gå igenom syntaxen i detalj i avsnitt Commit Ranges.

Från ovanstående output kan vi utläsa att det bara är en enda av Johns incheckningar som Jessika inte har slagit ihop med sitt arbete lokalt. Om hon slår ihop sina ändringar med ändringarna på origin/master är det bara den incheckningen som kommer att påverka hennes lokala arkiv.

Nu kan Jessika slå ihop sin lokala funktionsgren med sin huvudgren, slå samman Johns ändringar (origin/master) med sin master gren och sen skicka sitt arbete till servern igen. .

När alla ändringar på grenen issue54 har checkats in, börjar Jessika med att byta tillbaka till sin huvudgren:

Jessika kan slå ihop antingen origin/master eller issue54 först — de är båda uppströms, så ordningen spelar ingen roll. Den slutliga ögonblicksbilden blir identisk oavsett vilken ordning hon väljer, det är bara historiken som kommer att skilja sig åt. Hon bestämmer sig för att slå ihop grenen issue54 först:

Inget oväntat händer, som du kan se var det en sammanslagning som kunde snabbspolas framåt. Jessika kan nu avsluta sammanslagningarna lokalt genom att slå ihop de ändringar hon hämtade tidigare från John och som är väntar kvar på origin/master:

Allt slogs ihop smidigt, Jessikas historik ser nu ut så här:

Fjärreferensen origin/master kan nås från Jessikas huvudgren, så hon borde kunna skicka sina ändringar utan problem (förutsatt att John inte har skickat fler ändringar under tiden):

Båda utvecklarna har nu checkat in sina versioner av filerna några gånger och fått in varandras ändringar i sina lokala kodbaser.

Det här är en av de enklaste arbetsprocesserna.

Du arbetar ett tag (vanligtvis i en funktionsgren), och slår ihop arbetet i huvudgrenen när det är klart. När du vill dela ditt arbete, hämtar du och slår ihop din huvudgren med origin/master och skickar tillbaka din huvudgren till servern. Den generella arbetsprocessen ser ut ungefär så här:

Nästa exempel är medverkan i ett större, privat team. Här tittar vi närmre på hur arbetsprocessen kan se ut när mindre team samarbetar på features, som därefter slås ihop av andra team.

Säg att John och Jessika arbetar tillsammans på en funktion (vi kallar den “featureA”). Samtidigt samarbetar Jessika och en tredje utecklare, Josie, på en annan, (“featureB”). I det här fallet använder sig företaget av en slags integrationsstyrt arbetsprocess, där arbetet av ett enskilt team slås samman med huvudgrenen av specifika ingengörer. Arkivets huvudgren kan endast uppdateras av dessa. Allt arbete sker på förgreningar som sedan slås ihop av andra i ett senare skede.

Vi följer med Jessika medan hon arbetar på sina features parallellt, med två olika utvecklare, i en sådan här miljö. Vi utgår ifrån att hon redan har klonat arkivet, när hon bestämmer sig för att börja med featureA. Hon skapar en ny gren för funktionen och jobbar lite på den:

I det här läget behöver hon dela sitt jobb med John, så hon skickar sin featureA-gren med incheckningarna till servern. Jessika har inte behörighet att slå ihop sina ändringar med huvuudgrenen, så hon behöver skicka dem till en annan gren för att kunna samarbeta med John:

Jessika mejlar John för att berätta att hon har skickat ändringar till en gren med namnet featureA och att han kan kolla på dem nu. Medan hon väntar på feedback från John bestämmer hon sig för att börja jobba på featureB tillsammans med Josie. Hon börjar med att skapa en ny gren från serverns huvudgren:

Nu gör Jessika ett par inckeckningar på `featureB`grenen:

`[source,console]

Jessikas arkiv ser nu ut så här:

Hon är redo att skicka sina ändringar när hon får ett mejl från Josie som skriver att en gren hon har börjat på för featureB redan har skickats till servern som grenen featureBee. Jessika behöver slå ihop de ändringarna med sina innan hon kan skicka sitt arbete till den gren Josie skickat till servern. Jessika hämtar först Josies ändringar med git fetch:

Om vi antar att Jessika fortfarande är utcheckad på grenen featureB, så kan hon nu slå Josies arbete med den grenen med kommandot git merge:

I det här läget vill Jessika skicka allt som finns på featureB tillbaka till servern, men utan att skicka upp sin egna gren. Eftersom Josie redan har påbörjat en uppströms featureBee-gren så vill Jessika skicka till den grenen. Det gör hon med:

Detta kallas för en referensspecifikation. Se The Refspec för mer information om Gits referensspecifikationer och hur du kan använda dem. Lägg också märke till -u-flaggan; det är en kortversion av kommandot --set-upstream, som sparar en referens till den fjärrgren som din lokala gren spårar.

Plötsligt får Jessika ett mail från John, som berättar att han har skickat några ändringar till featureA-grenen och ber henne kolla på dem. Återigen kör Jessika ett enkelt git fetch för att hämta allt nytt innehåll från servern, inklusive Johns senaste arbete:

Jessika kan nu läsa loggarna med Johns senaste ändringar genom att jämföra innehållet som hämtades för featureA med den lokala kopian av samma gren:

Om Jessika gillar det hon ser kan hon fusionera Johns nya arbete till sin lokala featureA gren med:

Till sist kanske Jessika vill göra några mindre ändringar i det sammanslagna innehållet. Hon har full frihet att göra sina ändringar, checka in dem till sin lokala gren featureA och skicka tillbaka slutresultatet till servern.

Jessikas incheckningshistorik kommer nu att se ut ungefär så här:

Vid någon tidpunkt kommer Jessika, John och Josie att behöva informera dem som ansvarar för huvudgrenen att featureA och featureB är redo att slås ihop med den. När sammanslagningen med huvudgrenen då är klar, kommer en hämtning av den att få med den nya versionsincheckningen. Historiken kommer då att se ut så här:

Många byter till Git på grund av möjligheten för flera team att arbeta parallellt och kombinera sina förgreningar sent i processen. Möjligheten att mindre grupperingar inom ett team kan samarbeta via fjärrgrenar utan att nödvändigtvis behöva involvera hela teamet är utan tvekan en av Gits stora fördelar. Arbetsprocessen som precis har beskrivts ser ut ungefär såhär:

Att bidra till öppna projekt är ofta lite annorlunda än privata. Eftersom du vanligtvis inte har behörighet att göra ändringar direkt i projektet behöver förvaltarna få ditt arbete på något annat sätt. I det första exemplet ska vi titta på hur man förgrenar ett arkiv på de hostingsajter för Git som tillåter det. Många hostingsajter har stöd för förgreningar, (såsom GitHub, BitBucket, repo.or.cz med flera) och många projektansvariga förväntar sig att andra medverkar på det sättet. Det andra exemplet beskriver arbetsprocessen i de projekt som istället föredrar att acceptera patchade bidrag via mejl.

Det första du behöver göra är troligen att klona grundarkivet och skapa en funktionsgren för patcherna du planerar att bidra med Flödet ser helt enkelt ut så här:

När arbetet är klart och du är redo att dela det med förvaltarnas, gå till ursprungsarkivets projektsida och klicka på knappen ``Fork`` för att skapa en kopia av projektet som du har full behörighet till. Därefter lägger du till det nya repots URL som ett nytt fjärrarkiv för ditt lokala arkiv; i det här exemplet kan vi kalla det för mingaffel:

Sedan behöver du skicka ditt arbete till det här arkivet. Det är enklare att skicka den finessgren du arbetar på till ditt kopierade arkiv än att fusionera det arbetet i din huvudgren och fusionera den. Om ditt arbete inte bli godkänt, eller om din incheckning inte blir cherry-pickad, så slipper du spola tillbaka din huvudgren (läs mer om Gits cherry-pick i Arbetsflöden med ombasering och plocka russin ur kakan). Om de ansvariga å andra sidan slår ihop, ombaserar eller cherry-pickar din funktion, så kommer du att få tillbaka den genom att dra ner ändringar från deras repo ändå. Hur du än gör kan du skicka ditt arbete med:

När ditt arbete har skickats till din förgrening av arkivet behöver du meddela förvaltarna av originalprojektet att du har arbete som du skulle vilja att de slår samman. Detta kallas ofta för en pull request och du behöver vanligtvis göra en sådan begäran antingen via websida — GitHub har sin egen ``Pull Request``-mekanism som vi kommer att gå igenom i GitHub — eller så kan du köra kommandot git request-pull och mejla den efterföljande utdatan till de ansvariga.

Kommandot git request-pull tar basgrenenen, det vill säga den gren du vill att din funktionsgren dras in i, och Git-arkivets URL som du vill att de accepterar kod ifrån, och sammanfattar alla ändringar du begär ska tas in. Om Jessika till exempel vill skicka en pull request till John, och hon har gjort två incheckningar på funktionsgrenen som hon just har skickat, så kan hon använda det så här:

Den här utdatan kan skickas till de ansvariga — den beskriver från vilken gren arbetet förgrenades, ger en sammanfattning av incheckningarna och varifrån den nya funktionen kan hämtas.

I ett projekt där du inte är ansvarig är det oftast enklast att ha en huvudgren, t.ex master, som alltid följer origin/master och sen arbeta i funktionsgrenar som du enkelt kan radera om de inte godkänns. Att isolera funktioner tll funktionsgrenar gör det också lättare för dig att flytta ditt arbete om änden på huvudarkivet har rört sig under tiden du arbetat så att din version inte längre kan sammanfogas på ett smidigt sätt. Om du till exempel vill skicka in en andra funktionsgren till projektet, fortsätt inte att arbeta på den funktionsgren du nyss skickade upp — börja istället om från arkivets huvudgren:

Now, each of your topics is contained within a silo — similar to a patch queue — that you can rewrite, rebase, and modify without the topics interfering or interdepending on each other, like so: Nu är båda dina funktioner i varsitt silo — som en kö för patchar — som du kan skriva om, ombasera och ändra utan att funktionerna påverkar eller blir beroende av varandra:

Om vi säger att projektets ansvariga har dragit in ett gäng andra patches innan de testar din första gren, så kan den inte sammanfogas automatiskt. I det här fallet kan du försöka att ombasera den grenen så att den hamnar längst ut på toppen av origin/master, lösa eventuella konflikter och skicka in din version igen:

Det här skriver om historiken enligt bilden nedan Versionshistorik efter avslutat arbete med featureA..

Eftersom du flyttade grenen behöver du ange -f till ditt kommando för att kunna ersätta serverns featureA-gren med en annan incheckning än den ursprungliga. Ett alternativ vore att skicka det här nya arbetet till en annnan gren på servern (som kanske kan heta featureAv2),

Vi tittar närmre på ytterligare ett alternativ: ansvariga har tittat ändringarna i din andra gren och gillar dem mestadels, men de skulle vilja att du gjorde en justering. Du använder möjligheten att flytta förgreningen från featureA till huvudgrenen.

Du kan göra det här genom att skapa en ny gren från origin/master, sammanfoga featureB där, lösa eventuella konflikter, göra ändringen och skicka det som en ny gren:

Flaggan --squash komprimerar alla incheckningar på grenen som ska slås ihop till en enda versionsändring, vilket ger samma status i arkivet som vid en sammanslagning. Det innnebär att dina framtida incheckningar bara kommer att ha en förälder och ger dig möjlighet att dra in alla ändringar från en annan gren och göra fler ändringar innan den nya incheckningen kommer på pränt. Ibland kan det vara användarbart att använda flaggan --no-commit för att fördröja en ny incheckning vid en sammanslagning istället för som i den ordinarie sammanslagningsprocessen. I det här läget kan du meddela ansvarig att du har gjort de begärda ändringarna och att de kan hitta dessa i din featureBv2.

Många projekt har sina rutiner för att acceptera patchar — du behöver kolla upp de specifika reglerna för varje projekt, eftersom de kommer att skilja sig åt. Eftersom det finns flera äldre, större projekt som endast accepterar patchar via en mejllista för utvecklare, så kommer vi att gå igenom ett exempel på hur det går till.

Arbetsprocessen liknar den i föregående exemplet — du skapar finessgrenar som du arbetar på. Den stora skillnaden är att du inte kan skicka dina inceckningar till fjärrarkivet. Istället behöver du mejla varje commit till en mejllista för utvecklare.

Nu har du två incheckningar som du vill skicka till mejllistan. För att generera mbox-formatterade filer som du kan mejla till listan, använder du git format-patch — det gör om varje incheckning till ett mejl med den första raden i incheckningsmeddelandet som ämne och resten av meddelandet plus patchen som innehåll. Det fina med det här är att när en patch från ett mejl genererat med format-patch appliceras, så bevaras incheckningsinformationen korrekt.

format-patch-kommandot skriver ut namnen på de patchfiler som skapas. Flaggan -M talar om för Git att leta efter omdöpta filer. Filerna kommer att se ut så här:

Du kan också redigera patchfilerna för att lägga till mer information till mejllistan som du inte vill ska visas i incheckningsmeddelandet. Om du lägger till text mellan raden --- och början av patchen (inleds med raden diff --git), så kan utvecklarna läsa meddelandet, men det ignoreras i patchningsprocessen. Det är en bra plats att lägga till information om varför du gjorde ändringarna, eller om du har några speciella instruktioner för att testa dem.

För att skicka patchfilen till mejllistan kan du antingen klistra in innehållet i ditt mejlprogram eller skicka det via kommandoraden. Att klistra in texten orsakar ofta formatteringsproblem, speciellt med “smartare” klienter som inte bevarar radbrytningar och mellanslag korrekt. Som tur är har Git ett verktyg som hjälper dig att skicka korrekt formatterade patchar via IMAP, vilket gör det enklare. Vi kommer att visa hur du skickar en patch via Gmail, som råkar vara den e-postklient vi känner till bäst. Du kan läsa detaljerade instruktioner för en mängd e-postklienter i slutet av filen Documentation/SubmittingPatches i Gits källkod.

Först behöver du sätta upp IMAP-sektionen i din ~/.gitconfig-fil. Du kan sätta varje värde separat med en serie git config-kommandon, eller lägga till dem manuellt. I slutänden ska din konfigurationsfil se ut något så här:

Om din IMAP-server inte använder SSL så är de två sista raderna nog inte nödvändiga, och värdet för host kommer då att vara imap:// istället för imaps://. När det är inställt kan du använda git imap-send för att placera patchserien i mappen Drafts på den angivna IMAP-servern:

Nu borde du kunna gå till din Drafts-mapp, ändra To-fältet till mejllistan du ska skicka patchen till, eventuellt lägga till cc:a till den person som är ansvarig, och skicka iväg det.

Du kan också skicka patcharna via en SMTP-server. Precis som tidigare kan du sätta varje värde separat med en serie git config-kommandon, eller lägga till dem manuellt i ~/.gitconfig-filen:

När det är inställt kan du använda git send-email för att skicka patcharna:

Git kommer att ställa en rad frågor om hur du vill att e-posten ska se ut för varje skickad patch. De kommer att se ut ungefär så här:

I den här delen har vi gått igenom en mängd olika arbetsflöden för olika slags Git-projekt som du troligen kommer att stöta på, samt introducerat ett par nya verktyg för att hjälpa dig att hantera processerna. I nästa del kommer du att få lära dig hur du hanterar den andra sidan av myntet: att underhålla ett Git-projekt. Du får lära dig att vara en välvillig diktator eller integrationsansvarig.