Isang sangay ng matagumpay na modelo sa Git

Alamin kung paano gamitin Git ay mahalaga, at ito kabilang ang pagpapanatili ng isang collaborative na pag-unlad na kapaligiran na mapapamahalaan software.

credits

This Post ay isang Portuges na bersyon ng orihinal na, in English, “Ang isang matagumpay Git sumasanga modelo“, awtorisadong sa pamamagitan ng ang may-akda, Vincent Driessen. Salamat sa iyo ang tao!

Para sa mga teknikal na isyu, ang ilang mga keyword ay sadyang nag-iingat sa Ingles. Sinubukan kong upang matiyak ang pagka-orihinal ng teksto, ngunit aminin ko na ako had sa gumawa ng mga pagsasaayos upang mapadali ang pag-unawa sa ating wika (PT-BR). Ang anumang pagwawasto o mungkahi para sa pagpapabuti sa pagsasalin ay malugod.

pagpapakilala

Ito ay hindi isang post ng pagtuturo ang paggamit ng Git. Kung ito ay kung ano ang kailangang, Mungkahi ko na pagkuha ng isang pagtingin sa Manual do Git. At hindi rin ito ang aming layunin upang ipakita kung paano gumawa ng isang software versioning, sa kasong ito, tumingin semantiko pag-bersyon.

Narito ang mga mungkahi ay upang pamahalaan ang team collaboration software versioning. Alam mo kapag mayroon kang maramihang mga programmer “pagpapakilos” sa parehong source code? Ito ay mahalaga upang bilis ng pag-unlad, ngunit maaaring makabuo ng malaking sakit ng ulo (pagkawala at rework) kung walang control. Upang maiwasan ang isang developer mula sa patungan ng iba trabaho at matiyak ang progresibo at organisadong pag-unlad, pagliit ng conflicts at pamamahala ng software release, gumagamit kami Git at modelo sanga sundan.

Model sanga

Sa post na ito ipakita ko ang pag-unlad modelo ko na ginagamit sa ilan sa aking mga proyekto (parehong sa trabaho at pribadong) malapit 1 taon na ang nakakaraan, at ito ay lubhang matagumpay. Ang ilang oras nakaraan Nais kong magsulat tungkol sa mga ito, ngunit hindi natagpuan ng isang magagamit na oras, hanggang ngayon. Hindi ko makipag-usap tungkol sa mga detalye ng proyekto, lamang tungkol sa mga diskarte sanga at pamamahala release.

Ito seal hindi lamang model git bilang isang kasangkapan para sa versioning ng lahat ng aming source code. (hindi sinasadya, kung ikaw ay interesado sa Git, ang aming kumpanya gitpri na nagbibigay ito, real-time, ang ilang mga kamangha-manghang mga pagtatasa ng data sa software engineering optimization)

git na?

Para sa isang masusing talakayan ng mga kalamangan at kahinaan ng Git kumpara sa mga kontrol ng sentralisadong sistema ng source, tumingin isang web. May ay isang napakalaking “digmaan” paligid na. bilang isang developer, Mas gusto ko Git na may kaugnayan sa lahat ng iba pang mga umiiral na mga kasangkapan sa ngayon. Git walang pagsala binago ang paraan ng mga developer isipin ang tungkol sa paggawa ng isang merge o lumikha ng isang sangay. dumating ako mula sa klasikal na mundo CVS / pagbabagsak, saan merging / sumasanga Ito ay isang bagay na mo lamang gawin nang isang beses sa isang habang at ito lagi tila isang maliit na nakakatakot (“Mag-ingat sa mga salungatan ng merge, kumagat ka nila!”).

Ngayon Git mga pagkilos na ito [merging / sumasanga] Ang mga ito ay lubos na simple at kumakatawan sa isang malaking bahagi ng aming trabaho routine, maniwala. halimbawa, hindi libro CSV / pagbabagsak, sumasanga e pagsasama Sila ay sakop sa unang pagkakataon lamang sa mamaya chapters (para sa mga advanced na user), habang sa anumang libro sa Git, ito ay makikita sa kabanatang 3 (pangunahing).

