Turinys
- Gito iškilimas
- Būdinga rizika, susijungianti su „Git“ susijungimais
- Žmogus už užuolaidos: kaip veikia „Git“?
- Pavyzdys: įsipareigojimų sujungimas
- Sujungti konfliktus
- Kas atsitinka susijungus
- Ryklys vandenyje: ar gitas padeda, ar skauda?
- 2 pavyzdys: klaidos sujungiant
- Sunkiai randama klaida
- Išsinešimas: filialų problemos
- Magistralinė plėtra
- Privalumai
- Problema ne Git; Tai, kaip mes jį naudojame
Mike'as Shoemake'as jau 20 metų yra sėkmingas programinės įrangos kūrėjas, kuriantis kokybiškas programas ir puikiai veikiančias kūrėjų komandas.
Gito iškilimas
Atrodo, kad „Git“ užvaldo pasaulį, kiek tai susiję su versijų valdymo sistemomis. Prieš dešimt metų būtent Subversion patraukė mūsų susidomėjimą (raudona linija apačioje). Dabar „Git“ (mėlyna linija) tvirtai kontroliuoja.
Vis dėlto su Gitu reikia daug ko išmokti. Daugelis iš mūsų atėjo į „Git“ praleidę daug laiko su „Subversion“ ar kitu konkurentu, o tai, kaip naudojame „Git“, dabar atspindi mūsų patirtį ir supratimą apie tas kitas priemones. Mes išmokome tik tiek, kad išgyventume, ir greitai grįžome į savo kasdienius darbus.
Bet „Git“ labai labai skiriasi nuo bet kurios kitos versijos valdymo sistemos, kurią galbūt naudojote. Jei supranti Gitą, tai tavo geriausias draugas. Jei to nepadarėte, galite tai naudoti taip, kad jums ir jūsų komandai kiltų nereikalinga rizika. Keista, kad gamybos problemos gali kilti naudojant „Git“ taip, kaip jis nebuvo skirtas naudoti.
Būdinga rizika, susijungianti su „Git“ susijungimais
Kaip matysime, „Git“ susijungimai turi būdingą riziką, susijusią ne tik su kūrėjais, bet ir suvienijančiais konfliktų sprendimą. Ši rizika smarkiai didėja, kol laukiame, kol integruosime savo kodą. Pasirodo, kad dideli susijungimai yra daug rizikingesni nei maži, ir vis dėlto daugelis kūrėjų komandų vykdo didelius susijungimus kaip gyvenimo būdą. Jūsų išsišakojęs modelis gali turėti neigiamos įtakos gamybos kokybei, o jūs to dar nežinote.
Pirmiausia pažvelkime į tai, kaip „Git“ sujungia darbą, tada galime nustatyti, kaip geriausiai juos naudoti. Toliau pateiktuose pavyzdžiuose mes naudosime „SourceTree“, kad padėtų mums įsivaizduoti, kas vyksta.
Žmogus už užuolaidos: kaip veikia „Git“?
Galima pagalvoti, kad „Git“ susilieja kaip maišant kortų kaladę. Gitas paima dvi atskiras kortų kaladėles ir supina jas į vieną kaladę, mėtydamas priedus, kai randami dublikatai.
Pavyzdys: įsipareigojimų sujungimas
Apsvarstykite toliau pateiktą pavyzdį:
Tai yra paprastas „Groovy“ klasės failas, kuris nieko nedaro, tik atlieka „println“ () skambučius. Dabar du kūrėjai, Jimas ir Fredas, abu pakeitė šį failą vienu metu, o norint išspręsti reikės susieti.
Kiekvienas sukūrė filialą, kuris yra tik vardas, prie kurio galima susieti įsipareigojimų seriją. Filialas (t. Y. Pavadinimas) yra tiesiogiai susijęs su naujausiu įsipareigojimu, todėl, kai atliekamas naujas įsipareigojimas, filialo pavadinimas pereina prie naujo. Kiekvienas įsipareigojimas rodo savo pirmtaką (-us) - jie niekada nerodo į priekį.
Štai Jimo įsipareigojimas:
Atkreipkite dėmesį, kad Jimas redagavo 21 eilutę, kad pridėtų komentarą, o Gitas mato tai kaip vieną gretimą pakeitimą, kuris apima pašalinimą ir papildymą.
Štai Fredo įsipareigojimas:
Svarbu tai, kad čia yra keli skirtingi pokyčiai - vieni sutampa, o kiti - tik viena linija.
Norėdami gauti susijungimo peržiūrą, „SourceTree“ galime pažymėti abu įsipareigojimus, spustelėti šaltinio failą ir peržiūrėti gautą skirtumą.
Pasirinkus abu įsipareigojimus, matome skirtumą žemiau:
Sujungti konfliktus
„Git“ identifikuoja atskirus pokyčius, kurių kiekvienas yra gretimas pakitusių linijų blokas. Gitas bandys supinti pakeistus blokus su nepakeistais blokais. Jei dviejuose pakeistuose blokuose tarp jų nėra bent vienos nepakitusios eilutės, Gitas tai laiko susijungimo konfliktu.
Šiame pavyzdyje mes jau galime pamatyti, kur bus susijungimo konfliktai:
- 5 eilutė
- 21 eilutė
Kadangi raudonos ir žalios spalvos pokyčiai „liečia“ skirtumą, Gitas nežinos, kurį iš jų uždėti ant viršaus. Taigi, jis pažymi šiuos pokyčius kaip susijungiančius konfliktus ir prašo kūrėjo tai išsiaiškinti. Kadangi kiti pakeitimai yra atskirti bendromis kodo eilutėmis, „Git“ yra aiški tvarka. Žvelgiant iš Gito perspektyvos, viskas yra apie tai, kaip susipinti daiktus kartu ir įsitikinti, kad tai padaryta teisinga tvarka. Jei „Git“ nėra tikras, jis prašo išspręsti tai pats.
Kas atsitinka susijungus
Štai faktinio sujungimo rezultatas:
Kaip matote, susijungimo konfliktai pasirodė ten, kur ir buvo galima tikėtis. 29 ir 30 eilutės laikomos vienu gretutiniu pakeitimu, todėl kartu įtraukiamos į susijungimo konfliktą. Kadangi kiti pakeitimai nesutampa, „Git“ gali nustatyti teisingą tvarką, o visa kita padaro už jus.
Ryklys vandenyje: ar gitas padeda, ar skauda?
Gitas neabejotinai yra naudingas sprendžiant konfliktus už mus. Kūrėjams patinka ši funkcija! Daugelis iš mūsų stipriai remiasi „Git“ automatinio sujungimo galimybėmis, tarsi „Git“ būtų futuristinis „Android“, turintis pašėlusius kodavimo įgūdžius, kuris rūpinasi mūsų lengvu darbu, kad mums nereikėtų jo prakaituoti. Ir vis dėlto Gitas nieko nežino apie kontekstą. Tai nereiškia semantinio analizavimo ir niekaip negali nustatyti, ar dviejų sujungtų šaltinio failų pakeitimai iš tikrųjų priklauso arba yra vienas kitą išskiriantys.
2 pavyzdys: klaidos sujungiant
Apsvarstykite toliau pateiktą pavyzdį:
Tai labai paprastas „Groovy“ šaltinio failas su daugybos (int, int) metodu ir pagrindiniu metodu, kuris iškviečia dauginimą (). Tai iš tikrųjų yra kodas, esantis žemiau esančio pagrindinio filialo galvoje.
Fredas pridėjo naują skambutį į dauginimo () metodą:
Fredui nežinant, Jimas nusprendė atsisakyti daugybos metodo, pašalindamas jį ir nuo jo priklausančius metodo skambučius.
Galutinis sujungimo rezultatas (parodytas žemiau) apima iškvietimą į dauginimo () metodą, tačiau dabar šio metodo nebėra.
Sunkiai randama klaida
Dar blogiau, kad šis kodas iš tikrųjų kompiliuojamas, nes tai yra „Groovy“, o ne „Java“. Taigi vienintelis būdas sužinoti, ar egzistuoja ši problema, yra aptikti išimtį vykdymo metu. Jei jūsų klaidų tvarkymas nėra puikus, jums gali būti sunku sekti šią problemą ir niekada negalėsite suprasti, kad tai sukėlė „Git“ automatinis sujungimas.
Dinaminės kalbos (pvz., „Groovy“, „Javascript“, „Python“, „Ruby“ ir daugelis kitų) yra ypač jautrios šiai problemai dėl riboto kompiliavimo laiko tikrinimo. Nors tvirta vieneto / integracijos testo aprėptis tikrai padeda nustatyti problemas, kurios gali kilti dėl to, komandos dažnai neturi aprėpties, reikalingos apsaugoti jas nuo žalos.
Nors dažniausiai Gitas puikiai dirba už jus spręsdamas konfliktus, yra galimybė klaidoms pasitaikyti. Jei sutiksite, kad kai kūrėjai netinkamai elgiasi suvienydami konfliktus, „Git“ susijungimai tikrai turi su jais susijusios rizikos. Taigi, kaip sušvelninti šią riziką?
Išsinešimas: filialų problemos
Daugelis kūrėjų komandų yra naudoję funkcijų šakas kaip neatskiriamą savo šakojimo modelio dalį. Funkcijų filialai yra populiarios „GitFlow“ pirmos klasės piliečiai, ir daugelis organizacijų sukūrė pasirinktinius šakojimo modelius, kurie labai priklauso nuo funkcijų šakų. Funkcijų filialai leidžia atskiriems kūrėjams dirbti atskirai, kol jų funkcija bus baigta, todėl jiems nereikės neigiamai veikti kažkieno pakeitimų. Kai kurios organizacijos naudojasi ilgai veikiančiais filialais, kad izoliuotų visas komandas, kai toje pačioje kodų bazėje dirba kelios komandos. Kiti juos naudoja, norėdami išskirti kelis vienu metu kuriamus leidimus.
Galų gale visi šie dalykai, sukurti atskirai, turi būti sujungti, kad juos būtų galima gaminti, ir ten atsiranda rizika. Sujungus dvi šakas ir kiekvienam įvykus dideliems pokyčiams, beveik neįmanoma tiksliai žinoti, kad tarp „Git“ ir mūsų rankinio konfliktų sprendimo kiekviena situacija buvo tvarkoma teisingai. Vėlgi, Gitas nieko nežino apie kontekstą, tikslą ar semantiką. Tai galvoja tik apie tvarką.
Kūrėjai mokomi, kad ilgai veikiančios funkcijų šakos yra tinkamos tol, kol periodiškai sujungiate naujus tikslinės šakos (būsimo sujungimo paskirties) pakeitimus į savo funkcijų šaką. Tai turėtų jus palaikyti vienoje su visais kitais. Deja, tai miražas. Jei 5 komandos kūrėjai tam tikrą laiką dirbo su atskiromis funkcijų šakomis, nesvarbu, kaip dažnai jie sujungia tikslinę šaką su atitinkamais filialais. Jie vis dar nėra integruoti. Įvyko nemažai pokyčių, kurių niekas nemato, nes žmonės dar nėra pasirengę susijungti.
Ką daryti, jei tai nėra 5 kūrėjai, o 25 ar 75, visi dirba toje pačioje kodų bazėje? Šie sujungimai atliekami artėjant prie sprinto pabaigos, o jo patikrinimas buvo daug laiko reikalaujantis teisingai. Vėluojanti integracija visada kelia nereikalingą riziką ir dažnai kelia tai tiesiai tada, kai to mažiausiai norite - kai apvyniojate sprintą ar laidą.
Magistralinė plėtra
Dabar apsvarstykime magistralės plėtrą, pagal kurią kūrėjai prašo mažų, gerai išbandytų įsipareigojimų kasdien, jei ne kelis kartus per dieną, į bendrą bagažinės šaką, paprastai vadinamą „pagrindinis“. Priežiūros šakos kuriamos, kai išeina leidimai, tačiau visa nauja plėtra eina tiesiai į pagrindinę šaką.
Didelės funkcijos suskirstytos į mažus kąsnio dydžio gabalėlius, o kūrėjai naudoja funkcijų perjungiklį, kad paslėptų savo pakeitimus, kol ateis laikas pradėti veikti. Tai yra tikra nuolatinė integracija, kuri mums turi keletą svarbių pasekmių:
- Nėra jokių funkcijų atšakų, todėl kiekvienas kūrėjas kuria šiandieninį kodą ant visų vakarykščių kodų.
- Jokio filialų sujungimo - tiesiog atlikite bagažinės ir priežiūros šakų pakeitimus.
- Klaidos, skirtos priežiūros šakai, pirmiausia pirmiausia būna fiksuojamos bagažinėje, o po to vyšnios nuskinamos į priežiūros šaką (kad būtų išvengta regresijos problemų).
Privalumai
- Drastiškai sumažėja galimybė sujungti konfliktus. Mažiau kodo pasikeitė, todėl mes turime mažai konfliktų galimybių.
- Dažnas įpareigoja bagažinės jėgos kūrėjus atsižvelgti į kokybę viso statybų ciklo metu, o ne taupyti iki galo (nedideli pakeitimai, bandymai, stumdymai; nedideli pokyčiai, bandymai, stūmimai).
- Konfliktai užklumpa anksti statybų metu, o ne vėlai susijungimo metu.
- Nuolatinė integracija sukuria tikrą langą į dabartinę kodo būseną, leidimą ir kt. Niekas neslepia šešėlyje.
Vėluojanti integracija taip pat gali priversti kelis kartus stabilizuoti tą patį kodą. Pavyzdžiui, kai kurios komandos atlieka funkcijų testavimą ir stabilizavimą funkcijų šakoje, kad jas būtų galima išbandyti atskirai. Kai tik susijungimas įvyksta, gali būti, kad funkcija destabilizavosi, ir dabar jūs turite tai atlikti iš naujo. Arba galite manyti, kad jis stabilus, nes jis dirbo funkcijų skyriuje, ir tiesiog leiskite jam išeiti pro duris tokiu būdu. Viso to būtų galima išvengti, jei tik anksti integruotumėmės.
Problema ne Git; Tai, kaip mes jį naudojame
„Git“ turi daugybę fantastiškų savybių. Tai, kad sugebėjimai susijungia, galva ir pečiai viršija tai, ką teikia „Git“ konkurentai. Tie iš mūsų, kurie jį naudojo, matėme, kad „Git“ sėkmingai pasikeitė be mūsų pagalbos, o tai gali mus priversti klaidingu saugumo jausmu. Problema visai ne „Git“. Tai, kaip mes jį naudojame. Protingiausias dalykas, kurį galime padaryti, yra iš tikrųjų įdėti pastangų, kad suprastume, kas yra įrankis ir kas ne. Kai tai padarysime, galėsime jį naudoti taip, kaip buvo numatyta, ir nustoti tuo save žaloti.
Šis straipsnis yra tikslus ir tikras, kiek autorius žino. Turinys skirtas tik informaciniams ar pramoginiams tikslams ir nepakeičia asmeninių ar profesionalių patarimų verslo, finansų, teisiniais ar techniniais klausimais.
