5.1 Distribuerat Git - Distribuerade arbetsflöden

I centraliserade system finns i regel en enda samarbetsmodell – det centraliserade arbetsflödet. Ett nav, eller kodförråd, tar emot kod och alla synkroniserar sitt arbete mot det. Utvecklarna är noder och synkroniserar mot den centrala platsen.

Det betyder att om två utvecklare klonar navet och båda gör ändringar kan den första som skickar upp sina ändringar göra det utan problem. Den andra måste sammanfoga den förstas arbete innan hen skickar upp, för att inte skriva över ändringarna. Samma sak gäller i Git som i Subversion (och andra CVCS), och modellen fungerar väl i Git.

Om du redan är bekväm med ett centraliserat arbetsflöde i en organisation eller ett team kan du enkelt fortsätta med det i Git. Sätt bara upp ett enda kodförråd och ge alla rätt att skicka; Git låter inte användare skriva över varandra.

Säg att John och Jessica börjar arbeta samtidigt. John gör klart sina ändringar och skickar upp dem till servern. Sedan försöker Jessica skicka sina, men servern avvisar dem. Hon får veta att hon försöker skicka icke-snabbspolade ändringar och att hon måste uppdatera och sammanfoga först. Detta arbetsflöde tilltalar många eftersom det är välbekant.

Det här är inte begränsat till små team. Med Gits grenmodell kan hundratals utvecklare arbeta parallellt på ett och samma projekt i dussintals grenar.

Eftersom Git tillåter flera fjärrkodförråd kan du ha ett arbetsflöde där varje utvecklare har skrivrättigheter till sitt eget öppna kodförråd och läsbehörighet till andras. I det här scenariot finns det ofta ett huvudkodförråd som representerar det "officiella" projektet. För att bidra skapar du en öppen klon och skickar upp dina ändringar dit. Sedan skickar du en begäran till projektets förvaltare att dra in ändringarna. Förvaltaren kan lägga till ditt kodförråd som fjärrkodförråd, testa ändringarna lokalt, sammanfoga dem i sin gren och skicka till det officiella kodförrådet. Processen ser ut så här (se Integrationsstyrt arbetsflöde):

Det här är ett mycket vanligt arbetsflöde i navbaserade verktyg som GitHub eller GitLab, där det är enkelt att avgrena ett projekt och skicka sina ändringar. En stor fördel är att du kan fortsätta arbeta och att förvaltaren kan dra in dina ändringar när som helst. Bidragslämnaren behöver inte vänta på att projektet integrerar ändringarna – varje part arbetar i sin egen takt.

Det här är en variant av ett arbetsflöde med flera kodförråd. Det används ofta i mycket stora projekt med hundratals medverkande; ett känt exempel är Linuxkärnan. Olika integrationsansvariga ansvarar för olika delar av kodförrådet; de kallas löjtnanter. Alla löjtnanter har en gemensam integrationsansvarig som kallas den välvillige diktatorn. Den välvillige diktatorn skickar upp sin gren till ett referenskodförråd som alla medverkande drar från. Flödet ser ut så här (se Den välvillige diktatorns arbetsflöde):

Det här arbetsflödet är inte vanligt, men kan vara värdefullt 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.

Det här är några vanliga arbetsflöden som är möjliga i ett distribuerat system som Git, men det finns många varianter som kan passa din verklighet. Nu när du kan avgöra vilken kombination som fungerar för dig går vi vidare till mer konkreta exempel på hur du utför de huvudsakliga rollerna i arbetsflödena. I nästa avsnitt får du se några vanliga mönster för att bidra till ett projekt.