Bilang isang resulta ng pagiging simple nito at paulit-ulit na likas na katangian, sumasanga e pagsasama Hindi na sila ng isang bagay upang matakot. sa katunayan, ang bersyon control kasangkapan ay dapat makatulong sa makemerge at lumikha ng sangay higit pa kaysa sa anumang bagay.

sapat talk, hayaan ang pag-unlad modelo. Ang mga modelo na ay kong ipakita dito ay mahalagang walang higit sa isang set ng mga pamamaraan na ang bawat kasapi ng koponan ay dapat sumunod sa pagkakasunud-sunod upang makakuha ng isang pinamamahalaang proseso ng pag-unlad ng software.

desentralisado, ngunit sentralisadong

Ang repository setup na ginagamit namin at na gumagana nang napakahusay sa modelong ito sumasanga Ito ay binubuo ng isang central repository. Tandaan na ang repository na ito ay lamang ng “isinasaalang-alang” sentral (dahil Git ay isang DVCS [Ipinamahagi Version Control Systems], sa ibang salita, walang anuman tulad ng isang central repository sa isang teknikal na antas). Susubukan naming sumangguni sa repository bilang pinagmulan, dahil ito pangalan ko ay pamilyar sa lahat ng mga gumagamit Git.

Ang bawat developer ay pulls e pushes sa pinagmulan. Ngunit sa kabila ng relasyon tulak hila para sa sentralisadong [pinagmulan], ang bawat developer ay maaari ring mahuli [mga pull] nagbabago para sa iba pang mga kapantay upang bumuo Subteams. halimbawa, ito ay maaaring maging kapaki-pakinabang sa trabaho na may dalawa o higit pang mga developer sa isang malaking bagong pag-andar, dati nang pagpapadala [patulak] ang trabaho sa pag-unlad para sa pinagmulan. Sa itaas, may mga sub-team nina Alice at Bob, Alice e David, e Clair at David.

technically, ito ay nangangahulugan walang higit pa kaysa Alice ay may tinukoy na isang remote Git na may pangalang Bob, na tumuturo sa repository ni Bob, at vice versa.

Ang pangunahing sanga

sa likod, Ang pag-unlad modelo ay lubos na inspirasyon sa pamamagitan ng mga umiiral na mga modelo lumitaw diyan. Ang sentral na taguan ay may dalawang sanga [sanga] na humahantong sa isang walang katapusang buhay:

  • panginoon
  • linangin

ang sangay master sa pinagmulan ay dapat na pamilyar sa bawat gumagamit Git. kahilera sangay master, mayroong isa pang sangay na tinatawag na linangin.

isaalang-alang namin pinagmulan / master bilang pangunahing sangay kung saan ang source HEAD laging sumasalamin sa isang estado produksyon-handa na [handa na para sa produksyon].

isaalang-alang namin pinagmulan / bumuo bilang ang sangay kung saan ang pangunahing pinagkukunan HEAD laging sumasalamin sa isang estado sa mga pinakabagong pag-unlad ng mga pagbabago sa maihahatid sa susunod na release. Ang ilang mga nais na tawag ito “sangay pagsasama-sama”. Dito pumapasok ang pinaka-malas constructions mangyayari.

Kapag ang source code sa sangay bumuo umabot ng isang matatag na punto at ay handa na upang Ilalabas [pinalaya], lahat ng mga pagbabago ay dapat na ipinagsama [daop] upang i-back ang sangay master at pagkatapos ay minarkahan ng isang numero ng bersyon [paglaya]. Paano ito ay tapos na sa detalye, ay tinalakay sa karagdagang.

kaya, sa bawat oras na ang mga pagbabago ay nakasama [daop] balik panginoon, Ito ay binuo ng isang bagong bersyon [pinalaya], sa pamamagitan ng kahulugan. Sinusubukan naming maging napaka-mahigpit na tungkol sa mga ito, pagkatapos, theoretically, Maaari mo ring gamitin ang isang script kawit Git upang awtomatikong lumikha at magpadala ang aming application sa produksyon server sa tuwing mayroong isang mangako hindi panginoon.

