Sėkmingas šakų modelis Git

Svarbu žinoti, kaip vartoti Git, ir tai apima bendradarbiavimo programinės įrangos kūrimo aplinkos valdymo.

Kreditų

Šis pranešimas yra portugalų kalba originalas, Anglų kalba, “Sėkmingas Git šakojimo modelis“, tinkamai įgaliotas autorius, Vinsentas Driessenas(C). Ačiū vyras!

Dėl techninių priežasčių, kai kurie raktiniai žodžiai buvo sąmoningai laikomi anglų kalba. Bandžiau užtikrinti teksto originalumą, bet aš prisipažįstu, kad man teko atlikti pakeitimus, siekiant palengvinti supratimą mūsų kalba (LT-US (LT-US)). Bet koks vertimo pakeitimas ar pasiūlymas yra sveikintinas.

Įvadas

Tai ne Rašyti mokymo, kaip naudoti Git. Jei to jums reikia, siūlau pažvelgti į Rankinis padaryti Git. Tai taip pat nėra mūsų tikslas parodyti, kaip tai padaryti programinės įrangos versijų, Šiuo atveju, Pamatyti Semantinis versija.

Čia pasiūlymas yra valdyti komandos bendradarbiavimą programinės įrangos versijų kūrimo. Jūs žinote, kai turite kelis programuotojus “Maišant” tame pačiame šaltinio kode? Tai svarbu siekiant paspartinti, bet jis gali sukelti daug galvos skausmo (sužalojimas ir perdaryti) jei nėra kontrolės. Neleisti vienam kūrėjui perrašyti kito darbo ir užtikrinti laipsnišką ir organizuotą plėtrą, sumažinti konfliktus ir valdyti programinės įrangos versijas, yra tai, kad mes naudojame Git ir Filialai tada.

Šakos modelis

Į šią pastabą aš pateikti plėtros modelį aš kai kurie iš mano projektų (tiek darbe, tiek privačiajame) apie, 1 Metų, ir tai buvo labai sėkminga. Tai buvo ilgą laiką aš norėjau parašyti apie tai, bet niekada rasti laiko, Šiol. I'm not going to talk about projekto detales, tik apie strategijas, Filialai ir valdymo Spaudai.

Šiame modelyje daugiausia dėmesio skiriama tik Git kaip įrankis, skirtas visų mūsų šaltinio kodo versijų versijai. (beje, jei jus domina Git, mūsų įmonė GitPrime, Naujieji Metai Suteikia, realiu laiku, some amazing data analytics for software engineering optimization kai nuostabi duomenų analizė programinės įrangos inžinerijos optimizavimas)

Kodėl git?

Dėl išsamių diskusijų privalumus ir trūkumus Git, palyginti su centralizuotai šaltinio kontrolės sistemos, Pamatyti į Interneto. Yra didžiulis “Karo” aplink, kad. Kaip kūrėjas, Norėčiau Git per visus kitus įrankius, kurie egzistuoja šiandien. Git neabejotinai pakeitė tai, kaip kūrėjai galvoja apie Suliejimo arba sukurkite Filialas. Aš esu iš klasikinio pasaulio CVS/subversion (CVS/subversion), Kur sujungimas/šakojimas tai ką jūs tiesiog padaryti laikas nuo laiko ir jis visada atrodo šiek tiek baisu (“Saugokitės konfliktų Suliejimo, jie įkando jus!”).

Jau su Git šie veiksmai [sujungimas/šakojimas] yra labai paprasta ir yra viena iš pagrindinių mūsų darbo rutinos dalių, Tiki. Pvz., į Knyga CSV / subversion, Šakojasi ir Sujungti pirmą kartą aptariami tik vėlesniuose skyriuose, (patyrusiems vartotojams), bet kuriuo metu knyga apie Git, tai matyti iš skyriaus 3 (Pagrindinio).

