5.3 Porazdeljeni Git - Vzdrževanje projekta

Če prejmete programski popravek od nekoga, ki ga je generiral z git diff ali kakšno variacijo ukaza Unix diff (kar ni priporočljivo; glejte naslednji razdelek), ga lahko uporabite z ukazom git apply. Predpostavljamo, da ste shranili programski popravek v /tmp/patch-ruby-client.patch, lahko uporabite popravek na naslednji način:

To spremeni datoteke v vašem delovnem direktoriju. Je skoraj identično pogonu ukaza patch -p1, da uporabite programski popravek, vendar je bolj paranoično in sprejema manj nejasna ujemanja kot popravek. Upravlja tudi dodajanja datotek, brisanja in preimenovanja, če so opisana v obliki git diff, kar patch ne naredi. Na koncu git apply je model »uporabi vse ali prekliči vse«, kjer je uporabljeno vse ali nič, z razliko, kjer patch lahko delno uporablja datoteke popravkov, kar pusti vaš delovni direktorij v čudnem stanju. git apply je splošno veliko bolj konzervativen kot patch. Ne bo ustvaril potrditve za vas — po tem, ko ga poženete, morate ročno dati v področje priprave in potrditi uvedene spremembe.

git apply lahko uporabite tudi, da vidite, če se programski popravek lahko gladko uporabi, preden ga poskusite dejansko uporabiti — poženete lahko git apply --check s popravkom:

Če ni nobenega izpisa, potem bi se moral programski popravek uporabiti gladko. Ta ukaz se tudi konča z neničelnim statusom, če preverjanje ni uspešno, tako da ga lahko uporabite v skriptih, če želite.

Če je uporabnik, ki prispeva, uporabnik Git in je bilo dovolj dobro uporabiti ukaz format-patch za generiranje njegovega popravka, potem je vaše delo enostavnejše, saj programski popravek vsebuje informacije avtorja in sporočilo potrditve za vas. Če lahko, spodbudite svoje sodelavce, da uporabljajo format-patch namesto diff za generiranje popravkov za vas. git apply bi morali uporabiti samo pri opuščenih popravkih in podobnih stvareh.

Da uporabite programski popravek generiran s format-patch, uporabite git am (ukaz se imenuje am, ker pomeni »uporabi (angl. apply) serijo popravkov iz mailboxa«). Tehnično je git am zgrajen, da prebere datoteko mbox, ki je enostaven tekstovni format za shranjevanje enega ali več e-poštnih sporočil v eni tekstovni datoteki. Videti je nekako takole:

To je začetek izhodnega zapisa ukaza git format-patch, ki ste ga videli v prejšnjem odseku; predstavlja tudi veljaven e-poštni format mbox. Če vam nekdo pravilno pošlje programski popravek z uporabo ukaza git send-email in ga prenesete v obliki mbox, lahko git am usmerite v datoteko mbox in začne uporabljati vse popravke, ki jih vidi. Če uporabljate odjemalca pošte, ki lahko več e-poštnih sporočil shranjuje v obliki mbox, lahko celotno serijo popravkov shranite v datoteko in nato uporabite git am, da jih uporabite enega za drugim.

Če pa je nekdo naložil datoteko s popravkom, ki je bila ustvarjena prek ukaza git format-patch v sistem za beleženje težav ali kaj podobnega, lahko datoteko shranite lokalno in jo nato prenesete v git am, da jo uporabite:

Vidite lahko, da se je programski popravek uporabil brez težav in samodejno ustvaril novo potrditev za vas. Informacije o avtorju so vzete iz glav From in Date v e-pošti, sporočilo potrditve pa je vzeto iz Subject in telesa (pred popravkom) e-pošte. Če je bil na primer ta programski popravek uporabljen iz zgornjega primera mbox, bi bila ustvarjena potrditev nekaj podobnega temu:

Informacije Commit kažejo osebo, ki je uporabila programski popravek, in čas uporabe. Informacije Author pa kažejo na osebo, ki je prvotno ustvarila programski popravek in kdaj je bil prvotno ustvarjen.

Vendar lahko se zgodi, da se programski popravek ne bo uporabil brez težav. Morda se je vaša glavna veja preveč oddaljila od veje, iz katere je bil programski popravek zgrajen, ali pa je popravek odvisen od drugega popravka, ki ga še niste uporabili. V tem primeru bo proces git am spodletel in vas vprašal, kaj želite storiti:

Ta ukaz vstavi označevalce konfliktov v datoteke, s katerimi ima težave, podobno kot pri operaciji združevanja ali ponovnem baziranju, ki ima konflikte. To težavo lahko rešite na podoben način — uredite datoteko, da rešite konflikt, shranite novo datoteko in nato zaženite git am --resolved, da nadaljujete na naslednji programski popravek:

Če želite, da Git poskusi bolj inteligentno rešiti konflikt, mu lahko podate možnost -3, kjer Git poskuša izvesti tristransko združevanje. Ta možnost ni privzeto vklopljena, ker ne deluje, če potrditve, ki jih navaja programski popravek, ni v vašem repozitoriju. Če imate to potrditev — če je bil programski popravek ustvarjen na podlagi javne potrditve — je možnost -3 na splošno veliko bolj inteligentna pri uporabi konfliktnega popravka:

V tem primeru bi bil programski popravek brez možnosti -3 obravnavan kot konflikt. Ker je bila uporabljena možnost -3, se je programski popravek uporabil brez težav.

Če uporabljate več popravkov iz mboxa, lahko ukaz am zaženete tudi v interaktivnem načinu, ki se ustavi pri vsakem popravku, ki ga najde, in vpraša, ali ga želite uporabiti:

To je koristno, če imate shranjenih več popravkov, saj si lahko programski popravek najprej ogledate, če se ne spomnite, kaj predstavlja, ali pa ga ne uporabite, če ste ga že uporabili.

Ko so vsi popravki za vašo temo uporabljeni in potrjeni v vaši razvojni veji, lahko izberete, ali jih želite integrirati v dolgotrajno vejo in na kakšen način.

Eden izmed osnovnih potekov dela je, da preprosto združite vse delo neposredno v vašo vejo master. V tem scenariju imate vejo master, ki vsebuje v bistvu stabilno kodo. Ko imate delo v tematski veji, za katerega menite, da ste ga dokončali, ali delo, ki ga je prispeval nekdo drug in ste ga preverili, ga združite v vašo vejo master, izbrišete tematsko vejo, ki ste jo ravno združili, ter ponovite.

Na primer, če imamo repozitorij z delom v dveh vejah imenovanih ruby_client in php_client, ki je videti kot na sliki Zgodovina z več tematskimi vejami, in združimo ruby_client, nato pa še php_client, bo vaša zgodovina videti kot na sliki Po združitvi tematske veje.

To je verjetno najpreprostejši potek dela, vendar lahko pri delu z večjimi ali bolj stabilnimi projekti, kjer morate biti zelo previdni pri tem, kaj uvajate, povzroči težave.

Če imate pomembnejši projekt, bi morda želeli uporabiti dvofazni postopek združevanja. V tem scenariju imate dve dolgotrajni veji, master in develop, pri katerih določite, da se master posodobi le, ko je izdana zelo stabilna različica in se vsa nova koda integrira v vejo develop. Občasno obe veji potisnete v javni repozitorij. Vsakič, ko želite združiti novo tematsko vejo (slika Pred združitvijo tematske veje), jo združite v vejo develop (slika Po združitvi tematske veje); nato, ko označite izdajo, master hitro posodobite do stabilne točke, kjer je trenutna veja develop (slika Po objavi projekta).

Na ta način lahko ljudje, ki si klonirajo vaš repozitorij projekta, izvlečejo master za gradnjo najnovejše stabilne različice in jo enostavno ohranjajo posodobljeno, ali pa preverijo develop, ki vsebuje najnaprednejšo vsebino. To zasnovo lahko razširite tudi tako, da imate vejo integrate, v kateri se združi vse delo. Nato, ko je koda na tej veji stabilna in uspešno preide teste, jo združite v vejo develop, in ko se ta predstavi kot stabilna za več časa, posodobite vejo master.

Projekt Git ima štiri dolgotrajne veje: master, next in seen (prej pu — predlagane posodobitve — angl. proposed updates) za novo delo in maint za vzdrževanje posodobitev. Ko prispe novo delo s strani sodelavcev, se zbere v tematskih vejah v repozitoriju vzdrževalca na način, podoben temu, kar smo opisali (glejte sliko Upravljanje kompleksne serije vzporednih prispevanih tematskih vej). V tej fazi se ocenijo tematske veje, da se ugotovi, ali so varne in pripravljene za uporabo, ali potrebujejo še več dela. Če so varne, se vgradijo v next in ta veja se objavi, tako da lahko vsi preizkusijo teme, integrirane skupaj.

