3.2 Veje Git - Osnove vej in združevanja

Najprej recimo, da delate na vašem projektu in imate že nekaj pošiljanj.

Odločili ste se, da boste delali na težavi #53 v kateremkoli težavam-sledilnem sistemu, ki ga vaše podjetje uporablja. Da ustvarite vejo in nanjo preklopite istočasno, lahko poženete ukaz git checkout s stikalom -b:

To je bližnjica za:

Delate na vaši spletni strani in naredite nekaj pošiljanj. Da to naredite premakne vejo iss53 naprej, ker ste jo izpisali (to pomeni, vaš HEAD kaže nanjo):

Sedaj dobite klic, da je težava s spletno stranjo in jo potrebujete takoj popraviti. Z Git-om vam ni treba nalagati vašega popravka skupaj s spremembami iss53, ki ste jih naredili in ni vam treba vložiti veliko napora v povračanje teh sprememb preden lahko delate na uporabi vašega popravka na to, kar je v produkciji. Vse kar morate narediti je preklopiti nazaj na vašo vejo master.

Vendar preden to naredite, pomnite, da če ima vaš delovni direktorij ali vmesna faza neposlane spremembe, ki so v konfliktu z vejo, ki jo izpisujete, vam Git ne bo dovolil preklopiti vej. Najbolje je imeti čisto delovno stanje, ko preklapljate veje. Obstajajo načini, da se temu izognete (v glavnem, skrivanje in pošiljanje sprememb), kar bomo pokrili kasneje v [r_git_stashing]. Za sedaj predpostavimo, da ste poslali vse vaše spremembe, tako da lahko preklopite nazaj na vašo vejo master:

Na tej točki vaš delovni direktorij projekta je točno tak, kakor je bil preden, ste pričeli delati na težavi #53 in sedaj se lahko skoncentrirate na vaš sprotni popravek. To je pomembna točka za zapomniti: ko preklapljate veje, Git ponastavi vaš delovni direktorij, da izgleda kot je, ko ste zadnjič poslali na to vejo. Doda, odstrani in spremeni datoteke avtomatično, da zagotovi, da je vaša delovna kopija taka, kot je izgledala veja na vašem zadnjem pošiljanju vanjo.

Naslednje imate za narediti sprotni popravek. Ustvarimo vejo sprotnega popravka na kateri delate dokler ni končan:

Lahko poženete vaše teste, zagotovite, da je sprotni popravek, kar želite in ga združite nazaj v vašo vejo master, da naložite v produkcijo. To naredite z ukazom git merge:

Opazili bste frazo fast-forward'' v tem združevanju. Ker je bilo pošiljanje, kamor kaže veja, ki ste jo združili, direktno gorvodno pošiljanja na katerem ste, Git enostavno premakne kazalec naprej. Da dodamo frazo na drug način, kot poskušate združiti eno pošiljanje z drugim, se to lahko doseže s sledenjem zgodovine prvega pošiljanja, Git poenostavi stvari, tako da prestavi kazalec naprej, ker ni divergentnega dela za združiti skupaj - to se imenuje fast-forward''.

Vaša sprememba je sedaj posnetek pošiljanja, ki kaže na vejo master in lahko naložite popravek.

Ko je vaš super pomemben pomemben popravek naložen, ste pripravljeni preklopiti nazaj k delu, ki ste ga delali preden ste bili zmoteni. Vendar najprej boste izbrisali vejo hotfix, ker je ne potrebujete več - veja master kaže na enako lokacijo. Lahko jo izbrišete z opcijo -d ukazu git branch:

Sedaj lahko vaše delo preklopite nazaj na vašo vejo dela v teku na težavi #53 in nadaljujete delo na njej

Tu je vredno omeniti, da delo, ki ste ga naredili na vaši veji hotfix ni vsebovano na datotekah v vaši veji iss53. Če jo potrebujete potegniti notri, lahko združite vašo vejo master v vašo vejo iss53 s pogonom git merge master ali pa lahko počakate integracijo teh sprememb, dokler se ne odločite potegniti veje iss53 nazaj v master kasneje.

Predpostavimo, da ste se odločili, da je vaša težava #53 končana in pripravljena, da je združena v vašo vejo master Da to naredite boste združili vašo vejo iss53 v master, tako kot ste prej združili vašo vejo hotfix. Vse kar morate narediti je izpisati vejo, ki jo želite združiti in nato pognati ukaz git merge:

To izgleda nekoliko različno kot združitev hotfix, kar ste prej naredili. V tem primeru se je vaša zgodovina razvoja oddaljila od neke starejše točke. Ker pošiljanje na veji, na kateri se nahajate, ni direktni prednik veje, ki jo združujete, mora Git narediti nekaj dela. V tem primeru Git naredi enostavno tri-načinsko združitev z uporabo dveh posnetkov, ki kažeta na vejo tips in pogostega prednika od dveh.

Namesto samo premikanja kazalca veje naprej, Git ustvari nov posnetek, ki rezultira iz te tri-načinske združitve in avtomatično ustvari novo pošiljanje, ki kaže nanjo. Na to se sklicuje kot pošiljanje združitve in je posebno v tem, da ima več kot samo enega starša.

Vredno je pokazati, da Git določa najboljšega pogostega prednika za uporabo za svojo bazo združitev; to je različno od stareših orodij kot je CVS ali Subversion (pred verzijo 1.5), kjer je razvijalec, ki je delal združitev, moral ugotoviti najboljšo osnovo združitve sam. To naredi združevanje veliko bolj enostavno v Git-u kot v teh starejših sistemih.

Sedaj, ko je vaše delo združeno, nimate več potrebe po veji iss53. Problem lahko zaprete v vašem sistemu sledenja problemov in izbrišete vejo:

Včasih ta proces ne gre gladko. Če ste spremenili isti del neke datoteke različno v dveh vejah, ki jih združujete skupaj, jih Git ne bo mogel združiti čisto. Če je vaš popravek za težavo #53 spremenil isti del datoteke kot hotfix, boste dobili konflikt združevanja, ki izgleda nekako takole:

Ti ni avtomatično ustvaril pošiljanja združevanja. Ustavil je proces, dokler ne rešite konflikta. Če želite videti, katere datoteke niso združene na katerikoli točki po konfliktu združevanja, lahko poženete git status:

Karkoli, kar ima konflikte združevanja in ni bilo rešeno je izpisano kot nezdruženo. Git doda standardne označevalce konflikta ločljivosti k datotekam, ki imajo konflikte, tako da jih lahko odprete ročno in rešite te konflikte. Vaša datoteka vsebuje sekcijo, ki izgleda nekako takole:

To pomeni, da verzija v HEAD (vaše veje master, ker to je bilo, kar ste imeli izpisano, ko ste pognali vaš ukaz združevanja) je vrhnji del tega bloka (vse nad =======), medtem ko verzija v vaši veji iss53 izgleda kot vse v spodnjem delu. Da rešite konflikt, morate ali izbrati eno stran ali drugo ali združiti vsebino sami. Na primer ta konflikt lahko rešite z zamenjavo celotnega bloka s tem:

Ta ločljivost ima malo vsake sekcije in <<<<<<<, =======, and >>>>>>> vrstice so bile v celoti odstranjene. Ko ste rešili vsakega od teh sekcij v vsaki konfliktni datoteki, poženite git add na vsaki datoteki, da jo označite kot rešeno. Dajanje datoteke v vmesno fazo jo označi kot rešeno v Git-u.

Če želite uporabiti grafično orodje, da rešite te težave, lahko poženete git mergetool, ki zažene ustrezno vizualno združevalno orodje in vas sprehodi skozi konflikte:

Če želite uporabiti drugo orodje združevanja namesto privzetega (Git izbere opendiff v tem primeru, ker je bil ukaz pognan na Mac-u), vidite lahko vsa podprta orodja izpisana na vrhu za ``one of the following tools.'' Samo vpišite ime orodja, ki bi ga raje uporabljali.

Ko zapustite orodje združevanja, vas Git vpraša, če je bila združitev uspešna. Če poveste skripti, da je bila, da datoteko v vmesno fazo, da jo označi kot rešeno za vas. Ponovno lahko poženete git status, da potrdite, da so bili vsi konflikti rešeni:

Če ste s tem zadovoljni in potrdite, da je vse, kar je imelo s konflikti bilo dano v vmesno fazo, lahko vpišete git commit, da končate pošiljanje združevanja. Sporočilo pošiljanja privzeto izgleda nekako takole:

To sporočilo lahko spremenite s podrobnostmi o tem, kako ste rešili združevanje, če razmišljate, da bi bilo v pomoč ostalim, da pogledajo to združevanje v prihodnosti - zakaj ste to naredili, če ni očitno.