Model cabang sing sukses ing Git

Ngerti carane nggunakake Git iku penting, lan iki kalebu njaga lingkungan pangembangan perangkat lunak kolaboratif sing bisa dikelola.

Kredit

Posting Iki minangka versi asli Portugis, ing basa Inggris, “Model cabang Cabang sing sukses“, sah diwenehi wewenang dening panganggit, Vincent Driessen. Matur suwun wong!

Kanggo alasan teknis, sawetara tembung kunci sengaja disimpen ing basa Inggris. Aku nyoba njamin orisinalitas teks kasebut, nanging aku ngakoni yen aku kudu nyetel supaya luwih gampang dingerteni nganggo basa kita. (PT-BR). Sembarang koreksi utawa saran kanggo ngapikake terjemahan dijaluk..

introduksi

Iki dudu tulisan Piwulang babagan cara nggunakake Git. yen iki sing sampeyan butuhake, Aku saranake ndeleng ing Manual do Git. Sampeyan uga dudu tujuan kanggo nuduhake sampeyan carane nggawe versi piranti lunak, ing kasus iki, dipikir Versi Semantik.

Ing kene proposal kanggo ngatur kolaborasi tim ing versi piranti lunak. Sampeyan ngerti yen duwe macem-macem programer “obah” ing kode sumber sing padha? Iki penting kanggo nyepetake pembangunan., nanging bisa ngasilake ngelu banget (karusakan lan rework) yen ora ana kendali. Kanggo nyegah pangembang supaya ora nimpa karya liyane lan njamin pangembangan sing progresif lan teratur, minimalake konflik lan ngatur versi piranti lunak, yaiku nggunakake Git lan pang-pang nerusake.

Model cabang

Ing postingan iki, aku nampilake model pangembangan sing digunakake ing sawetara proyek (ing papan kerja uga pribadi) near 1 taun kepungkur, lan iku wis sukses banget. Aku wis suwe kepengin nulis babagan iki, nanging aku ora nate nemokake wektu sing kasedhiya, nganti saiki. Aku ora bakal ngomong babagan rincian proyek, namung bab strategi saka pang-pang lan manajemen ngeculake.

Model segel iki khusus ora Git minangka alat kanggo versi kabeh kode sumber. (Miturut cara, yen sampeyan kasengsem karo Git, perusahaan kita GitPrime nyedhiyakake, nyata-wektu, sawetara analytics data sing apik banget kanggo optimalisasi rekayasa piranti lunak)

Kok git?

Kanggo diskusi lengkap babagan pro lan kontra Git dibandhingake karo sistem kontrol kode sumber terpusat, dipikir a web. ana sanget “perang” sak mubeng iku. Minangka pangembang, Aku luwih seneng Git tinimbang kabeh alat liyane sing kasedhiya saiki. Git mesthi bakal ngowahi cara pangembang babagan nggawe nyawiji utawa gawe a cabang. Aku teka saka jagad klasik CVS / Subversi, ngendi nyawiji / ngepang iku soko sampeyan mung nate ditindakake lan mesthi rada medeni (“Ati-ati saka konflik nyawiji, padha cokotan sampeyan!”).

Kanthi Git tumindak kasebut [nyawiji / ngepang] pancen gampang banget lan makili salah sawijining bagean utama saka rutinitas kerja., pracaya. contone, ora buku CSV / Subversi, ngepang e nyawiji kaping pisanan mung kalebu bab mengko wae. (kanggo pangguna majeng), nalika ing sembarang buku babagan Git, iki katon ing bab 3 (dhasar).

Minangka akibat saka kesederhanaan lan sifat repetitif, ngepang e nyawiji wis ora keweden maneh. Sejatine, alat kontrol versi kudu mbantu nindakakenyawiji lan nggawe cabang luwih saka liyane.

Dhiskusi cekap, ayo pindhah menyang model pangembangan. Model sing bakal dakkirim ing kene intine ora liya yaiku set tata cara sing kudu dituruti saben anggota tim supaya bisa proses pangembangan piranti lunak sing dikelola..

Desentralisasi, nanging terpusat

Konfigurasi repositori sing digunakake lan bisa digunakake kanthi model ngepang kalebu repositori tengah. Elinga yen repositori iki mung “dijupuk minangka” tengah (amarga Git minangka DVCS [Sistem Kontrol Versi sing Disebar], ing tembung liyane, ora ana repositori pusat ing level teknis). Kita bakal deleng gudang iki minangka asal usul, amarga jeneng iki kenal karo kabeh pangguna Git.

