En framgångsrik modell för filialer i Git

För att använda Git är viktigt, och det inkluderar att upprätthålla en gemensam utvecklingsmiljö för programvara hanterbara.

Krediter

Detta inlägg är en portugisisk version av originalet, på engelska, “En framgångsrik Git förgrenade modell“, vederbörligen bemyndigade av författaren, Vincent Driessen. Tack mannen!

För tekniska frågor, Några nyckelord har medvetet hållits på engelska. Jag försökte garantera originaliteten i texten, men jag erkänner att jag var tvungen att göra anpassningar för att underlätta förståelsen i vårt språk (SV). Någon korrigering eller förslag till förbättring av översättningen är välkommen.

Introduktion

Detta är inte en tjänst som lär hur man använder Git. Om detta är vad du behöver, Jag föreslår att ta en titt på Git manual. Inte heller är vårt mål att visa hur man gör en programvara versionshantering, i detta fall, Se Semantiska versionshantering.

Förslaget är att hantera gruppsamarbete i programvara versionshantering. Du vet när du har flera programmerare “omrörning” i samma källkod? Det är viktigt att påskynda utvecklingen, men kan generera enorma huvudvärk (fördomar och omarbetningar) Om det finns en kontroll. För att förhindra utvecklare från att skriva över alla andras arbete och garantera en gradvisa utveckling och organiseras, att minimera konflikter och hantera programversioner, är att vi använder Git och modell grenar sedan.

Tom mall

I det här inlägget presenterar jag den utvecklingsmodell som jag använt i några av mina projekt (arbeta som särskilt) om 1 år sedan, och det har varit mycket framgångsrik. Det har varit en lång tid jag ville skriva om det, men jag hittade aldrig ett tillgängligt schema, Hittills. Jag tänker inte prata om projektdetaljer., endast om strategier för grenar och förvaltning av Släpper.

Denna modell fokuserar uteslutande på Git som ett verktyg för att versionsgöra alla våra källkod. (Förresten, om du är intresserad av Git, vårt företag GitPrime, nyår Ger, i realtid, några fantastiska dataanalyser för optimering av programvaruteknik)

Varför git?

För en grundlig diskussion om Git's för-och nackdelar jämfört med centraliserade system källkodkontroll, Se den Web. Det finns en enorm “Krig” runt det. Som utvecklare, Jag föredrar Git jämfört med alla andra verktyg som finns idag. Git har utan tvekan förändrat hur utvecklare tänkte på att göra en Sammanfoga eller skapa en gren. Jag kommer från den klassiska världen av CVS/Subversion, där sammanslagning/förgrening Det är något du bara göra en gång i en stund och alltid ser lite skrämmande (“Akta dig för intressekonflikter Sammanfoga, de bita dig!”).

Med Git dessa åtgärder [sammanslagning/förgrening] är extremt enkel och utgör en av de stora delarna av vårt arbete rutin, tror. Till exempel, i Bok CSV/Subversion, förgrening och samgående omfattas för första gången endast i senare kapitel (för avancerade användare), Tag i någon bok om Git, Detta ses i kapitel 3 (grunderna).

Till följd av din enkelhet och repetitiva karaktär, förgrening och samgående inte längre något att vara rädd. Faktum är, verktyg för versionskontroll bör bidra till att göraSammanfoga och skapa gren Mer än något annat.

Inga fler samtal, Låt oss gå till utvecklingsmodellen. Den modell som jag kommer att presentera här är i grunden inget annat än en uppsättning av bearbetar som varje team-medlem måste följa för att nå en hanterad process mjukvaruutveckling.

Decentraliserad, men centrerad

Konfigurationen av databasen som vi använder och som fungerar mycket bra med denna modell förgrening består av en central lagringsplats. Observera att databasen endast “betraktas som” Centrala (eftersom Git är a DVCS [Distributed Version Control Systems], IE, Det finns inget som en central lagringsplats på teknisk nivå). Vi kommer att referera till denna databas som ursprung, Eftersom detta namn är bekant för alla Git-användare.

Varje utvecklare gör drar och resor för den ursprung. Men bortom förhållandet push-pull för centraliserad [ursprung], varje utvecklare kan också plocka upp [Dra] ändringarna av andra par sätta ihop sub lag. Till exempel, Detta kan vara användbart för att arbeta med två eller fler utvecklare i en ny stor funktionalitet, tidigare skicka [att trycka] pågående arbete för den ursprung. I figuren ovan, Det finns underordnade grupperna med Alice och Bob, Alice och David, och Clair och David.

Tekniskt, Detta betyder ingenting mer än att Alice har definierat en remote Git som heter Bob, peka i slutförvaret av Bob, och vice versa.

Huvudgrenarna

