Kerja tim tanpa Kebingungan: Ngerteni Strategi Cabang ing Git

Pambuka

Git wis dadi standar industri de facto kanggo kontrol versi ing nggawe piranti lunak. Kanggo mangerteni apa git lan carane miwiti, pisanan maca artikel babagan iki. Apa sampeyan wis maca? Apik, ayo nerusake! Seneng ora, instrumen sing digawe Linus Towalds ora bakal pensiun. Mulane, iku ndadekake pangertèn kanggo pirembagan bab carane tim mbagekke ing git lan apa strategi cabang kanggo milih iki. Lan iki dudu pitakonan sing ora ana gunane. Asring, ing kahanan nalika tim pangembang anyar sing durung kolaborasi karo siji liyane, strategi cabang minangka salah sawijining perkara sing kudu diputusake. Lan bakal ana wong sing bakal umpluk ing tutuk kanggo mbuktekaken sing siji strategi luwih saka liyane. Mulane, aku pengin menehi informasi babagan apa sing umume.

Apa strategi cabang perlu?

Nanging dheweke dibutuhake, lan isih dibutuhake. Amarga yen sampeyan ora setuju karo apa wae ing tim kasebut, kabeh wong bakal nindakake apa sing dikarepake:

• kerja ing cabang sing dikarepake;
• gabung menyang cabang liyane sing dikarepake;
• mbusak sawetara cabang;
• nggawe anyar;
• lan liya-liyane-saben anggota tim ana ing aliran sing ora bisa dikontrol.

Mulane, ing ngisor iki ana telung strategi. Tindak!

Strategi Aliran GitHub

Strategi percabangan, ora preduli sepira aneh, luwih disenengi ing GitHub :) Dilampirake ana sawetara aturan sing kudu ditindakake:

1. Kode ing cabang master kudu unbroken lan siap kanggo disebarake ing sembarang wektu (yaiku, sampeyan ora bisa sijine kode ana sing bakal nyegah saka mbangun project lan deploying ing server).
2. Yen sampeyan rencana nggarap fungsi anyar, sampeyan kudu nggawe cabang anyar (cabang fitur) 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 Pull-Request (sampeyan bisa maca apa pull-request ing kene ) nalika ana perasaan sing jelas yen 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 wis disetujoni, bisa digabung menyang cabang master.
5. Nalika owah-owahan digabungake menyang cabang master, kudu langsung dikirim menyang server.

Miturut GitHub Flow, pranyata 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 wiwit implementasine. Sampeyan kudu terus-terusan push commits menyang server remot kanthi jeneng sing padha. Yen sampeyan ngerti yen kabeh wis siyap, sampeyan kudu nggawe panjaluk narik ing cabang master. Banjur paling ora siji, utawa luwih apik, wong loro kudu ndeleng kode iki lan klik Sarujuk. Biasane, pimpinan tim proyek lan wong liya kudu ndeleng, banjur sampeyan bisa ngrampungake panjaluk tarik. GitHub Flow uga dikenal kanggo nyopir Continuous Delivery (CD) ing sawijining proyek. Amarga nalika owah-owahan digawe ing cabang master, kudu langsung disebarake menyang server.

strategi GitFlow

Strategi sadurunge (GitHub Flow) sejatine ora rumit banget. Ana rong jinis cabang: master lan fitur cabang. Nanging GitFlow luwih serius. Paling ora saka gambar ing ndhuwur sampeyan bisa ngerti iki) Dadi, kepiye strategi iki? Umumé, GitFlow kasusun saka rong cabang permanen lan sawetara jinis cabang sementara (Ing konteks GitHub Flow, cabang master permanen lan liyane sementara). Cabang permanen:

• master: ora ana siji kudu ndemek cabang iki utawa push apa-apa ana. Ing strategi iki, master nampilake versi stabil paling anyar sing digunakake ing produksi (yaiku, ing server nyata);
• pembangunan minangka cabang kanggo pembangunan. Bisa uga ora stabil.

Pangembangan ditindakake kanthi nggunakake telung cabang sementara tambahan :

1. Cabang fitur - kanggo ngembangake fungsi anyar.
2. Cabang rilis - kanggo nyiapake rilis versi anyar proyek kasebut.
3. Cabang hotfix minangka solusi cepet kanggo cacat sing wis 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 narik ing cabang pangembangan. Cetha yen ing tim gedhe bisa uga ana luwih saka siji cabang fitur sekaligus. Sawise maneh, mbayar manungsa waé menyang gambar ing awal gambaran saka strategi GitFlow.

Ngeculake cabang

