Git
Chapters ▾ 2nd Edition

5.1 Distribuerade Git - Distribuerade arbetsflöden

Nu när du har ett fjärrarkiv för Git inställt som en hub för samtliga utvecklare, och du är bekant med grundläggande Git-kommandon lokalt, ska vi titta på hur man använder några av de distribuerade arbetsflöden som Git erbjuder.

I det här kapitlet kommer du att lära dig att arbeta med Git i en distribuerad miljö, både som bidragslämnare och förvaltare. Du kommer alltså att lära dig hur du framgångsrikt bidar med kod till ett projekt och gör det så enkelt för dig och den som underhåller projektet som möjligt, samt hur du framgångsrikt förvaltar ett projekt med flera utvecklare som bidrar.

Distribuerade arbetsflöden

Till skillnad från centraliserade versionshanteringssystem (CVCS) tillåter Gits distribuerade natur mer flexibilitet när utvecklare ska samarbeta. I centraliserade system är varje utvecklare en nod som arbetar mer eller mindre likvärdigt mot ett nav. I Git däremot, kan varje utvecklare både en nod och ett nav samtidigt; varje utvecklare kan parallellt bidra med kod till andras arkiv och själv underhålla ett öppet arkiv som andra kan bidra till. Det öppnar upp för en mängd olika möjligheter att organisera samarbetet i ditt projekt och/eller i ditt team. Vi kommer att titta närmare på några vanliga processer som drar nytta av den här flexibiliteten. Vi går igenom både styrkor och svagheter för varje arbetsprocess; du kan välja att använda en enda eller blanda och matcha de finesser som verkar passa bäst.

Centraliserad arbetsprocess

Centraliserade system har i stort sett en enda samarbetsmodell — den centraliserade arbetsprocessen. Ett nav, eller arkiv, accepterar kod från utvecklarna, som alla synkroniserar sitt arbete mot det. Utvecklarna är noder till den centrala enheten.

Centraliserad arbetsprocess.
Figur 54. Centraliserad arbetsprocess.

Det innebär att om två utvecklare klonar navet och gör ändringar, så kan den första utvecklaren som skickar upp sina ändringar göra det utan problem. Den andra utvecklaren måste däremot sammanfoga den första utvecklarens arbete innan den skickar upp sina ändringar, annars kommer de nya ändringarna att skrivas över. Det är likadant i Git som i Subversion (eller något annat CVCS), och i Git fungerar modellen utmärkt.

Om du redan är bekväm med en centraliserad arbetsprocess i ditt företag eller team kan du enkelt fortsätta använda den i Git. Det är bara att sätta upp ett enda arkiv och ge alla i teamet skrivbehörighet; Git kommer inte att låta användare skriva över varandras arbeten.

Låt oss säga att John och Jessika båda börjar arbeta samtidigt. John avslutar sina ändringar och skickar upp dem till servern. Sen försöker Jessika att skicka upp sina, men servern avvisar dem. Hon får veta att hon försöker skicka upp ändringar som inte kan snabbspolas, och att hon inte kommer att kunna göra det förrän hon först hämtar och sammanfogar incheckade ändringar. Detta arbetsflöde är tilltalande för många eftersom det är ett tillvägagångssätt många är bekanta och bekväma med.

Det är heller inte begränsat till små team. Gits grenmodell gör det möjligt för hundratals utvecklare att arbeta framgångsrikt på ett enda projekt genom dussintals grenar på en och samma gång.

Integrationsstyrd arbetsprocess

Eftersom Git tillåter dig att ha flera fjärrarkiv är det möjligt att med ett arbetsflöde där varje utvecklare har skrivbehörighet till sitt eget öppna arkiv och läsbehörighet till andras. Detta scenario inkluderar ofta ett arkiv som representerar det “officiella” projektet. För att bidra till det projektet gör du en öppen klon av det som du skickar dina ändringar till. Sen kan du skicka en förfrågan till den som förvaltar det officiella projektet att hämta dina ändringar. Förvaltaren kan då lägga till ditt arkiv som ett fjärrarkiv, testa dina ändringar lokalt, sammanfoga dem i sin gren och skicka till det officiella arkivet. Processen ser ut så här (se Integrationssstyrt arbetsflöde.):

  1. Förvaltaren skickar till sitt öppna arkiv.

  2. En deltagare klonar arkivet och gör ändringar.

  3. Deltagaren skickar sina ändringar till sin egna öppna klon.

  4. Deltagaren skickar ett e-postmeddelande till förvaltaren och ber denne att hämta ändringarna.

  5. Förvaltaren lägger till deltagarens arkiv som ett fjärrarkiv och slår ihop ändringarna lokalt.

  6. Förvaltaren skickar de sammanslagna ändringarna till det officiella arkivet.

Integrationsstyrt arbetsflöde.
Figur 55. Integrationssstyrt arbetsflöde.

Detta är ett mycket vanligt arbetsflöde som används av verktyg som GitHub eller GitLab, där det är enkelt att förgrena ett projekt och skicka upp sina ändringar. En av de största fördelarna med detta tillvägagångssätt är att du kan fortsätta att arbeta vidare, och den som underhåller det officiella arkivet kan hämta in dina ändringar när som helst. Bidragslämnaren behöver inte vänta på att ändringarna ska slås samman innan hen kan börja på något nytt — varje part kan istället arbeta i sin egen takt.

Diktatorns och löjtnanternas arbetsflöde

Diktatorns och löjtnanternas arbetsflöde är en variant av ett flerarkivsarbetsflöde. Det används vanligtvis i stora projekt med hundratals medarbetare; ett känt exempel är Linuxkärnan. Där har integrationsansvariga hand om varsin del av arkivet; de kallas löjtnanter. Löjtnanterna har en gemensam integrationsansvarig som kallas den välvillige diktatorn. Den välvillige diktatorn är den enda med skrivrättigheter till det heliga referensarkiv, som alla medverkande hämtar kod från. Flödet fungerar så här (se Den välvillige diktatorns arbetsflöde.):

  1. Utvecklarna arbetar på sina egna funktionsgrenar och ombaserar sitt arbete till toppen av “master”. “Master”-grenen är det referensarkiv som endast diktatorn skickar ändringar till.

  2. Löjtnanterna slår samman utvecklarnas funktionsgrenar med sina respektive “master”-grenar.

  3. Diktatorn slår samman löjtnanternas “master”-grenar med sin egen “master”-gren.

  4. Slutligen skickar diktatorn sin “master”-gren till referensarkivet, så att de andra utvecklarna kan ombasera från den.

Den välvillige diktatorns arbetsflöde.
Figur 56. Den välvillige diktatorns arbetsflöde.

Det här arbesflödet är inte så vanligt, men kan vara användbart i mycket stora projekt eller hierarkiska miljöer. Det gör det möjligt för projektledaren (diktatorn) att delegera mycket av arbetet och samla stora kodändringsuppsättningar innan de integreras.

Sammanfattning av arbetsflöden

Det här är några av de vanligaste arbetsflödena i distribuerade system, som till exempel Git, men det är möjligt att anpassa dem efter specifika omständigheter i ett projekt. Nu när du (förhoppningsvis) kan avgöra vilken kombination av arbetsflöden som kan fungera för dig, kommer vi att gå igenom några mer specifika exempel på hur du kan utföra de huvudsakliga rollerna som ingår i processerna. I näste avsnitt kommer du att lära dig om några vanliga tillvägagångssätt för att bidra till ett projekt.

scroll-to-top