I bakgrunden, Denna modell av utvecklingen är ganska inspirerad av befintliga modeller runt. Den centrala databasen har två grenar [grenar] Major med en oändligt liv:

  • Master
  • utveckla

Den Gren master i ursprung bör känna till varje användare Git. Parallellt med Gren master, Det finns en annan gren kallas utveckla.

Vi anser ursprung/master som den viktigaste grenen där källkoden Huvud återspeglar alltid en stat produktionsklara [redo för produktion].

Vi anser ursprung/utveckla som gren om källkoden för Huvud återspeglar alltid ett tillstånd med de senaste utvecklingsändringarna som ska levereras i nästa version av. Vissa skulle kalla det “gren Integration”. Det är där de mest olycksbådande byggnaderna inträffar.

När källkoden i grenutveckla når en stabil punkt och är redo att släppas fri [Släppt], alla ändringar måste slås samman [Sammanslagna] tillbaka till Gren master och sedan taggade med ett versionsnummer [Release]. Hur detta görs i detalj, kommer att diskuteras senare.

Så, varje gång ändringarna införlivas [Sammanslagna] tillbaka till Master, en ny version genereras [Släppt], per definition. Vi försöker vara ganska strikta i detta, Så, Teoretiskt, vi skulle till och med behöva ett skript Krok att automatiskt skapa och skicka vår applikation till produktionsservrar när det finns en Begå i Master.

Hjälpgrenar

Bredvid grenar Main, Master och utveckla, vår utvecklingsmodell använder en mängd olika grenar stöd för att stödja samtidig utveckling bland gruppmedlemmar, Vad 1) gör det enkelt att spåra nya funktioner [Funktioner], 2) förbereder sig för leverans av en ny version [Release] och 3) hjälper till att snabbt åtgärda produktionsfel [Snabbkorrigeringen]. Olikt grenar Main, Dessa grenar har en kort livslängd, eftersom de så småningom kommer att tas bort.

De olika typerna av grenar [Extra] som vi kan använda, är:

  • Funktionsgrenar
  • Släpp grenar
  • Snabbkorrigeringsgrenar

Var och en av dessa grenar har ett specifikt syfte och är bunden av strikta regler, Så att, grenar kan ge upphov till gren och att grenar bör slås samman [Sammanslagna] till dina mål. Vi får se var och en av dem [grenar] på ett ögonblick.

Ur ett tekniskt perspektiv, Dessa grenar anses inte vara “Särskilda”. Varje typ av gren kategoriseras av hur vi använder dem. Ändå, är bara enkla grenar av den gamla goda Git.

Funktionsgrenar

[Funktioner = funktioner/funktioner]

– Du kan förgrena dig [gren] Från:
utveckla
– Den bör slå samman [Sammanfoga] igen:
utveckla
– konventionen om utnämning av gren:
Något, Utom Master, utveckla, release-*, Eller snabbkorrigering-*

Den funktionsgrenar (eller ibland kallas ämne grenar) används för att utveckla nya funktioner/funktioner för en nära eller framtida version av. När utvecklingen av en Funktionen, målversionen där den här funktionen kommer att införlivas mycket väl kan vara okänd vid den tidpunkten.

Kärnan i en funktionsgrenar är att den existerar medan Funktionen är under utveckling, men så småningom kommer det att införlivas [Sammanslagna] tillbaka till utveckla (att definitivt lägga till den nya Funktionen till nästa Release) eller kasseras (i händelse av en misslyckad upplevelse).

Funktionsgrenar finns vanligtvis bara i databasen utveckla, inte i ursprung.

Skapa en funktionsgren

$ git kassan -b myfeature utveckla
# Switched to a new branch "myfeature"

Införliva ett färdigt inslag i utveckla

Funktioner, nya funktioner kan slås samman[Sammanslagna] med grenutveckla att definitivt lägga till dem till nästa Release.

$ git kassan utveckla
# Bytte till gren "utveckla"
$ git sammanfogning --i-ff myfeature
# Uppdatering ea1b82a.. 05e9557
# (Sammanfattning av ändringar)
# $ git gren -d myfeature
# Borttagen gren myfeature (var 05e9557).
$ git push ursprung utveckla

Flaggan –no-ff orsakar blandning [Sammanfoga] alltid skapa en ny Begå, även om kopplingen kunde utföras med en snabbspola framåt [Ff]. Detta förhindrar information om historien om förekomsten av en funktionsgren, gruppera alla Begår som har lagts till Funktionen. Jämföra:

I det senare fallet [från figuren ovan], det är omöjligt att se från git-historien vilken av de Begår har genomförts inom en Funktionen; du skulle behöva manuellt läsa alla loggmeddelanden. Omvänd en Funktionen Hela (IE, en grupp Begår), det är en riktig huvudvärk i den sista situationen, även om det är lätt gjort om flaggan –no-ff har använts.