Saben pangembang nindakake narik e nyurung kanggo asal usul. Nanging ngluwihi sesambetan push-narik menyang terpusat [asal usul], saben pangembang uga bisa njupuk [narik] pangowahan pasangan liyane kanggo mbentuk subteam. contone, iki bisa migunani kanggo nggarap loro utawa luwih pangembang ing fitur anyar sing apik., sadurunge ngirim [meksa nindakake perkara] karya ing proses kanggo asal usul. Ing gambar ing ndhuwur, ana subteam Alice lan Bob, Alice lan David, e Clair lan David.

Teknis, iki ora ana artine nanging Alice wis netepake Git sing adoh jenenge Bob, nuduhake repositori Bob, lan kosok-balene.

Cabang utama

ing latar mburi, model pangembangan iki cukup inspirasi karo model sing ana ing kana.. Repositori pusat duwe loro cabang [pang-pang] utama kanthi urip tanpa wates:

  • juragan
  • ngrembaka

ing juragan cabang ing asal usul kudu kenal karo saben pangguna Git.. Paralel karo juragan cabang, ana liyane cabang diarani ngrembaka.

Kita nimbang asal / master minangka cabang utama ing endi kode sumber KEPALA tansah nggambarake negara siyap produksi [siyap kanggo produksi].

Kita nimbang asal / berkembang minangka cabang utama ing endi kode sumber saka KEPALA tansah nggambarake negara kanthi pangowahan pangembangan paling anyar sing bakal dikirim ing rilis sabanjure. Sawetara bakal nelpon “cabang integrasi”. Iki minangka konstruksi sing paling jahat.

Nalika kode sumber ing cabang berkembang tekan titik stabil lan siyap diluncurake [dirilis], kabeh pangowahan kudu digabung [gabung] bali menyang juragan cabang banjur ditandhani nganggo nomer versi [ngeculake]. Kepiye cara ngrampungake kanthi rinci, mengko bakal dirembug..

mulane, saben ganti diganti [gabung] bali menyang juragan, versi anyar digawe [dirilis], miturut definisi. Kita nyoba dadi ketat banget., banjur, miturut teoritis, kita malah bisa nggunakake skrip pancing saka Git kanggo nggawe lan push aplikasi kanthi otomatis menyang server produksi nalika ana nindakake ora juragan.

Cabang bantu

ing jejere pang-pang utama, juragan e ngrembaka, model pangembangan kita nggunakake macem-macem pang-pang dhukungan kanggo mbantu pangembangan simultan ing antarane anggota tim, apa 1) nggawe gampang nglacak fitur-fitur anyar [fitur], 2) siyap-siyap kanggo ngirim versi anyar [ngeculake] e 3) mbantu sampeyan kanthi cepet ndandani kegagalan produksi [ndandani]. Beda karo pang-pang utama, estes pang-pang duwe umur sing cendhak, amarga pungkasane bakal dicopot.

Macem-macem jinis pang-pang [pambantu] apa sing bisa digunakake, padha:

  • Cabang fitur
  • Ngeculake cabang
  • Cabang perbaikan terbaru

saben iki pang-pang duwe tujuan tartamtu lan kaiket karo aturan sing ketat., dadi, pang-pang bisa menehi munggah kanggo cabang iku sing pang-pang kudu digabung [gabung] kanggo target sampeyan. kita bakal ndeleng masing-masing [pang-pang] ing cepet.

Saka perspektif teknis, Sing pang-pang ora dianggep “khusus”. Saben jinis cabang dikategorikake karo cara nggunakake.. wekasanipun, mung prasaja pang-pang saka Git lawas sing apik.

Cabang fitur

[Fitur = fitur / fungsi]

– bisa cabang [cabang] saka:
ngrembaka
– kudu nyawiji [nyawiji] maneh ing:
ngrembaka
– konvensi penamaan saka cabang:
Opo wae, kajaba juragan, ngrembaka, ngeculake- *, utawa perbaikan terbaru- *