Dėl savo paprastumo ir pasikartojančio pobūdžio, Šakojasi ir Sujungti nebėra kažkas bijoti. Faktiškai, versijų valdymo įrankiai turėtų padėtiSuliejimo ir sukurti Filialas daugiau nei kas nors kitas.

Daugiau jokių kalbamų, eikime prie kūrimo modelio. Modelis I'm going to present here iš esmės yra ne kas kita kaip procedūrų rinkinys, kad kiekvienas komandos narys turi laikytis, kad būtų pasiektas valdomas programinės įrangos kūrimo procesas.

Decentralizuota, bet centralizuotas

Saugyklos konfigūracija, kurią naudojame, kuri labai gerai veikia su šiuo Šakojasi sudaro centrinė duomenų saugykla,. Atkreipkite dėmesį, kad ši saugykla yra tik “vartojamas kaip” Centrinė (nes Git yra DVCS [Paskirstytos versijų valdymo sistemos], IE, nėra nieko, kas būtų laikoma centrine saugykla techniniu lygmeniu,). Mes tai informuosime apie šią saugyklą kaip Kilmės, nes šis pavadinimas yra susipažinęs su visais Git vartotojai.

Kiekvienas kūrėjas Išsitraukia ir Verčia dėl to Kilmės. Bet už santykių push-pull traukimas centralizuotai [Kilmės], kiekvienas kūrėjas taip pat gali pasiimti [Traukti] kitų porų pakeitimus, kad sudarytų pakomandytus pogrupius. Pvz., tai gali būti naudinga dirbant kartu su dviem ar daugiau kūrėjų apie naują puikią funkciją, anksčiau siųsdami [Stūmimas] nebaigtas darbas, skirtas Kilmės. Pirmiau pateiktame paveikslėlyje, yra Alice ir Bob pakomitečių, Alisa ir Dovydas, ir Clair ir David.

Techniškai, tai reiškia, nieko daugiau, nei Alice apibrėžta nuotolinio Git pavadintas Bob, nukreipta į Bob saugyklą, ir atvirkščiai.

Pagrindinės šakos

Fone, šis kūrimo modelis yra gana įkvėptas esamų modelių ten. Centrinė saugykla turi du filialus, [Filialai] su begaliniu gyvenimu:

  • Meistras
  • Plėtoti

Į pagrindinis filialas į Kilmės turėtų būti susipažinę sieti su kiekvienu Git naudotoju. Lygiagretus su pagrindinis filialas, yra dar vienas Filialas Vadinamas Plėtoti.

Apsvarstyti kilmės/kapitonas kaip pagrindinė šaka, kurioje Galvos visada atspindi valstybės gamybai paruoštas [paruošta gamybai].

Apsvarstyti kilmės /plėtros kaip ir Filialas pagrindinis, kai pirminis kodas Galvos visada atspindi valstybę, kurioje naujausi plėtros pakeitimai bus pateikti kitame leidime. Kai kurie tai vadins “Filialas Integracijos”. Štai kur labiausiai sinister konstrukcijos atsitikti.

Kai šaltinio kodas filialas plėtoti pasiekia stabilų tašką ir yra pasirengęs būti išleistas [Išleistas], visi pakeitimai turi būti sujungti [Sulietų] atgal į pagrindinis filialas ir tada pažymėtos versijos numeriu [Išleidimo]. Kaip tai daroma išsamiai, bus aptarta vėliau.

Taigi, kiekvieną kartą, kai pakeitimai įtraukiami į [Sulietų] atgal į Meistras, generuojama nauja versija [Išleistas], pagal apibrėžimą. Mes stengiamės būti labai griežti apie tai, Taigi, Teoriškai, mes netgi galėtų naudoti scenarijų Kablys automatiškai kurti ir siųsti mūsų paraišką gamybos serveriams, kai yra Įsipareigoti į Meistras.

Pagalbiniai filialai