Ja, detta kommer att skapa några fler objekt av Begår (Tom), men vinsten är mycket högre än kostnaden.

Släpp grenar

[Release = slutversionen/leverans /]

– Du kan förgrena dig [gren] Från:
utveckla
– Den bör slå samman [Sammanfoga] igen:
utveckla och Master
– konventionen om utnämning av gren:
release-*

Den Releaser grenar bistå vid utarbetandet av en ny produktion release [produktionens frisläppning]. De tillåter dig att dot bindningsikonerna av sista timmen. Ytterligare, De tillåter små buggfixar buggar och definition av Meta-data för en Release (versionsnummer, bygga datum, etc). Att göra allt detta arbete i en släppa gren, den utveckla gren bo ren ta emot Funktioner nästa stora Release [version].

Det viktigaste ögonblicket att skapa en ny släppa gren förgrening av utveckla är när den utveckla är redan (nästan) reflekterande av önskat tillstånd för nya Release [version]. Alla Funktioner kandidater till den Release för att byggas bör införlivas [Sammanfoga] den utveckla i detta ögonblick. Redan den Funktioner inför Släpper framtiden bör förvänta sig ett nästa Release [version].

Är exakt i början av en släppa gren som nästa Release blir ett versionsnummer – inte före. Fram till dess, den utveckla gren återspeglade förändringar till den “nästa utgåva” [nästa version], men det är oklart om detta “nästa version” kommer så småningom att 0.3 eller 1.0, tills den släppa gren startas. Detta beslut görs i början av den släppa gren och utförs av reglerna för projektet på versionshantering [Jag föreslår för att se “Semantiska versionshantering“].

Skapa en release gren

Den Releaser grenar skapas från den utveckla gren. Till exempel, Låt oss säga att versionen 1.1.5 är den nuvarande produktion release och vi har en stor Release kommer. Delstaten utveckla är du redo för den “nästa version” [nästa utgåva] och vi beslutade att detta skulle bli versionen 1.2 (Istället för 1.1.6 eller 2.0). Så, Vi har expanderat och ge släppa gren ett namn som speglar det nya versionsnumret:

$ git kassan -(b) release-1.2 utveckla
# Switched to a new branch "release-1.2"
$ ./bula-version.SH 1.2
# Filer modified framgångsrikt, version som stötte till 1.2.
$ git commit -den -m "Bumped version number to 1.2"
# [Release-1.2 74d 9424] Bumped versionsnummer till 1.2
# 1 ändrade filer, 1 Infogningar(+), 1 Borttagningar(-)

När du har skapat en ny gren och få tillgång till den, vi stötte på versionsnumret. Här, bump-version.sh är ett skalskript som ändrar vissa fungerande kopieringsfiler för att återspegla den nya versionen. (Detta kan, Självklart, vara en manuell ändring – Poängen är att vissa filer ändras.) Så, görs Begå av det ändrade versionsnumret.

Denna nya gren kan finnas där ett tag, tills Release lanseras definitivt. Under denna period, buggfixar kan tillämpas i detta gren (i stället för utveckla gren). Tillägg av nya och stora Funktioner här är strängt förbjudet. De måste slås samman [Sammanslagna] i utveckla och, Gillar det här, vänta på nästa stora Release.

Slutföra en releasegren

När släppa gren är redo att bli en riktig version, vissa åtgärder måste vidtas. Första, den släppa gren slås samman till Master (eftersom varje Begå i Master är en ny version per definition, Kom ihåg). Sedan, Detta Begå i Master bör märkas för att underlätta en framtida hänvisning till denna version s. Slutligen, de ändringar som gjorts i släppa gren måste slås samman [Sammanslagna] igen för att utveckla, Så att Släpper terminer innehåller också dessa buggfixar.

De två första stegen i Git:

$ git kassan mästare
# Växlad till gren "master"
$ git sammanfogning --i-ff release-1.2
# Sammanfogning som görs av rekursiv.
# (Sammanfattning av ändringar)
$ tagg git -den 1.2

Den Release är nu klar och markerad för framtida referens.

Obs: du kan också använda flaggorna -s eller -u att prenumerera på din tagg kryptografiskt.

För att hålla de ändringar som gjorts i släppa gren, vi måste sätta ihop dem igen utveckla. Ingen Git:

$ git kassan utveckla
# Bytte till gren "utveckla"
$ git sammanfogning --i-ff release-1.2
# Sammanfogning som görs av rekursiv.
# (Sammanfattning av ändringar)

Det här steget kan leda till en sammanfogningskonflikt (förmodligen gå, när vi ändrar versionsnumret). Om så är fallet, fixa och göra Begå.

Nu, att vi verkligen bröt upp, den släppa gren kan tas bort, eftersom vi inte behöver det längre:

$ git gren -d release-1.2
# Borttagen gren release-1.2 (var ff452fe).