Sampeyan cabang fitur (utawa kadang diarani cabang topik) digunakake kanggo nggawe fitur / fungsi anyar kanggo rilis mbesuk utawa mbesuk. Nalika miwiti pangembangan a fitur, versi target sing bakal dilebokake fitur iki bisa uga durung dingerteni saiki..

intine a cabang fitur yaiku ana nalika fitur ana ing pembangunan, nanging pungkasane bakal digabung [gabung] bali menyang ngrembaka (temtunipun nambah anyar fitur Kanggo sabanjure ngeculake) utawa dibuwang (yen ana eksperimen sing gagal).

Cabang fitur biasane mung ana ing gudang ngrembaka, ora ing asal usul.

Nggawe cabang fitur

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

Nggabungake fitur rampung dadi berkembang

Fitur rampung bisa digabung[gabung] minangka a cabang berkembang kanggo nambah manawa ing sabanjure ngeculake.

$ git checkout berkembang
# Diowahi dadi cabang 'berkembang'
$ git gabung --ora-myfeature
# Nganyari ea1b82a..05e9557
# (Ringkesan pangowahan)
# $ git cabang -d myfeature
# Myfeature cabang (yaiku 05e9557).
$ git push asal berkembang

Gendera –ora-ff nyebabake gabung [nyawiji] tansah nggawe obyek anyar saka nindakake, sanajan gabungan bisa ditindakake kanthi a maju cepet [FF]. Iki ngalangi sampeyan kelangan informasi babagan sejarah eksistensi a cabang fitur, klompok kabeh nindakake sing ditambahake menyang fitur. Bandingake:

Ora kasus pungkasan [saka gambar ing ndhuwur], ora bisa dingerteni saka sejarah Git sing saka nindakake dileksanakake ing a fitur; sampeyan kudu maca kabeh pesen log kanthi manual. mbalikke siji fitur kabeh (ing tembung liyane, klompok saka nindakake), pancen lara sirah ing kahanan pungkasan, nalika gampang ditindakake yen gendera –ora-ff wis digunakake.

Sim, iki bakal nggawe sawetara obyek liyane saka nindakake (kosong), nanging bathi luwih gedhe tinimbang biaya.

Ngeculake cabang

[Rilis = rilis / pangiriman / versi]

– bisa cabang [cabang] saka:
ngrembaka
– kudu nyawiji [nyawiji] maneh ing:
ngrembaka e juragan
– konvensi penamaan saka cabang:
ngeculake- *

Sampeyan ngeculake cabang mbantu nyiyapake versi produksi anyar [rilis produksi]. Dheweke ngidini sampeyan nyelehake titik ing menit pungkasan. malih, padha ngidini koreksi cilik saka kewan omo lan definisi saka metadata kanggo ngeculake (nomer versi, tanggal gawe, etc). Kanthi nindakake kabeh karya kasebut dadi siji ngeculake cabang, ing berkembang cabang tetep resik kanggo nampa fitur saka amba sabanjure ngeculake [versi].

Wayahe utama kanggo nggawe sing anyar ngeculake cabang ngepang saka ngrembaka yaiku nalika ngrembaka wis ana (meh) nggambarake kahanan sing dikarepake anyar ngeculake [versi]. Kabeh fitur calon kanggo ngeculake kanggo dibangun kudu dilebokake [nyawiji] menyang ngrembaka saiki. wis ing fitur madhep ngeculake berjangka kudu ngenteni mbesuk ngeculake [versi].

Pancen ing wiwitan a ngeculake cabang sing sabanjure ngeculake nampa nomer versi – ora sadurunge. Nganti wektu iki, ing berkembang cabang pangowahan sing dibayangke kanggo “rilis sabanjure” [versi sabanjure], nanging ora jelas apa iki “versi sabanjure” bakal pungkasane dadi 0.3 utawa 1.0, nganti ing ngeculake cabang diwiwiti. Keputusan iki digawe ing wiwitan taun ngeculake cabang lan ditindakake dening aturan proyek babagan versi [Aku saranake kanggo ndeleng babagan “Versi Semantik“].

Nggawe cabang rilis

Sampeyan ngeculake cabang digawe saka berkembang cabang. contone, ayo ngomong versi 1.1.5 versi produksi saiki lan kita duwe versi gedhe ngeculake teka. Utawa negara saka ngrembaka wis siyap kanggo a “versi sabanjure” [rilis sabanjure] lan kita mutusake yen iki bakal dadi versi 1.2 (tinimbang 1.1.6 utawa 2.0). banjur, kita cabang lan menehi kanggo ngeculake cabang jeneng sing nuduhake nomer versi anyar:

$ checkout git -b ngeculake-1.2 ngrembaka
# Switched to a new branch "release-1.2"
$ ./nabrak-versi.sh 1.2
# File wis sukses diowahi, versi nabrak kanggo 1.2.
$ git nindakake -a -m "Bumped version number to 1.2"
# [ngeculake-1.2 74d9424] Nomer versi bumped menyang 1.2
# 1 file diganti, 1 sisipan(+), 1 pambusakan(-)

Sawise nggawe anyar cabang lan ngakses, kita entuk nomer versi. Ing kene, bunder-versi.sh minangka skrip shell sing ngowahi sawetara file ing salinan sing digunakake kanggo nggambarake versi anyar. (Iki bisa, langit, dadi pangowahan manual – intine yaiku sawetara file diganti.) banjur, wis rampung ing nindakake saka nomer versi sing wis diowahi.

anyar iki cabang bisa uga ana ing kana sawetara wektu, nganti ing ngeculake bakal dirilis tenan. Sajrone periode kasebut, perbaikan bug bisa ditrapake ing iki cabang (tinimbang ing berkembang cabang). Nambahake anyar lan apik fitur ing kene dilarang banget. dheweke kudu digabung [gabung] ing ngrembaka e, supaya, ngenteni amba sabanjure ngeculake.

Ngakhiri cabang rilis

Nalika ngeculake cabang siyap dadi versi nyata, sawetara tumindak kudu ditindakake. Kaping pisanan, ing ngeculake cabang digabung dadi juragan (sapisan saben nindakake ora juragan minangka versi anyar miturut definisi, elinga yen). Banjur, sing nindakake ora juragan kudu ditandhani kanggo nggampangake referensi riwayat sejarah mbesuk.. Pungkasane, pangowahan sing digawe ing ngeculake cabang kudu digabung [gabung] maneh kanggo ngrembaka, supaya ing ngeculake berjangka uga ngemot perbaikan bug kasebut..

Rong langkah pertama ing Git:

$ git checkout master
# Diowahi dadi 'master' cabang
$ git gabung --ora-rilis FF-1.2
# Gabung digawe kanthi rekursif.
# (Ringkesan pangowahan)
$ tag git -a 1.2

ing ngeculake saiki wis rampung lan ditandhani kanggo referensi mbesuk..

pengamatan: sampeyan uga bisa nggunakake gendera -s utawa -u kanggo menehi tandha kriptografi tag sampeyan.

Supaya pangowahan digawe ing ngeculake cabang, kita kudu nggabungake maneh ing ngrembaka. Ora Git:

$ git checkout berkembang
# Diowahi dadi cabang 'berkembang'
$ git gabung --ora-rilis FF-1.2
# Gabung digawe kanthi rekursif.
# (Ringkesan pangowahan)

Langkah iki bisa nyebabake konflik gabungan. (bisa uga lunga, awit kita ngowahi nomer versi). Ing kasus negesake, ndandani lan nindakake nindakake.

saiki, sing tenan rampung, ing ngeculake cabang bisa dicopot, awit kita ora butuh maneh:

$ cabang git -d ngeculake-1.2
# Rilis cabang-1.2 dihapus (ana ff452fe).

Cabang perbaikan terbaru

– bisa cabang [cabang] saka:
juragan
– kudu nyawiji [nyawiji] maneh ing:
ngrembaka e juragan
– konvensi penamaan saka cabang:
perbaikan terbaru- *

Sampeyan Cabang perbaikan terbaru padha banget karo ngeculake cabang, amarga uga dimaksudake kanggo nyiyapake versi produksi anyar, sanajan ora direncanakake. Dheweke tuwuh amarga kudu tumindak langsung sawise rilis produksi sing ora dikarepake. [Aku nggunakake]. Nalika ana kesalahan kritis ing rilis produksi, kudu dirampungake langsung, banjur a cabang perbaikan terbaru bisa dijupuk saka tag sing menehi tandha versi produksi sing ana ing cabang utama.

Intine yaiku kerja para anggota tim (ora berkembang cabang) terus wae, nalika wong liya nyiapake perbaikan cepet kanggo kegagalan produksi.

