3.4 Git Branching - Vertakkingswerkvloeie (Branching Workflows)

Omdat Git 'n eenvoudige drierigting-saamsmelting (three-way merge) gebruik, is dit oor die algemeen maklik om veelvuldige kere oor 'n lang tydperk van een tak na 'n ander te smelt (merge). Dit beteken jy kan verskeie takke hê wat altyd oop is en wat jy vir verskillende fases van jou ontwikkelingsiklus gebruik; jy kan gereeld van sommige van hulle na ander smelt.

Baie Git-ontwikkelaars het 'n werkvloei wat hierdie benadering omhels, soos om byvoorbeeld slegs kode wat heeltemal stabiel is in hul master tak te hê — moontlik net kode wat reeds vrygestel (released) is of sal word. Hulle het nog 'n parallelle tak genaamd develop of next waaruit hulle werk of wat hulle gebruik om stabiliteit te toets — dit is nie noodwendig altyd stabiel nie, maar wanneer dit in 'n stabiele toestand kom, kan dit by master saamgesmelt word. Dit word gebruik om onderwerp-takke (topic branches - kortlewende takke, soos jou vroeëre iss53 tak) in te trek (pull in) wanneer hulle gereed is, om seker te maak hulle slaag al die toetse en stel nie foute (bugs) in nie.

In werklikheid praat ons van wysers (pointers) wat op en af beweeg op die lyn van vasleggings (commits) wat jy besig is om te maak. Die stabiele takke is verder af in die lyn van jou vasleggingsgeskiedenis, en die heel nuutste (bleeding-edge) takke is verder op in die geskiedenis.

Dit is oor die algemeen makliker om aan hulle te dink as werksilo’s, waar stelle vasleggings (commits) gradueer na 'n meer stabiele silo wanneer hulle ten volle getoets is.

Jy kan aanhou om dit te doen vir verskeie vlakke van stabiliteit. Sommige groter projekte het ook 'n proposed of pu (proposed updates) tak wat takke geïntegreer het wat dalk nog nie gereed is om in die next of master tak in te gaan nie. Die idee is dat jou takke op verskillende vlakke van stabiliteit is; wanneer hulle 'n meer stabiele vlak bereik, word hulle in die tak bokant hulle saamgesmelt (merged). Weereens, dit is nie nodig om veelvuldige langlopende takke te hê nie, maar dit is dikwels nuttig, veral wanneer jy met baie groot of komplekse projekte te doen het.

Onderwerp-takke is egter nuttig in projekte van enige grootte. 'n Onderwerp-tak is 'n kortlewende tak wat jy skep en gebruik vir 'n enkele spesifieke kenmerk (feature) of verwante werk. Dit is iets wat jy waarskynlik nog nooit voorheen met 'n VCS gedoen het nie, want dit is oor die algemeen te duur om takke te skep en te smelt (merge). Maar in Git is dit algemeen om takke verskeie kere per dag te skep, daaraan te werk, saam te smelt en uit te vee.

Jy het dit in die laaste afdeling gesien met die iss53 en hotfix takke wat jy geskep het. Jy het 'n paar vasleggings (commits) op hulle gedoen en hulle uitgevee direk nadat jy hulle in jou hooftak (main branch) saamgesmelt het. Hierdie tegniek stel jou in staat om vinnig en heeltemal van konteks te verander — omdat jou werk in silo’s geskei is waar al die veranderings in daardie tak met daardie onderwerp te doen het, is dit makliker om te sien wat gebeur het tydens kodehersiening (code review) en dergelike dinge. Jy kan die veranderings daar hou vir minute, dae, of maande, en dit saamsmelt wanneer hulle gereed is, ongeag die volgorde waarin hulle geskep is of waaraan gewerk is.

Oorweeg 'n voorbeeld waar jy bietjie werk doen (op master), af vertak (branch off) vir 'n kwessie (iss91), 'n bietjie daaraan werk, 'n tweede tak af vertak om 'n ander manier te probeer om dieselfde ding te hanteer (iss91v2), teruggaan na jou master tak en 'n rukkie daar werk, en dan daarvandaan vertak om werk te doen wat jy nie seker is 'n goeie idee is nie (dumbidea tak). Jou vasleggingsgeskiedenis sal min of meer so lyk:

Sê nou jy besluit jy hou die beste van die tweede oplossing vir jou kwessie (iss91v2); en jy het die dumbidea tak vir jou medewerkers gewys, en dit blyk geniaal te wees. Jy kan die oorspronklike iss91 tak weggooi (wat veroorsaak dat jy vasleggings C5 en C6 verloor) en die ander twee saamsmelt (merge). Jou geskiedenis lyk dan so:

Ons sal in meer detail ingaan oor die verskillende moontlike werkvloeie (workflows) vir jou Git-projek in Distributed Git, so voordat jy besluit watter vertakkingskema jou volgende projek sal gebruik, maak seker dat jy daardie hoofstuk lees.

Dit is belangrik om te onthou wanneer jy al hierdie dinge doen, dat hierdie takke heeltemal plaaslik (local) is. Wanneer jy vertak en saamsmelt (branching and merging), word alles slegs in jou Git-bewaarplek (repository) gedoen — daar is geen kommunikasie met die bediener nie.