Kerja tim tanpa kebingungan: ngerteni strategi cabang ing Git

Pambuka

Git wis dadi standar industri de facto kanggo sistem kontrol versi ing pangembangan piranti lunak. Sampeyan kudu maca artikelku babagan apa Git lan carane miwiti. Apa sampeyan wis maca? Banget, ayo padha lunga! Seneng utawa ora, alat sing digawe Linus Tovalds iki ora bakal pensiun. Dadi, masuk akal kanggo ngomong babagan cara tim sing disebarake karo Git lan strategi percabangan apa sing kudu dipilih kanggo iki. Iki ora pitakonan inconsequential. Nalika nglumpukake tim pangembangan anyar sing durung kerja bareng sadurunge, strategi cabang asring dadi salah sawijining perkara sing kudu diputusake. Lan sawetara wong bakal umpluk ing tutuk kanggo mbuktekaken sing siji strategi luwih apik tinimbang liyane. Dadi, aku pengin menehi sawetara informasi umum babagan dheweke.

Apa strategi cabang perlu?

Padha pancen perlu. Perlu banget. Amarga yen tim ora setuju, saben anggota tim bakal nindakake apa sing dikarepake:

• nyambut gawe ing cabang apa wae
• gabung dadi cabang liyane sing sewenang-wenang
• mbusak sawetara cabang
• nggawe anyar
• lan supaya saben anggota tim bakal tumindak ing aliran unmanaged.

Pramila kita duwe telung strategi sing kudu ditimbang ing ngisor iki. Ayo budal!

Alur GitHub

Strategi cabang iki, cukup aneh, luwih disenengi ing GitHub :) Dilengkapi karo sawetara aturan :

1. Kode ing cabang master ora kena rusak. Iku kudu siap kanggo disebarake ing sembarang wektu. Yaiku, sampeyan ora kudu nyelehake kode ing kana sing bakal nyegah sampeyan mbangun proyek kasebut lan nyebarake menyang server.
2. Yen sampeyan rencana nggarap fungsi anyar, sampeyan kudu nggawe cabang fitur anyar adhedhasar cabang master lan menehi jeneng sing migunani. Nggawe kode sampeyan sacara lokal lan ajeg push owah-owahan menyang cabang sing padha ing repositori remot.
3. Mbukak panjalukan narik (sampeyan bisa maca babagan panjalukan narik kene ) nalika sampeyan mikir karya wis siyap lan bisa digabung menyang cabang master (utawa yen sampeyan ora yakin, nanging pengin njaluk saran ing karya rampung).
4. Sawise fitur anyar ing panjalukan narik disetujoni, bisa digabung menyang cabang master.
5. Nalika owah-owahan digabungake menyang cabang master, kudu langsung dikirim menyang server.

Miturut GitHub Flow, sadurunge sampeyan miwiti nggarap sing anyar, dadi fix utawa fitur anyar, sampeyan kudu nggawe cabang anyar adhedhasar master lan menehi jeneng sing cocog. Sabanjure, karya ing implementasine diwiwiti. Sampeyan kudu terus ngirim komitmen menyang server remot kanthi jeneng sing padha. Nalika sampeyan nyimpulake yen kabeh wis siyap, sampeyan kudu nggawe panjalukan narik menyang cabang master. Banjur paling ora siji, utawa luwih apik, wong loro kudu ndeleng kode iki sadurunge ngeklik "Setuju". Biasane, pimpinan tim proyek lan wong liya kudu dideleng. Banjur sampeyan bisa ngrampungake panjalukan narik. GitHub Flow uga dikenal kanggo nyopir pangiriman terus-terusan (CD) ing proyek. Iki amarga nalika owah-owahan menyang cabang master, kudu langsung dikirim menyang server.

GitFlow

Strategi sadurunge (GitHub Flow) ora rumit banget ing inti. Ana rong jinis cabang: master lan fitur cabang. Nanging GitFlow luwih serius. Paling ora, gambar ing ndhuwur kudu jelas :) Dadi kepiye strategi iki? Umumé, GitFlow kasusun saka rong cabang persisten lan sawetara jinis cabang sementara. Ing konteks GitHub Flow, cabang master tetep lan liyane sementara. Cabang sing terus-terusan

• master: Ora ana sing kudu ndemek utawa push apa-apa menyang cabang iki. Ing strategi iki, master nggambarake versi stabil paling anyar, sing digunakake ing produksi (yaiku, ing server nyata)
• pembangunan: Cabang pembangunan. Bisa uga ora stabil.

Pangembangan ditindakake kanthi nggunakake telung cabang sementara tambahan :

1. Cabang fitur - kanggo ngembangake fungsi anyar.
2. Release cabang - kanggo nyiapake kanggo release saka versi anyar saka project.
3. Cabang hotfix - kanggo cepet ndandani bug sing ditemokake dening pangguna nyata ing server nyata.

Cabang fitur

Cabang fitur digawe dening pangembang kanggo fungsi anyar. Padha kudu tansah digawe adhedhasar cabang pembangunan. Sawise ngrampungake fungsi anyar, sampeyan kudu nggawe panjaluk tarik menyang cabang pangembangan. Cetha, tim gedhe bisa duwe luwih saka siji cabang fitur sekaligus. Deleng maneh gambar ing wiwitan deskripsi strategi GitFlow.

Ngeculake cabang