Nggawe cabang perbaikan terbaru

Sampeyan cabang perbaikan terbaru digawe saka cabang utama. contone, nganggep versi 1.2 minangka versi saiki rilis produksi sing mlaku lan duwe masalah amarga ana kesalahan serius. Pangowahan ing ngrembaka ninggalake sing isih ora stabil. Banjur kita bisa cabang a cabang perbaikan terbaru lan wiwiti ngrampungake masalah kasebut:

$ checkout git -b ndandani-1.2.1 juragan
# Switched to a new branch "hotfix-1.2.1"
$ ./nabrak-versi.sh 1.2.1
# File wis sukses diowahi, versi nabrak kanggo 1.2.1.
$ git nindakake -a -m "Bumped version number to 1.2.1"
# [perbaikan terbaru-1.2.1 41e61bb] Nomer versi bumped menyang 1.2.1
# 1 file diganti, 1 sisipan(+), 1 pambusakan(-)

Aja lali ganti nomer versi sawise cabang!

Banjur, mbenerake kesalahan lan tindakake nindakake koreksi ing siji utawa luwih nindakake pisah.

$ git nindakake -m "Fixed severe production problem"
# [perbaikan terbaru-1.2.1 abbe5d6] Ngatasi masalah produksi parah
# 5 file diganti, 32 sisipan(+), 17 pambusakan(-)

Ngakhiri cabang perbaikan terbaru

nalika rampung, ing bugfix kudu digabung maneh juragan, nanging uga kudu dipasang maneh menyang ngrembaka, supaya bisa mesthekake yen bugfix uga kalebu ing versi sabanjure.. Iki meh padha karo kepiye ngeculake cabang dirampungake.

Kaping pisanan, nganyari ing juragan e dina a ngeculake [tandhani musim panas]:

$ git checkout master
# Diowahi dadi 'master' cabang
$ git gabung --ora-perbaikan terbaru ff-1.2.1
# Gabung digawe kanthi rekursif.
# (Ringkesan pangowahan)
$ tag git -a 1.2.1

pengamatan: sampeyan uga bisa nggunakake gendera -s utawa -u kanggo menehi tandha kriptografi tag sampeyan.

Banjur, kalebu ing bugfix ora ngrembaka uga:

$ git checkout berkembang
# Diowahi dadi cabang 'berkembang'
$ git gabung --ora-perbaikan terbaru ff-1.2.1
# Gabung digawe kanthi rekursif.
# (Ringkesan pangowahan)

Mung istiméwa kanggo aturan ing kene yaiku, nalika ana siji ngeculake cabang Ing proses, pangowahan saka ndandani kudu digabung kanggo iki ngeculake cabang, tinimbang ngrembaka. nggabung ing bugfix ora ngeculake cabang bakal nyebabake bugfix bakal digabung dadi ngrembaka uga, nalika ing ngeculake cabang wis rampung. (Yen makarya ing ngrembaka langsung mbutuhake iki bugfix lan ora sabar nganti ngeculake cabang rampung, sampeyan bisa nggabung kanthi aman bugfix kanggo deveolp uga)

Pungkasane, mbusak ing cabang sauntara:

$ cabang git -d ndandani-1.2.1
# Perbaikan terbaru cabang-1.2.1 (ana abbe5d6).

Ringkesan

Sanajan ora ana sing luar biasa babagan model cabang iki, tokoh ing wiwitan Post bisa migunani banget ing proyek kita. Iki nuduhake model mental sing gampang dingerteni lan ngidini anggota tim nggawe pangerten umum babagan proses bisnis. ngepang e ngeculake.

Versi PDF gambar berkualitas tinggi diwenehake ing postingan blog asli.: http://nvie.com/posts/a-successful-git-branching-model/ [utawa ing link Download ing ngisor iki.]. Maju lan pasang ing tembok kanggo referensi cepet kapan wae.

Total accesses: 11021

A review ing “Model cabang sing sukses ing Git

  1. Deivson Birth ngandika:

    afternoon apik, Aku ngerti sing Git wiwitanipun dikembangaké kanggo Linux nanging yen ngomong bab portability, Aku wonder yen Git nganggo POSIX MSIS lan windows??

Ninggalake a Reply

Panjenengan alamat email ora bisa diterbitake. Perangkat kothak ditandhani karo *