Snabbkorrigeringsgrenar

– Du kan förgrena dig [gren] Från:
Master
– Den bör slå samman [Sammanfoga] igen:
utveckla och Master
– konventionen om utnämning av gren:
snabbkorrigering-*

Den Snabbkorrigeringsgrenar är mycket lik den frigöra grenar, eftersom de också är avsedda att förbereda en ny produktionsversion, även om oplanerade. De uppstår från behovet av att agera omedelbart efter ett oönskat tillstånd av en produktionsversion [som används]. När ett kritiskt fel uppstår i en produktionsversion, bör lösas omedelbart, då en hotfix-gren kan härledas från taggen som markerar den befintliga produktionsversionen i huvudgren.

Kärnan är att teamets medlemmars arbete (i utveckla gren) kan fortsätta, medan någon annan förbereder en snabb lösning på produktionsfelet.

Skapa snabbkorrigeringsgrenen

Den snabbkorrigeringsgrenar skapas från den huvudgren. Till exempel, förutsatt att den version som 1.2 är den aktuella versionen av produktionsversionen igång och ger problem på grund av ett allvarligt fel. Förändringar i utveckla lämna den fortfarande instabila. Vi kan sedan förgrena oss en hotfix-gren och börja lösa problemet:

$ git kassan -b snabbkorrigering-1.2.1 Master
# Switched to a new branch "hotfix-1.2.1"
$ ./bula-version.SH 1.2.1
# Filer modified framgångsrikt, version som stötte till 1.2.1.
$ git commit -den -m "Bumped version number to 1.2.1"
# [snabbkorrigering-1.2.1 41e61bb] Bumped versionsnummer till 1.2.1
# 1 ändrade filer, 1 Infogningar(+), 1 Borttagningar(-)

Glöm inte att ändra versionsnumret efter filialen!

Sedan, korrigera felet och göra Begå korrigering i en eller flera Begå Separat.

$ git commit -m "Fixed severe production problem"
# [snabbkorrigering-1.2.1 abbe5d6] Fast allvarligt produktionsproblem
# 5 ändrade filer, 32 Infogningar(+), 17 Borttagningar(-)

Efterbehandling av en snabbkorrigeringsgren

När du är klar, den Bugfix måste slås samman igen till Master, men det måste också införlivas igen för att utveckla, för att säkerställa att Bugfix ingår också i nästa version. Detta är ganska likt hur frigöra grenar är färdiga.

Första, uppdatera Master och tagga Release [markera sommaren]:

$ git kassan mästare
# Växlad till gren "master"
$ git sammanfogning --i-hotfix ff-1.2.1
# Sammanfogning som görs av rekursiv.
# (Sammanfattning av ändringar)
$ tagg git -den 1.2.1

Obs: du kan också använda flaggorna -s eller -u att prenumerera på din tagg kryptografiskt.

Sedan, inkluderar Bugfix i utveckla Också:

$ git kassan utveckla
# Bytte till gren "utveckla"
$ git sammanfogning --i-hotfix ff-1.2.1
# Sammanfogning som görs av rekursiv.
# (Sammanfattning av ändringar)

Det enda undantaget från regeln här är att, när det finns en släppa gren pågår, förändringarna i Snabbkorrigeringen måste slås samman för detta släppa gren, Stället utveckla. Slå samman Bugfix i släppa gren kommer att orsaka Bugfix slås samman till utveckla Också, när släppa gren är klar. (Om arbetet i utveckla kräver omedelbart detta Bugfix och kan inte vänta tills släppa gren är klar, kan du säkert slå samman Bugfix för deveolp (deveolp) Också.)

Slutligen, ta bort gren Tillfälliga:

$ git gren -snabbkorrigering d-1.2.1
# Borttagen snabbkorrigering för gren-1.2.1 (var abbe5d6).

Sammanfattning

Även om det inte finns något verkligt extraordinärt i denna förgrening modell, siffran i början av Posten kan vara till stor hjälp i våra projekt. Det visar en lättförståelig mental modell och gör det möjligt för gruppmedlemmar att utveckla en gemensam förståelse av förgrening och Släppa.

En högkvalitativ PDF-version av figuren finns på bloggen av det ursprungliga inlägget: http://nvie.com/posts/a-successful-git-branching-model/ [eller på länken Ladda ner nedan]. Gå vidare och sätta det på väggen för en snabb hänvisning till helst.

Totalt antal träffar: 8355

En kommentar om “En framgångsrik modell för filialer i Git

  1. Deivson Födelse sade:

    God eftermiddag, vet att Git ursprungligen utvecklades av Linux-systemet, men när man talar om bärbarhet, Jag undrar om git körs på Windows MSIS och POSIX??

Lämna svar

I din e-postadress kommer inte att publiceras. Obligatoriska fält är markerade med *