Nalika set fitur anyar sing dibutuhake wis siyap ing cabang pangembangan, sampeyan bisa nyiapake rilis versi anyar produk. Cabang rilis, sing digawe adhedhasar cabang pangembangan, bakal mbantu kita babagan iki. Nalika nggarap cabang rilis, sampeyan kudu nemokake lan ndandani kabeh kewan omo. Sembarang owah-owahan anyar sing dibutuhake kanggo nyetabilake cabang rilis uga kudu digabung maneh menyang cabang pangembangan. Iki ditindakake kanggo nyetabilake cabang pangembangan uga. Nalika panguji ujar manawa cabang kasebut cukup stabil kanggo rilis anyar, digabungake menyang cabang master. Mengko tag, sing diwenehi nomer versi, digawe kanggo komitmen iki. Kanggo ndeleng conto, katon ing gambar ing awal strategi. Ing kono sampeyan bakal weruh Tag 1.0- iki mung tag sing nuduhake versi 1.0 proyek. Lan pungkasane, kita duwe cabang hotfix.

Cabang hotfix

Cabang hotfix uga ditrapake kanggo ngeculake versi anyar menyang cabang master. Bentenipun mung sing rilis ora ngrancang. Ana kahanan nalika kewan omo mlebu ing versi sing dirilis lan ditemokake ing lingkungan produksi. Njupuk iOS: sanalika versi anyar dirilis, sampeyan langsung entuk akeh nganyari kanthi ndandani bug sing ditemokake sawise diluncurake. Mulane, kita kudu cepet ndandani bug lan ngeculake versi anyar. Ing gambar kita, iki cocog karo versi 1.0.1. Ing idea iku karya ing fungsi anyar ora kudu mandheg nalika iku perlu kanggo ndandani bug ing server nyata (utawa kita ngomong, "ing prod" utawa "ing produksi"). Cabang hotfix kudu digawe saka cabang master, amarga iku nuduhake apa sing lagi mlaku ing produksi. Sanalika ndandani bug wis siyap, digabung dadi master, lan tag anyar digawe. Kaya nyiapake cabang rilis, cabang hotfix uga kudu nggabungake fix maneh menyang cabang pangembangan.

Alur kerja forking

Ing alur kerja forking, pangembangan kalebu rong repositori:

1. Repositori asli, ing ngendi kabeh owah-owahan bakal digabung.
2. Repositori garpu. Iki minangka salinan repositori asli, diduweni dening pangembang liyane sing pengin nggawe owah-owahan menyang asline.

Swara rada aneh nganti saiki, bener? Sapa wae sing wis nemoni pangembangan open-source wis kenal karo pendekatan iki. Strategi iki menehi kauntungan ing ngisor iki: pangembangan bisa kedadeyan ing gudang garpu tanpa menehi ijin kanggo pangembangan bareng ing cabang asli. Mesthine, pemilik repositori asli duwe hak kanggo nolak owah-owahan sing diusulake. Utawa kanggo nampa lan nggabung. Iki trep kanggo pemilik repositori asli lan pangembang sing pengin mbantu nggawe produk kasebut. Contone, sampeyan bisa menehi saran pangowahan ing kernel Linux . Yen Linus mutusake dheweke nggawe akal, owah-owahan bakal ditambahake (!!!).

Tuladha alur kerja forking

Alur kerja forking ditrapake ing GitHub nalika ana perpustakaan sing pengin digunakake. Nduwe bug sing ngalangi sampeyan nggunakake kanthi lengkap. Upaminipun sampeyan nyilem cukup jero menyang masalah lan ngerti solusi. Nggunakake alur kerja forking, sampeyan bisa ndandani masalah kasebut tanpa hak kerja ing gudang asli perpustakaan. Kanggo miwiti, sampeyan kudu milih sawetara repositori, contone, Spring Framework . Golek lan klik tombol "Fork" ing pojok tengen ndhuwur: Iki bakal njupuk sawetara wektu. Banjur salinan repositori asli bakal katon ing akun pribadhi, sing bakal nuduhake manawa iku garpu:Saiki sampeyan bisa nggarap repositori iki kaya biasane, nambah owah-owahan ing cabang master, lan nalika kabeh wis siyap, sampeyan bisa nggawe panjalukan narik menyang gudang asli. Kanggo nindakake iki, klik tombol Panjaluk tarik anyar :

Strategi sing kudu dipilih

Git minangka alat sing fleksibel lan kuat sing ngidini sampeyan bisa nggunakake macem-macem proses lan strategi. Nanging luwih akeh pilihan sampeyan, luwih angel kanggo nemtokake strategi sing kudu dipilih. Cetha yen ora ana siji-sijine jawaban kanggo saben wong. Kabeh gumantung ing kahanan. Sing jarene, ana sawetara pedoman sing bisa mbantu iki:

1. Luwih becik milih strategi sing paling gampang dhisik. Pindhah menyang strategi sing luwih rumit mung yen perlu.
2. Coba strategi sing duwe sawetara jinis cabang sabisa kanggo pangembang.
3. Deleng ing Pros lan cons saka macem-macem Sastranegara, banjur pilih salah siji sing perlu kanggo project.

Iku kabeh sing dakkarepake babagan strategi cabang ing Git. Matur nuwun kanggo perhatian sampeyan :) Tindakake aku ing GitHub , ing ngendi aku kerep ngirim kreasiku sing nglibatake macem-macem teknologi lan alat sing digunakake ing karyaku.