Šalia Filialai Pagrindinis, Meistras ir Plėtoti, mūsų kūrimo modelis naudoja įvairias Filialai paramą, skirtą padėti vienu metu plėtoti komandos narius, ką kas 1) leidžia lengvai sekti naujas funkcijas [Funkcijos], 2) ruošiasi pristatyti naują versiją [Išleidimo] ir 3) padeda greitai išspręsti gamybos triktis [Karštųjų pataisų]. Skirtingai nuo Filialai Pagrindinis, Šių Filialai turi trumpą gyvenimo trukmę, nes galiausiai jie bus pašalinti.

Įvairių tipų Filialai [Pagalbiniai] kad mes galime naudoti, Yra:

  • Funkcijų šakos
  • Išleidimo šakos
  • Karštųjų pataisų šakos

Kiekvienas iš šių Filialai turi konkretų tikslą ir yra saistomos griežtų taisyklių, taip kad, Filialai gali sukelti Filialas ir kad Filialai turi būti sulietas [Sulietų] jūsų tikslus. Pamatysime kiekvieną iš jų [Filialai] akimirksniu.

Techniniu požiūriu, Šių Filialai nelaikomi “Specialios”. Kiekvieno tipo Filialas yra suskirstyti pagal tai, kaip mes juos naudojame. Bet kokiu atveju, yra tiesiog paprasta Filialai iš senojo senojo Git.

Funkcijų šakos

[Savybės = funkcijos / funkcionalumas]

– Ar išsišakoti [Filialas] Iš:
Plėtoti
– Ji turėtų sulieti [Suliejimo] dar kartą:
Plėtoti
– konvencija dėl Europos Filialas:
Nieko, Išskyrus Meistras, Plėtoti, išleidimo*leidinyje**, Arba karštosios pataisos-*

Į funkcija filialai (arba kartais vadinamas temų šakos) naudojami naujoms funkcijoms / funkcijoms kurti būsimam ar būsimam leidimui. Kai pradedate kurti Funkcija, tikslinė versija, į kurią bus įtraukta ši funkcija, gali būti nežinoma tuo metu.

Esminio funkcija filialai yra tai, kad ji egzistuoja tol, kol Funkcija šiuo metu kuriama, tačiau galiausiai ji bus įtraukta į [Sulietų] atgal į Plėtoti (tikrai pridėti naują Funkcija į kitą Išleidimo) arba išmesti (nesėkmingos patirties atveju).

Funkcijų šakos paprastai egzistuoja tik saugykloje Plėtoti, ne Kilmės.

Funkcijų šakų kūrimas

$ git kasos -b plėtoti manofeature
# Switched to a new branch "myfeature"

Įtraukti gatavą funkciją į plėtros

Funkcijos baigtas gali būti sulietas[Sulietų] su filialas plėtoti tikrai įtraukti juos į kitą Išleidimo.

$ git kasos sukurti
# Perėjo į filialą "kurti"
$ git suliejimas --į-ff myfeature ff myfeature ff mano
# Naujinama ea1b82a.. 05:9557 esu
# (Pakeitimų suvestinė)
# $ git filialas -d myfeature
# Panaikinta šaka myfeature (buvo 05e9557).
$ git stumti kilmės sukurti

Vėliava –ne-ff sukelia suliejimą [Suliejimo] visada sukurkite naują objektą Įsipareigoti, nors suliejimas gali būti atliekamas su sukti pirmyn [Ff]. Tai neleidžia prarasti informacijos apie funkcija filialas, sugrupuojant visus Įsipareigoja kurie buvo įtraukti į Funkcija. Palyginti:

Pastaruoju atveju [iš pirmiau nurodyto skaičiaus], neįmanoma iš git istorijos matyti, kuri iš Įsipareigoja buvo įgyvendintos per 2014 m. Funkcija; jums reikės rankiniu būdu skaityti visus žurnalo pranešimus. Atstatykite Funkcija Visą (IE, grupė Įsipareigoja), tai tikras galvos skausmas paskutinėje situacijoje, o tai lengva padaryti, jei vėliava –ne-ff buvo naudojamas.