Če teme še potrebujejo delo, so namesto tega združene v vejo seen. Ko se ugotovi, da so v celoti stabilne, se teme ponovno združi v vejo master. Veji next in seen sta nato znova zgrajeni iz master. To pomeni, da se master skoraj vedno premika naprej, next se občasno ponovno bazira in seen se ponovno bazira še pogosteje:

Ko je tematska veja končno združena v master, se izbriše iz repozitorija. Projekt Git ima tudi vejo maint, ki je razvejana od zadnje različice, da zagotavlja popravke za nazaj, če je potrebna vzdrževalna izdaja. Tako imate pri kloniranju repozitorija Git štiri veje, ki jih lahko preizkusite, da ovrednotite projekt v različnih razvojnih fazah, odvisno od tega, kako drzni želite biti, ali kako želite prispevati; in vzdrževalec ima strukturiran potek dela, ki mu pomaga preverjati nove prispevke. Potek dela projekta Git je specializiran. Za boljše razumevanje si lahko ogledate Gitov vodnik za vzdrževanje.

Drugi vzdrževalci raje ponovno bazirajo ali izberejo najboljše prispevano delo na vrh njihove veje master, namesto da bi ga združili, da ohranijo predvsem linearno zgodovino. Ko imate delo v tematski veji in ste ugotovili, da ga želite integrirati, se premaknete na to vejo in zaženete ukaz za ponovno baziranje (angl. rebase), da ponovno sestavite spremembe na vrhu trenutne veje master (ali develop in tako naprej). Če to deluje dobro, lahko hitro previjete naprej vašo vejo master in imeli boste linearno zgodovino projekta.

Drugi način za premikanje vpeljanega dela iz ene veje v drugo je t. i. izbiranje najboljšega (angl. cherry picking). Izbiranje najboljšega v Gitu je podobno ponovnem baziranju za eno samo potrditev. Vzame programski popravek, ki je bil uveden v eni potrditvi, in ga poskuša ponovno uporabiti na veji, na kateri trenutno ste. To je uporabno, če imate na veji več potrditev in želite integrirati le eno od njih, ali če imate samo eno potrditev na veji in bi jo raje izbrali kot najboljšo namesto ponovnega baziranja. Na primer, recimo, da imate projekt, ki je videti tako:

Če želite povleči potrditev e43a6 v vašo vejo master, lahko poženete:

To povleče iste spremembe, ki so bile predstavljene v e43a6, vendar dobite novo vrednost SHA-1 potrditve, ker je uporabljeni datum drugačen. Sedaj je vaša zgodovina videti takole:

Sedaj lahko odstranite svojo tematsko vejo in opustite potrditve, ki jih niste želeli povleči.

Če delate veliko združevanja in ponovnega baziranja, ali vzdržujete dolgotrajno tematsko vejo, ima Git lastnost, ki se imenuje »rerere«, ki je lahko koristna.

Rerere pomeni »reuse recorded resolution« (ponovno uporabi posneto rešitev) — je način bližnjice ročnega reševanja konflikta. Ko je rerere omogočen, bo Git obdržal skupek slik pred in po iz uspešnih združitev in če opazi, da gre za konflikt, ki je videti točno tak kot eden, ki ste ga že popravili, bo enostavno samo uporabil programski popravek od zadnjič, ne da vas pri tem z njim moti.

Ta lastnost prihaja v dveh delih: konfiguracijska nastavitev in ukaz. Konfiguracijska nastavitev je rerere.enabled in je dovolj priročna, da jo dodate v svoje globalne nastavitve:

Sedaj, vsakič, ko izvedete združevanje, ki rešuje konflikte, se bo rešitev zabeležila v predpomnilnik, če jo boste potrebovali v prihodnosti.

Če je treba, lahko z ukazom git rerere interaktivno upravljate s predpomnilnikom rerere. Ko se uporabi samostojno, Git preveri svojo bazo rešitev in poskuša najti ujemanje z morebitnimi trenutnimi konflikti ob združevanju in jih reši (če je rerere.enabled nastavljeno na true, se to izvede samodejno). Obstajajo tudi podukazi, s katerimi lahko vidite, kaj bo zabeleženo, izbrišete določeno rešitev iz predpomnilnika ali počistite celoten predpomnilnik. Rerere bomo podrobneje obravnavali v Rerere.