Nalika jumlah fitur anyar sing dibutuhake wis disiapake ing cabang pangembangan, sampeyan bisa nyiapake kanggo ngeculake versi anyar produk. Cabang rilis bakal mbantu kita babagan iki. kang digawe adhedhasar cabang pembangunan. Nalika nggarap cabang rilis, sampeyan kudu nemokake lan ndandani kabeh cacat. Sembarang owah-owahan anyar sing dibutuhake kanggo nyetabilake cabang rilis uga kudu digabung maneh menyang pembangunan. Iki ditindakake kanggo nyetabilake lan ngembangake cabang kasebut. Nalika panguji ujar manawa cabang kasebut cukup stabil kanggo rilis anyar, digabungake menyang cabang master. Sabanjure, tag digawe ing commit iki (tag: sampeyan bisa maca liyane babagan kene ), sing diwenehi nomer versi. Minangka conto, sampeyan bisa ndeleng gambar ing wiwitan strategi. Dadi, ana Tag 1.0 mung label sing nuduhake versi 1.0 proyek kasebut. Lan bab pungkasan iku hotfix cabang.

Cabang hotfix

Cabang hotfix uga dimaksudake kanggo ngeculake versi anyar ing master. Bentenipun mung sing release iki ora ngrancang. Ana kahanan nalika cacat tekan rilis lan wis ditemokake ing produksi. Contone, iOS: sanalika ngeculake versi anyar, sampeyan langsung entuk akeh nganyari kanthi ndandani cacat sing ditemokake sawise diluncurake. Ing babagan iki, perlu kanggo ndandani cacat kasebut kanthi cepet lan ngeculake versi anyar. Ing gambar kita iki cocog karo versi 1.0.1. Ing idea iku karya ing fungsi anyar bisa uga ora mandheg ing wektu nalika sampeyan kudu ndandani cacat ing server nyata (kaya kita ngomong, "ing produksi": maneh, salinan saka produksi tembung Inggris). Cabang hotfix kudu digawe saka cabang master, amarga iku nuduhake negara sing bisa digunakake ing produksi. Sanalika solusi kanggo cacat wis siyap, digabung dadi master, lan label anyar digawe. Kaya nyiapake cabang rilis, cabang hotfix kudu nggabungake solusi kasebut menyang cabang pangembangan.

Strategi Forking Workflow

Minangka bagéan saka strategi Forking Workflow, pangembangan ditindakake kanthi cara sing ana rong repositori:

1. Repositori asli ing ngendi kabeh owah-owahan bakal digabung.
2. Repositori garpu (iki salinan repositori asli sing diduweni pangembang liyane sing pengin ngganti asline).

Muni rada aneh nganti saiki, bener? Kanggo sing wis nemoni pangembangan open-source, pendekatan iki wis akrab. Strategi iki menehi kauntungan ing ngisor iki: pangembangan bisa ditindakake ing gudang garpu tanpa menehi hak kanggo pangembangan bareng ing asline. Mesthine, pemilik repositori asli duwe hak kanggo nolak owah-owahan sing diusulake. Utawa setuju lan matèni wong. Iki trep kanggo pemilik repositori asli lan pangembang sing pengin melu nggawe sawetara produk. Contone, sampeyan bisa ngusulake owah-owahan ing kernel Linux . Yen Linus mutusake dheweke nggawe akal, owah-owahan bakal ditambahake (!!!).

Contoh Alur Kerja Forking

Aliran Forking digunakake ing GitHub nalika ana perpustakaan sing pengin digunakake. Nduweni cacat sing ngalangi supaya ora bisa digunakake kanthi lengkap. Ayo dadi ngomong sampeyan wis delved cukup menyang masalah lan ngerti solusi. Nggunakake strategi The Forking Workflow, sampeyan bisa ngatasi masalah iki tanpa menehi hak kanggo bisa ing repositori perpustakaan asli. Kanggo miwiti, sampeyan kudu milih repositori, contone, inti Spring Framework .Temokake tombol Fork ing pojok tengen ndhuwur banjur klik: Iki bakal njupuk sawetara wektu, sawise salinan repositori asli iki bakal katon ing sampeyan. akun pribadi, kang bakal nuduhake yen iku garpu: Banjur sampeyan bisa karo gudang iki minangka biasanipun, nambah owah-owahan ing cabang master lan nalika kabeh wis siyap, nggawe Narik-Request kanggo 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, luwih angel kanggo mutusake strategi apa sing kudu dipilih saiki. Cetha, ora ana jawaban siji-ukuran-cocok-kabeh. Iku kabeh gumantung ing kahanan. Nanging, ana sawetara rekomendasi sing bisa mbantu:

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 pangembang sabisa.
3. Deleng pro lan kontra saka macem-macem strategi lan, miturut proyek kasebut, pilih sing bener.

Iku kabeh sing pengin dakkandhakake babagan strategi cabang ing git. Matur nuwun kanggo perhatian sampeyan :) Langganan akun GitHub , aku kerep ngirim karya ing kana ing macem-macem teknologi lan alat sing digunakake ing karyaku.

pranala migunani

• Aliran GitHub: cara paling apik kanggo nggunakake Git lan GitHub
• Tarik panjalukan ing GitHub utawa Kepiye carane bisa ngganti proyek wong liya
• GitHub: Babagan Pull-Requests
• Integrasi, Pangiriman, lan Penyebaran sing Dibedakake
• Dasar Git: Nggarap Tag
• Habr: Model percabangan sing sukses kanggo Git