taip, tai sukurs dar keletą objektų, Įsipareigoja (Tuščias), tačiau pelnas yra daug didesnis nei.

Išleidimo šakos

[Išleidimas = išleidimas / pristatymas / versija]

– Ar išsišakoti [Filialas] Iš:
Plėtoti
– Ji turėtų sulieti [Suliejimo] dar kartą:
Plėtoti ir Meistras
– konvencija dėl Europos Filialas:
išleidimo*leidinyje**

Į filialai spaudai padėti parengti naują gamybos versiją [gamybos išleidimas]. Jie leidžia jums įdėti lašelių paskutinę minutę aš. be to, jie leidžia šiek tiek pataisyti Klaidas ir apibrėžti metaduomenys Fora Išleidimo (versijos numeris, komponavimo versijos datos, ir t.t.). Atlikdami visą šį darbą išleidimo šaka, į plėtoti filialą lieka švarus, kad gautų Funkcijos iš kito didelio Išleidimo [versija].

Svarbiausias momentas sukurti naują išleidimo šaka šakojasi iš Plėtoti yra tada, kai Plėtoti jau yra (Beveik) atsižvelgiant į norimą naujos Išleidimo [versija]. Visus Funkcijos kandidatus į Išleidimo turi būti įtraukti į [Suliejimo] Norėdami Plėtoti šiuo metu. kita vertus Funkcijos Siekiama Spaudai ateities sandoriai turėtų tikėtis kito Išleidimo [versija].

Tai tiesiai išleidimo šaka kad kitas Išleidimo gauna versijos numerį – ne anksčiau kaip. Iki to momento, į plėtoti filialą atspindėjo pokyčius, susijusius su “kitas leidimas” [kita versija], bet neaišku, ar tai “kita versija” galiausiai bus 0.3 arba 1.0, kol išleidimo šaka pradėti. Šis sprendimas priimamas išleidimo šaka ir yra vykdoma pagal projekto taisykles dėl versijų kūrimo [rodo, kad “Semantinis versija“].

Leidimo šakos kūrimas

Į filialai spaudai yra sukurti iš plėtoti filialą. Pvz., Tarkime, kad versija 1.1.5 yra dabartinė gamybos versija, ir mes turime daug Išleidimo Ateina. Padėtis, dėl kurios Plėtoti yra paruoštas “kita versija” [kitas leidimas] ir mes nusprendėme, kad tai taps 1.2 (vietoj to 1.1.6 arba 2.0). Taigi, mes išsišakoti ir duoti išleidimo šaka pavadinimas, atspindintis naujos versijos numerį:

$ git kasos -B leidimas-1.2 Plėtoti
# Switched to a new branch "release-1.2"
$ ./Guzas-Versija.Sh 1.2
# Failai sėkmingai modifikuoti, Iškilioji versija į 1.2.
$ git įsipareigoti -į -m "Bumped version number to 1.2"
# [išleidimo 1,2 74d9424] Iškilioji versijos numeris į 1.2
# 1 failai pakeisti, 1 Įterpimai(+), 1 Naikinimus(-)

Sukūrę naują Filialas ir prieiti prie jo, mes Iškilioji į versijos numerį. čia, bump-version.sh yra apvalkalo scenarijų, kuris pakeičia kai kuriuos failus iš darbinės kopijos, kad atspindėtų naują versiją. (Tai gali, žinoma, būti rankinis pakeitimas – esmė yra ta, kad kai kurie failai keičiasi.) Taigi, yra padaryta Įsipareigoti pakeistos versijos numerio.