sangay auxiliary

sa tabi ng sanga pangunahin, panginoon e linangin, ang aming pag-unlad modelo ay gumagamit ng iba't-ibang sanga suportahan upang tulungan ang sabay-sabay na pag-unlad sa pagitan ng mga miyembro ng koponan, ano 1) pinapadali ang pagsubaybay ng mga bagong tampok [mga tampok], 2) naghahanda para sa paghahatid ng isang bagong bersyon [paglaya] e 3) Ito ay tumutulong upang mabilis na ayusin ang mga flaws sa produksyon [hotfix]. hindi katulad sanga pangunahin, estes sanga Ito ay may isang span maikling buhay, dahil ito ay sa wakas ay inalis.

Ang iba't ibang uri ng sanga [katulong] maaari naming gamitin, ang mga ito ay:

  • sanga Tampok
  • sangay ng Paglabas
  • hotfix sanga

Ang bawat isa sa mga sanga Ito ay may isang tiyak na layunin at ito ay nakasalalay sa pamamagitan ng mahigpit na mga alituntunin, kaya na, sanga kayang sangay at sanga Dapat sila ay ipinagsama [daop] ang kanilang mga target. Susubukan naming makita ang bawat [sanga] in awhile.

Mula sa isang teknikal na pananaw, iyon sanga Sila ay hindi itinuturing “espesyal”. Ang bawat uri ng sangay Ito ay ikinategorya sa pamamagitan ng kung paano namin ginagamit. sa huli, Ang mga ito ay simple lang sanga para sa Old Git.

sanga Tampok

[Mga Tampok = tampok / pag-andar]

– maaari sanga [sangay] mula sa:
linangin
– ito makisalamuha [merge] muli:
linangin
– Pagpapangalan convention ng sangay:
anumang bagay, maliban panginoon, linangin, release- *, o hotfix- *

ang sangay ng tampok (o kung minsan ay tinatawag topic sanga) Sila ay ginagamit upang bumuo ng mga bagong tampok / pag-andar para sa isang susunod na release o sa susunod na. Kapag simulan ang pagbuo ng isang tampok, ang target release na kung saan ang tampok ay inkorporada maaaring maayos ay hindi kilala sa puntong ito.

Ang kakanyahan ng isang sangay ng tampok ito ay umiiral habang tampok ay pagbuo ng, ngunit sa huli ay nakasama [daop] balik linangin (upang permanenteng idagdag ang mga bagong tampok ang susunod na paglaya) o itinapon (sa kaso ng isang hindi matagumpay na karanasan).

sanga Tampok karaniwang umiiral lamang sa repository linangin, hindi sa pinagmulan.

Ang paglikha ng isang tampok na sanga

$ git checkout -b MyFeature bumuo
# Switched to a new branch "myfeature"

Nagsasama ng isang natapos na tampok na ito sa Bumuo

Mga tampok tinatapos maaaring pagsamahin[daop] bilang sangay bumuo idagdag ang mga ito nang permanente sa susunod paglaya.

$ git checkout bumuo
# Nakalipat sa branch 'bumuo'
$ Pumunta merge --hindi-ff MyFeature
# Ina-update ang ea1b82a..05e9557
# (Buod ng mga pagbabago)
# $ git branch -d MyFeature
# Deleted branch MyFeature (ay 05e9557).
$ git push pinanggalingan bumuo

Ang isang bandila –walang-ff Ito ay nagiging sanhi ng pagsanib [merge] lumikha ng bagong bagay mangako, kahit na ang pagsasama ay maaaring gumanap na may isang fast-forward [ff]. Ito avoids hindi nawawala ang impormasyon tungkol sa kasaysayan ng pag-iral ng isang Ang tampok na sangay, pagpapangkat ng lahat commits Sila ay idinagdag sa tampok. ihambing:

Walang huli kaso [figure sa itaas], ito ay imposible upang makita mula sa Git kasaysayan alin sa commits Sila ay ipinatupad sa loob ng isang tampok; Gusto mong manu-manong basahin lahat ng mga mensahe ng log. pagtaliwas ng isang tampok buo (sa ibang salita, isang grupo commits), Ito ay isang tunay na sakit ng ulo sa mga huling sitwasyon, habang ito ay madaling gawin kung ang bandila –walang-ff Ito ay ginagamit.

Sim, Magbubunsod ito ng ilang higit pang mga bagay commits (alisan ng laman), ngunit ang pakinabang ay mas higit kaysa sa gastos.

sangay ng Paglabas

[Paglabas = release / delivery / release]

– maaari sanga [sangay] mula sa:
linangin
– ito makisalamuha [merge] muli:
linangin e panginoon
– Pagpapangalan convention ng sangay:
release- *

ang release sanga tulong sa paghahanda ng isang bagong bersyon ng produksyon [produksyon release]. Pinapayagan nila ang mong ilagay ang tuldok ang i ay huling minuto. higit sa rito, pinapayagan nila ang maliit na pagwawasto bugs at depinisyon ng meta-data para sa isang paglaya (numero ng bersyon, petsa ng compilation, etc). Sa pamamagitan ng paggawa ng lahat ng trabaho na ito sa isang release sangay, ang bumuo ng sangay Kini-clear upang makatanggap ng mga tampok ang susunod na malaking paglaya [bersyon].

Ang susi sandali upang lumikha ng isang bagong release sangay sumasanga ng linangin ay kapag ang linangin ito ay isa (halos) na sumasalamin sa bagong ninanais na estado paglaya [bersyon]. lahat mga tampok kandidato para sa paglaya upang mabuo ay dapat na inkorporada [merge] sa linangin ngayon. na mga tampok nakaharap release hinaharap dapat asahan sa susunod na paglaya [bersyon].

Ito ay lamang ang simula ng isang release sangay ang susunod na paglaya na natatanggap ng isang numero ng bersyon – hindi bago. hanggang sa sandaling iyon, ang bumuo ng sangay masasalamin ang mga pagbabago sa “susunod na release” [susunod na bersyon], ngunit ito ay hindi maliwanag kung ito “susunod na bersyon” sa huli ay magiging 0.3 o 1.0, hanggang sa release sangay pagsisimula. desisyon na ito ay kinuha sa simula ng release sangay at ito ay gaganapin sa pamamagitan ng ang mga patakaran ng proyekto sa versioning [Iminumungkahi ko makita ang tungkol sa “semantiko pag-bersyon“].

Ang paglikha ng isang sangay ng release

ang release sanga Ang mga ito ay ginawa mula sa bumuo ng sangay. halimbawa, sabihin na ang mga bersyon 1.1.5 ay ang kasalukuyang bersyon ng produksyon at magkaroon ng isang mahusay na paglaya pagdating. O status linangin Ito ay unang bahagi ng “susunod na bersyon” [susunod na release] at kami ay nagpasya na ito ay maging ang mga bersyon 1.2 (kapalit ng 1.1.6 o 2.0). pagkatapos, ramificamos sa amin at dalhin namin ang release sangay isang pangalan na sumasalamin sa bagong numero ng bersyon:

$ git checkout -b release-1.2 linangin
# Switched to a new branch "release-1.2"
$ ./paga-bersyon.sh 1.2
# File ay matagumpay na nabago, bersyon Uusog sa 1.2.
$ git gumawa -isang -m "Bumped version number to 1.2"
# [release-1.2 74d9424] Uusog numero ng bersyon sa 1.2
# 1 mga file ay nagbago, 1 insertions(+), 1 pagtanggal(-)

Matapos ang paglikha ng isang bagong sangay at ma-access ito, kami ay Uusog ang numero ng bersyon. dito, bump-version.sh Ito ay isang shell script na ang mga pagbabago sa ilang mga nagtatrabaho kopya ng mga file upang sumalamin sa bagong bersyon. (ito lata, malinaw, maging isang manwal na pagbabago – ang punto ay na baguhin ang ilang mga file.) pagkatapos, Ito ay ginawa mangako ng binagong numero ng bersyon.

