Lagarbete utan förvirring: förstå grenstrategier i Git

Introduktion

Git har blivit de facto industristandard för versionskontrollsystem inom mjukvaruutveckling. Du bör först läsa min artikel om vad Git är och hur du kommer igång. Har du läst den? Utmärkt, låt oss köra! Gilla det eller inte, det här verktyget skapat av Linus Tovalds kommer inte att gå i pension. Så det är vettigt att prata om hur distribuerade team arbetar med Git och vilken förgreningsstrategi de ska välja för detta. Detta är inte en oviktig fråga. När man sätter ihop ett nytt utvecklingsteam som inte har arbetat tillsammans tidigare är förgreningsstrategin ofta en av de första sakerna att ta ställning till. Och vissa människor kommer att skumma om munnen för att bevisa att en strategi är bättre än en annan. Så jag vill förmedla lite allmän information om dem.

Är förgreningsstrategier nödvändiga?

De är verkligen nödvändiga. Mycket nödvändigt. För om teamet inte kommer överens om något, kommer varje teammedlem att göra vad han eller hon vill:

• arbetar i vilken bransch som helst
• smälter samman till godtyckliga andra grenar
• ta bort vissa grenar
• skapa nya
• och så kommer varje gruppmedlem att agera i ett ohanterat flöde.

Det är därför vi har tre strategier att överväga nedan. Nu går vi!

GitHub Flow

Den här förgreningsstrategin föredras konstigt nog på GitHub :) Den kommer med en uppsättning regler :

1. Koden i mastergrenen får inte brytas. Den ska vara redo att distribueras när som helst. Det vill säga, du får inte lägga kod där som hindrar dig från att bygga projektet och distribuera det till servern.
2. När du planerar att arbeta med ny funktionalitet måste du skapa en ny funktionsgren baserad på huvudgrenen och ge den ett meningsfullt namn. Ange din kod lokalt och skicka regelbundet dina ändringar till samma gren i fjärrförvaret.
3. Öppna en pull-förfrågan (du kan läsa om pull-förfrågningar här ) när du tror att arbetet är klart och kan slås samman i mastergrenen (eller om du är osäker, men vill få feedback på utfört arbete).
4. Efter att den nya funktionen i pull-begäran har godkänts kan den slås samman med mastergrenen.
5. När ändringarna slås samman i huvudgrenen bör de distribueras till servern omedelbart.

Enligt GitHub Flow, innan du börjar arbeta med något nytt, oavsett om det är en fix eller en ny funktion, måste du skapa en ny gren baserad på master och ge den ett passande namn. Därefter påbörjas arbetet med implementeringen. Du bör hela tiden skicka commits till fjärrservern med samma namn. När du drar slutsatsen att allt är klart måste du skapa en pull-förfrågan till mastergrenen. Då bör åtminstone en, eller ännu bättre, två personer titta på den här koden innan de klickar på "Godkänn". Vanligtvis bör projektledaren och en andra person definitivt ta en titt. Sedan kan du slutföra pull-begäran. GitHub Flow är också känt för att driva kontinuerlig leverans (CD) i projekt. Detta beror på att när ändringar går in i huvudgrenen bör de distribueras till servern omedelbart.

GitFlow

Den tidigare strategin (GitHub Flow) är inte särskilt komplicerad i sin kärna. Det finns två typer av grenar: huvud- och funktionsgrenar. Men GitFlow är mer seriöst. Åtminstone borde bilden ovan göra det tydligt :) Så hur fungerar den här strategin? Generellt sett består GitFlow av två ihållande grenar och flera typer av tillfälliga grenar. I sammanhanget av GitHub Flow är mastergrenen beständig och de andra är tillfälliga. Ihållande grenar

• master: Ingen ska röra eller trycka någonting till den här grenen. I denna strategi representerar master den senaste stabila versionen, som används i produktionen (det vill säga på en riktig server)
• utveckling: Utvecklingsgrenen. Det kan vara instabilt.

Utvecklingen sker med hjälp av tre tillfälliga hjälpgrenar :

1. Funktionsgrenar — för att utveckla ny funktionalitet.
2. Släppgrenar — för att förbereda för releasen av en ny version av projektet.
3. Snabbkorrigeringsgrenar – för att snabbt fixa en bugg som hittats av riktiga användare på en riktig server.

Funktionsgrenar

Funktionsgrenar skapas av utvecklare för ny funktionalitet. De ska alltid skapas utifrån utvecklingsgrenen. Efter att ha slutfört arbetet med den nya funktionaliteten måste du skapa en pull-förfrågan till utvecklingsgrenen. Det är klart att stora team kan ha mer än en funktionsgren åt gången. Ta en ny titt på bilden i början av beskrivningen av GitFlow-strategin.

Släpp grenar