Ši nauja Filialas gali egzistuoti ten tam tikrą laiką, tol, kol Išleidimo pradedamas visam laikui. Per šį laikotarpį, klaidų taisymai gali būti taikomi šiame Filialas (vietoj to, kad plėtoti filialą). Naujų ir didelių Funkcijos čia yra griežtai draudžiama. Jie turi būti sujungti [Sulietų] į Plėtoti ir, va taip, laukti kito didelio Išleidimo.

Išleidimo šakos užbaigimas

Kai sijungus išleidimo šaka yra pasirengusi tapti tikra versija, kai kurie veiksmai turi būti atliekami. Pirmosios, į išleidimo šaka suliejamas į Meistras (kadangi kiekvienas Įsipareigoti į Meistras yra nauja versija pagal apibrėžimą, Prisiminti). Tada, Šį Įsipareigoti į Meistras turėtų būti pažymėtos, kad ateityje būtų lengviau pateikti nuorodą į šią versijų istoriją. Galiausiai, pakeitimus, padarytus išleidimo šaka reikia sulieti [Sulietų] vėl Plėtoti, taip, kad Spaudai ateities taip pat yra šių klaidų.

Pirmieji du "Git" žingsniai:

$ git kasos meistras
# Perėjo į šaką "kapitonas"
$ git suliejimas --į-ff spaudai-1.2
# Rekursinis suliejimas.
# (Pakeitimų suvestinė)
$ git žyma -į 1.2

Į Išleidimo dabar yra užbaigtas ir pažymėtas būsimai nuorodai.

Pastaba: taip pat galite naudoti -s arba -u vėliavėles , kad pasirašytumėte žymą kriptografiškai.

Norėdami išsaugoti pakeitimus, atliktus išleidimo šaka, turime juos sugrąžinti į Plėtoti. Apie Git:

$ git kasos sukurti
# Perėjo į filialą "kurti"
$ git suliejimas --į-ff spaudai-1.2
# Rekursinis suliejimas.
# (Pakeitimų suvestinė)

Šis veiksmas gali sukelti suliejimo konfliktą (tikriausiai eiti, kai mes pakeisime versijos numerį). Jei taip,, nustatyti ir padaryti Įsipareigoti.

Dabar, kad mes tikrai padaryta, į išleidimo šaka galima pašalinti, nes mums jo nebereikės:

$ git filialas -d išleidimas-1.2
# Panaikintas filialas spaudai-1.2 (buvo ff452fe).

Karštųjų pataisų šakos

– Ar išsišakoti [Filialas] Iš:
Meistras
– Ji turėtų sulieti [Suliejimo] dar kartą:
Plėtoti ir Meistras
– konvencija dėl Europos Filialas:
karštosios pataisos-*

Į Karštųjų pataisų šakos yra labai panašūs į išleidimo filialai, nes jie taip pat skirti parengti naują gamybos versiją, nors neplanuota. Jie atsiranda dėl būtinybės veikti iš karto po nepageidaujamos gamybos versijos būsenos [naudojamas]. Kai gamybos versijoje įvyksta kritinė klaida, reikia nedelsiant, tada karštųjų pataisų šaka galima išvesti iš žymens, žyminčios esamą gamybos versiją pagrindinis filialas.

Esmė yra ta, kad komandos narių darbas (į plėtoti filialą) gali tęsti, o kažkas ruošiasi greitai nustatyti gamybos gedimo.

Karštųjų pataisų šakos kūrimas

Į karštųjų pataisų šakos yra sukurti iš pagrindinis filialas. Pvz., darant prielaidą, kad 1.2 yra dabartinė gamybos leidimo versija, kuri kelia problemų dėl rimtos klaidos. Pokyčiai Plėtoti palikti vis dar nestabili. Tada mes galime karštųjų pataisų šaka ir pradėkite spręsti problemą:

$ git kasos -b karštosios pataisos-1.2.1 Meistras
# Switched to a new branch "hotfix-1.2.1"
$ ./Guzas-Versija.Sh 1.2.1
# Failai sėkmingai modifikuoti, Iškilioji versija į 1.2.1.
$ git įsipareigoti -į -m "Bumped version number to 1.2.1"
# [karštųjų pataisų-1.2.1 41e61bb] Iškilioji versijos numeris į 1.2.1
# 1 failai pakeisti, 1 Įterpimai(+), 1 Naikinimus(-)

Nepamirškite pakeisti versijos numerio po šakojimo!

Tada, ištaisyti klaidą ir padaryti Įsipareigoti korekcijos vienoje ar keliose Įsipareigoti Atskiras.

$ git įsipareigoti -m "Fixed severe production problem"
# [karštųjų pataisų-1.2.1 abbe5d6] Ištaisyta sunki gamybos problema
# 5 failai pakeisti, 32 Įterpimai(+), 17 Naikinimus(-)

Baigiama karštųjų pataisų šaka

Baigę, į Bugfix turi būti sujungtas atgal į Meistras, tačiau ji taip pat turi būti vėl įtraukta į Plėtoti, siekiant užtikrinti, kad Bugfix taip pat yra įtrauktas į kitą versiją. Tai gana panašus į tai, kaip išleidimo filialai yra baigti.

Pirmosios, atnaujinti Meistras ir žyma Išleidimo [pažymėti vasarą]:

$ git kasos meistras
# Perėjo į šaką "kapitonas"
$ git suliejimas --į-karštoji pataisa ff-1.2.1
# Rekursinis suliejimas.
# (Pakeitimų suvestinė)
$ git žyma -į 1.2.1

Pastaba: taip pat galite naudoti -s arba -u vėliavėles , kad pasirašytumėte žymą kriptografiškai.

Tada, apima Bugfix į Plėtoti Taip pat:

$ git kasos sukurti
# Perėjo į filialą "kurti"
$ git suliejimas --į-karštoji pataisa ff-1.2.1
# Rekursinis suliejimas.
# (Pakeitimų suvestinė)

Vienintelė išimtis iš taisyklės čia yra tai, kad, kai yra išleidimo šaka vyksta, pokyčius, susijusius su Karštųjų pataisų reikia sujungti, kad būtų galima išleidimo šaka, , o ne Plėtoti. Sulieti Bugfix į išleidimo šaka sukels Bugfix susijungtas į Plėtoti Taip pat, kai išleidimo šaka baigtas. (Jei darbas Plėtoti nedelsiant reikalauja, kad Bugfix ir negalite laukti, kol išleidimo šaka baigtas, galite saugiai sujungti BugfixDeveolp (Netoliž Taip pat.)

Galiausiai, nuimkite Filialas Laikinas:

$ git filialas -karštosios pataisos d-1.2.1
# Panaikintas filialas karštųjų pataisų-1.2.1 (buvo abbe5d6).

Santrauka

Nors nėra nieko tikrai neeilinis apie šį šakojasi modelis, skelbimo pradžioje skaičius gali būti labai naudingas mūsų projektams. Tai rodo lengvai suprantamą psichikos modelį ir leidžia komandos nariams plėtoti bendrą supratimą apie Šakojasi ir Atleidžiantis.

Aukštos kokybės PDF versija skaičius yra pateikta originalaus posto dienoraštis: http://nvie.com/posts/a-successful-git-branching-model/ [arba toliau pateiktoje atsisiuntimo nuorodoje]. Eiti į priekį ir padėkite jį ant sienos gauti greitą nuorodą bet kuriuo metu.

Iš viso atitikimų: 8576

Komentuoti “Sėkmingas šakų modelis Git

  1. Deivson gimimo sakė:

    laba diena, Žinau, kad Git iš pradžių buvo sukurta Linux sistema, bet kai kalbame apie perkeliamumą, norėčiau žinoti, jei Git veikia Windows MSIS ir POSIX??

palik atsakymą

Į jūsų el. pašto adresas nebus skelbiamas. Būtini laukai yra pažymėti su *