ang bagong sangay maaaring hindi doon para sa isang habang, hanggang sa paglaya ay sa wakas ay inilabas. Sa panahong ito, aayos ng bug maaaring ilapat sa ito sangay (sa halip bumuo ng sangay). Ang karagdagan ng mga malalaking mga bagong mga tampok dito ay mahigpit na ipinagbabawal. Dapat sila ay ipinagsama [daop] sa linangin e, kaya, maghintay para sa susunod na malaking paglaya.

Tinatapos ang isang sangay release

kapag ang release sangay Ito ay handa na upang maging isang tunay na bersyon, ilang mga aksyon na kailangan upang maisagawa. una, ang release sangay Ito ay ipinagsama sa panginoon (dahil ang bawat isa mangako hindi panginoon Ito ay isang bagong bersyon sa pamamagitan ng kahulugan, tandaan). pagkatapos, na mangako hindi panginoon Dapat itong mamarkahan para sa madaling sanggunian sa hinaharap sa kasaysayan bersyong ito. sa wakas, nagbabago na ginawa sa release sangay Kailangan nilang i-merge [daop] muli upang linangin, kaya na release hinaharap ring maglaman ng mga pag-aayos ng bug.

Ang unang dalawang mga hakbang sa Git:

$ git checkout master
# Nakalipat sa branch 'master'
$ Pumunta merge --hindi-ff release-1.2
# Sumanib na ginawa ng recursive.
# (Buod ng mga pagbabago)
$ git tag -isang 1.2

ang paglaya Ito ay kumpleto na ngayon at naka-iskedyul para sa sanggunian sa hinaharap.

pangungusap: maaari mo ring gamitin ang mga flag -s o -u upang mag-sign ang iyong tag cryptographically.

Upang panatilihin ang mga pagbabago na ginawa sa release sangay, kailangan namin upang gumulong ito pabalik sa linangin. walang Git:

$ git checkout bumuo
# Nakalipat sa branch 'bumuo'
$ Pumunta merge --hindi-ff release-1.2
# Sumanib na ginawa ng recursive.
# (Buod ng mga pagbabago)

Ang hakbang na ito ay maaaring humantong sa isang pag-merge salungatan (marahil pumunta, sa sandaling baguhin namin ang numero ng bersyon). Kung gayon, pagkumpuni at make mangako.

ngayon, talagang kami ay natapos, ang release sangay Ito ay maaaring alisin, dahil hindi na namin ito kailangan:

$ git branch -d release-1.2
# Tinanggal branch release-1.2 (ay ff452fe).

hotfix sanga

– maaari sanga [sangay] mula sa:
panginoon
– ito makisalamuha [merge] muli:
linangin e panginoon
– Pagpapangalan convention ng sangay:
hotfix- *

ang hotfix sanga Ang mga ito ay halos kapareho sa release sanga, ang mga ito ay inilaan din upang maghanda ng isang bagong bersyon ng produksyon, bagaman hindi planadong. lumitaw ang mga ito mula sa ang pangangailangan na kumilos kaagad pagkatapos ng isang estado ng hindi ninanais ng produksyon bersyon [gamitin ko]. Kapag ang isang kritikal na error ay nangyayari sa isang bersyon ng produksyon, Ito ay dapat na direksiyon kaagad, pagkatapos ay ang isa hotfix branch maaaring nagmula sa tag na marks sa umiiral na bersyon ng produksyon sa master sangay.

Kakanyahan ay na ang gawain ng mga miyembro ng koponan (hindi bumuo ng sangay) maaaring magpatuloy, habang ang ibang tao ay naghahanda ng isang mabilis na pagwawasto ng kabiguan sa produksyon.

Paglikha ng hotfix branch

ang sangay hotfix Ang mga ito ay ginawa mula sa master sangay. halimbawa, ipagpalagay na ang mga bersyon 1.2 Ito ay ang kasalukuyang bersyon ng release ng produksyon tumatakbo at nagtatanghal problema dahil sa isang pangunahing error. pagbabago sa linangin hindi matatag pa rin leave. pagkatapos ay maaari naming magpalago ng isa hotfix branch at simulan upang malutas ang problema:

$ git checkout -b hotfix-1.2.1 panginoon
# Switched to a new branch "hotfix-1.2.1"
$ ./paga-bersyon.sh 1.2.1
# File ay matagumpay na nabago, bersyon Uusog sa 1.2.1.
$ git gumawa -isang -m "Bumped version number to 1.2.1"
# [hotfix-1.2.1 41e61bb] Uusog numero ng bersyon sa 1.2.1
# 1 mga file ay nagbago, 1 insertions(+), 1 pagtanggal(-)

Huwag kalimutan upang baguhin ang numero ng bersyon pagkatapos sumasanga!

pagkatapos, iwasto ang mga error at gawin ang mga mangako pagwawasto sa isa o higit mangako hiwalay.

$ git gumawa -m "Fixed severe production problem"
# [hotfix 1.2.1 abbe5d6] Nakatakdang malubhang problema production
# 5 mga file ay nagbago, 32 insertions(+), 17 pagtanggal(-)

Tinatapos ang pag-a hotfix branch

kapag nakumpleto, ang bugfix Kailangan mong maging merged balik panginoon, ngunit din na kailangan upang maging inkorporada sa likod linangin, upang matiyak na ang bugfix Ito ay kasama rin sa susunod na release. Ito ay lubos na katulad sa paraan ng release sanga sila ay tinatapos.

una, update panginoon e araw ng paglaya [suriin ang mga tag-init]:

$ git checkout master
# Nakalipat sa branch 'master'
$ Pumunta merge --hindi-ff hotfix-1.2.1
# Sumanib na ginawa ng recursive.
# (Buod ng mga pagbabago)
$ git tag -isang 1.2.1

pangungusap: maaari mo ring gamitin ang mga flag -s o -u upang mag-sign ang iyong tag cryptographically.

pagkatapos, isama ang bugfix hindi linangin din:

$ git checkout bumuo
# Nakalipat sa branch 'bumuo'
$ Pumunta merge --hindi-ff hotfix-1.2.1
# Sumanib na ginawa ng recursive.
# (Buod ng mga pagbabago)

Ang tanging kataliwasan sa patakaran dito ay, kapag may isang release sangay isinasagawa, ang mga pagbabago sa hotfix Kailangan nilang i-merge para sa release sangay, sa halip linangin. merge bugfix hindi release sangay ay magsasanhi sa bugfix ipinagsama sa linangin din, kapag ang release sangay Naganap. (Kung ang trabaho sa linangin ito ay nangangailangan ng agad na bugfix at hindi makapaghihintay hanggang sa release sangay ay nakumpleto, maaari mong ligtas na sumanib bugfix para sa deveolp masyadong.)

sa wakas, alisin ang sangay pansamantala:

$ git branch -d hotfix-1.2.1
# Tinanggal branch hotfix-1.2.1 (ay abbe5d6).

buod

Habang naroon ay wala talagang pambihirang sa modelong branch, ang pigura sa simula ng post ay maaaring maging lubhang kapaki-pakinabang sa aming mga proyekto. Ito ay nagpapakita ng isang simpleng modelo ng kaisipan upang maunawaan at nagbibigay-daan sa mga miyembro ng koponan upang bumuo ng isang karaniwang pang-unawa ng mga proseso sumasanga e ilalabas.

Ang isang PDF na bersyon ng mataas na kalidad na figure ay ibinigay sa orihinal na blog post: http://nvie.com/posts/a-successful-git-branching-model/ [o sa I-download ang link sa ibaba]. Sige at ilagay ito sa pader para sa mabilis na reference sa anumang oras.

Kabuuang accesses: 8863

Ang isang puna sa “Isang sangay ng matagumpay na modelo sa Git

  1. Deivson Kapanganakan sinabi:

    magandang hapon, Alam ko na Git ay una na binuo para sa Linux ngunit kapag pinag-uusapan portability, Siguro kung Git ay tumatakbo sa POSIX MSIs at bintana??

-Iwan Ng sagot

Ang iyong email address ay hindi nai-publish. Mga kinakailangang patlang ay minarkahan ng *