När den nödvändiga uppsättningen av nya funktioner är klar i utvecklingsgrenen, kan du förbereda dig för lanseringen av en ny version av produkten. En releasegren, som skapas utifrån utvecklingsgrenen, kommer att hjälpa oss med detta. När du arbetar med releasegrenen måste du hitta och fixa alla buggar. Alla nya ändringar som krävs för att stabilisera releasegrenen måste också slås samman tillbaka till utvecklingsgrenen. Detta görs för att även stabilisera utvecklingsgrenen. När testare säger att grenen är tillräckligt stabil för en ny utgåva, slås den samman till huvudgrenen. Senare skapas en tagg, som tilldelas ett versionsnummer, för denna commit. För att se ett exempel, titta på bilden i början av strategin. Där ser du Tag 1.0— detta är bara en tagg som indikerar version 1.0 av projektet. Och slutligen har vi snabbkorrigeringsfilialen.

Hotfix-grenar

Snabbkorrigeringsgrenar är också avsedda för att släppa en ny version till huvudgrenen. Den enda skillnaden är att dessa releaser inte är planerade. Det finns situationer när buggar kommer in i den släppta versionen och upptäcks i produktionsmiljön. Ta iOS: så fort en ny version släpps får du direkt ett gäng uppdateringar med korrigeringar för buggar som hittats efter releasen. Därför måste vi snabbt fixa en bugg och släppa en ny version. På vår bild motsvarar detta version 1.0.1. Tanken är att arbetet med ny funktionalitet inte behöver upphöra när det är nödvändigt att fixa en bugg på en riktig server (eller som vi säger, "in prod" eller "in production"). Snabbkorrigeringsgrenen bör skapas från huvudgrenen, eftersom den representerar det som för närvarande körs i produktion. Så snart buggfixen är klar, den slås samman till master och en ny tagg skapas. Precis som att förbereda en releasegren, bör en snabbkorrigeringsgren också slå ihop sin fix tillbaka till utvecklingsgrenen.

Forking arbetsflöde

I forking-arbetsflödet involverar utveckling två förråd:

1. Det ursprungliga arkivet, i vilket alla ändringar kommer att slås samman.
2. Ett gaffelförråd. Detta är en kopia av originalförrådet, som ägs av en annan utvecklare som vill göra ändringar i originalet.

Låter lite konstigt än så länge, eller hur? Alla som redan har stött på utveckling med öppen källkod är redan bekant med detta tillvägagångssätt. Denna strategi ger följande fördel: utveckling kan ske i ett gaffelförråd utan att ge tillstånd för gemensam utveckling i den ursprungliga grenen. Naturligtvis har ägaren av det ursprungliga förvaret rätt att avslå de föreslagna ändringarna. Eller att acceptera och slå samman dem. Detta är praktiskt för både originalförvarets ägare och utvecklaren som vill hjälpa till att skapa produkten. Du kan till exempel föreslå ändringar av Linux-kärnan . Om Linus bestämmer sig för att de är vettiga kommer ändringarna att läggas till (!!!).

Ett exempel på gaffelarbetsflödet

Forking-arbetsflödet tillämpas på GitHub när det finns ett bibliotek som du vill använda. Den har en bugg som hindrar dig från att använda den fullt ut. Anta att du dyker tillräckligt djupt in i problemet och vet lösningen. Med hjälp av forking-arbetsflödet kan du åtgärda problemet utan rättigheter att arbeta i bibliotekets ursprungliga arkiv. För att komma igång måste du välja något arkiv, till exempel Spring Framework . Hitta och klicka på knappen "Gaffel" i det övre högra hörnet: Detta kommer att ta lite tid. Sedan kommer en kopia av originalförvaret att dyka upp på ditt personliga konto, vilket indikerar att det är en gaffel:Nu kan du arbeta med det här förrådet som vanligt, lägga till ändringar i huvudgrenen, och när allt är klart kan du skapa en pull-förfrågan till det ursprungliga förvaret. För att göra detta, klicka på knappen Ny pull request :

Vilken strategi att välja

Git är ett flexibelt och kraftfullt verktyg som låter dig arbeta med en mängd olika processer och strategier. Men ju fler val du har, desto svårare är det att bestämma vilken strategi du ska välja. Det är klart att det inte finns något entydigt svar för alla. Allt beror på situationen. Som sagt, det finns flera riktlinjer som kan hjälpa till med detta:

1. Det är bäst att välja den enklaste strategin först. Gå bara till mer komplexa strategier när det behövs.
2. Överväg strategier som har så få filialtyper som möjligt för utvecklare.
3. Titta på för- och nackdelarna med de olika strategierna och välj sedan den du behöver för ditt projekt.

Det var allt jag ville säga om förgreningsstrategier i Git. Tack för din uppmärksamhet :) Följ mig på GitHub , där jag ofta lägger upp mina skapelser som involverar olika teknologier och verktyg som jag använder i mitt arbete.