Kerja berpasukan tanpa kekeliruan: memahami strategi percabangan dalam Git

pengenalan

Git telah menjadi standard industri de facto untuk sistem kawalan versi dalam pembangunan perisian. Anda harus terlebih dahulu membaca artikel saya tentang apa itu Git dan bagaimana untuk bermula. Adakah anda telah membacanya? Cemerlang, mari kita mulakan! Suka atau tidak, alat yang dicipta oleh Linus Tovalds ini tidak akan bersara. Jadi, masuk akal untuk bercakap tentang cara pasukan teragih bekerja dengan Git dan strategi percabangan yang harus mereka pilih untuk ini. Ini bukan soalan yang tidak penting. Apabila memasang pasukan pembangunan baharu yang tidak bekerjasama sebelum ini, strategi percabangan selalunya merupakan salah satu perkara pertama yang perlu diputuskan. Dan sesetengah orang akan berbuih mulut untuk membuktikan bahawa satu strategi adalah lebih baik daripada yang lain. Jadi, saya ingin menyampaikan kepada anda beberapa maklumat umum tentang mereka.

Adakah strategi cawangan perlu?

Mereka sememangnya perlu. Sangat perlu. Kerana jika pasukan tidak bersetuju dengan sesuatu, maka setiap ahli pasukan akan melakukan apa yang dia mahu:

• bekerja di mana-mana cawangan
• bergabung menjadi cabang-cabang lain yang sewenang-wenangnya
• memadam beberapa cawangan
• mencipta yang baru
• maka setiap ahli pasukan akan bertindak dalam aliran yang tidak terurus.

Itulah sebabnya kami mempunyai tiga strategi untuk dipertimbangkan di bawah. Mari pergi!

Aliran GitHub

Strategi percabangan ini, anehnya, lebih disukai di GitHub :) Ia disertakan dengan satu set peraturan :

1. Kod dalam cawangan induk tidak boleh dipecahkan. Ia sepatutnya bersedia untuk digunakan pada bila-bila masa. Iaitu, anda tidak boleh meletakkan kod di sana yang akan menghalang anda daripada membina projek dan mengerahkannya ke pelayan.
2. Apabila anda merancang untuk mengusahakan fungsi baharu, anda perlu mencipta cawangan ciri baharu berdasarkan cawangan induk dan memberikannya nama yang bermakna. Serahkan kod anda secara setempat dan kerap tolak perubahan anda ke cawangan yang sama dalam repositori jauh.
3. Buka permintaan tarik (anda boleh membaca tentang permintaan tarik di sini ) apabila anda fikir kerja itu sudah siap dan boleh digabungkan ke dalam cawangan induk (atau jika anda tidak pasti, tetapi ingin mendapatkan maklum balas tentang kerja yang dilakukan).
4. Selepas ciri baharu dalam permintaan tarik diluluskan, ia boleh digabungkan ke dalam cawangan induk.
5. Apabila perubahan digabungkan ke dalam cawangan induk, ia harus digunakan ke pelayan dengan segera.

Menurut Aliran GitHub, sebelum anda mula mengerjakan sesuatu yang baharu, sama ada pembaikan atau ciri baharu, anda perlu mencipta cawangan baharu berdasarkan induk dan memberikannya nama yang sesuai. Seterusnya, kerja pelaksanaan bermula. Anda harus sentiasa menyerahkan komitmen kepada pelayan jauh dengan nama yang sama. Apabila anda membuat kesimpulan bahawa semuanya sudah siap, anda perlu membuat permintaan tarik ke cawangan induk. Kemudian sekurang-kurangnya seorang, atau lebih baik lagi, dua orang harus melihat kod ini sebelum mengklik "Luluskan". Biasanya, ketua pasukan projek dan orang kedua pasti perlu melihat. Kemudian anda boleh melengkapkan permintaan tarik. Aliran GitHub juga terkenal kerana memacu penghantaran berterusan (CD) dalam projek. Ini kerana apabila perubahan masuk ke cawangan induk, ia harus digunakan ke pelayan dengan segera.

GitFlow

Strategi sebelumnya (GitHub Flow) tidak begitu rumit pada terasnya. Terdapat dua jenis cawangan: cawangan induk dan ciri. Tetapi GitFlow lebih serius. Sekurang-kurangnya, gambar di atas harus menjelaskannya :) Jadi bagaimana strategi ini berfungsi? Secara umum, GitFlow terdiri daripada dua cawangan berterusan dan beberapa jenis cawangan sementara. Dalam konteks Aliran GitHub, cawangan induk adalah berterusan dan yang lain adalah sementara. Cawangan yang berterusan

• tuan: Tiada siapa patut menyentuh atau menolak apa-apa ke cawangan ini. Dalam strategi ini, master mewakili versi stabil terkini, yang digunakan dalam pengeluaran (iaitu, pada pelayan sebenar)
• pembangunan: Cawangan pembangunan. Ia boleh menjadi tidak stabil.

Pembangunan berlaku menggunakan tiga cawangan sementara tambahan :

1. Cawangan ciri — untuk membangunkan fungsi baharu.
2. Cawangan keluaran — untuk persediaan untuk keluaran versi baharu projek.
3. Cawangan hotfix — untuk membetulkan pepijat yang ditemui dengan pantas oleh pengguna sebenar pada pelayan sebenar.

Cawangan ciri

Cawangan ciri dicipta oleh pembangun untuk fungsi baharu. Mereka harus sentiasa diwujudkan berdasarkan cabang pembangunan. Selepas menyelesaikan kerja pada fungsi baharu, anda perlu membuat permintaan tarik ke cawangan pembangunan. Jelas sekali, pasukan besar boleh mempunyai lebih daripada satu cabang ciri pada satu masa. Lihat sekali lagi pada gambar pada permulaan penerangan strategi GitFlow.

Melepaskan cawangan

Apabila set ciri baharu yang diperlukan sudah sedia dalam cawangan pembangunan, anda boleh bersedia untuk mengeluarkan versi baharu produk. Cawangan keluaran, yang dibuat berdasarkan cawangan pembangunan, akan membantu kami dengan ini. Apabila bekerja dengan cawangan keluaran, anda perlu mencari dan membetulkan semua pepijat. Sebarang perubahan baharu yang diperlukan untuk menstabilkan cawangan keluaran juga mesti digabungkan semula ke dalam cawangan pembangunan. Ini dilakukan demi menstabilkan cabang pembangunan juga. Apabila penguji mengatakan bahawa cawangan itu cukup stabil untuk keluaran baharu, ia digabungkan ke dalam cawangan induk. Kemudian teg, yang diberikan nombor versi, dibuat untuk komit ini. Untuk melihat contoh, lihat gambar pada permulaan strategi. Di sana anda akan melihat Tag 1.0— ini hanyalah teg yang menunjukkan versi 1.0 projek. Dan akhirnya, kami mempunyai cawangan hotfix.

Cawangan hotfix

Cawangan hotfix juga bertujuan untuk mengeluarkan versi baharu kepada cawangan induk. Satu-satunya perbezaan ialah keluaran tersebut tidak dirancang. Terdapat situasi apabila pepijat masuk ke dalam versi yang dikeluarkan dan ditemui dalam persekitaran pengeluaran. Ambil iOS: sebaik sahaja versi baharu dikeluarkan, anda serta-merta mendapat banyak kemas kini dengan pembetulan pepijat yang ditemui selepas keluaran. Sehubungan itu, kami perlu membetulkan pepijat dengan cepat dan mengeluarkan versi baharu. Dalam gambar kami, ini sepadan dengan versi 1.0.1. Ideanya ialah kerja pada fungsi baharu tidak perlu dihentikan apabila perlu untuk membetulkan pepijat pada pelayan sebenar (atau seperti yang kita katakan, "dalam prod" atau "dalam pengeluaran"). Cawangan hotfix harus dibuat daripada cawangan induk, kerana ia mewakili perkara yang sedang berjalan dalam pengeluaran. Sebaik sahaja pembetulan pepijat bersedia, ia digabungkan menjadi induk, dan teg baharu dibuat. Sama seperti menyediakan cawangan keluaran, cawangan hotfix juga harus menggabungkan pembetulannya semula ke dalam cawangan pembangunan.

Aliran kerja forking

Dalam aliran kerja forking, pembangunan melibatkan dua repositori:

1. Repositori asal, di mana semua perubahan akan digabungkan.
2. Repositori garpu. Ini ialah salinan repositori asal, dimiliki oleh pembangun lain yang ingin membuat perubahan kepada yang asal.

Kedengarannya agak ganjil setakat ini, bukan? Sesiapa sahaja yang telah menemui pembangunan sumber terbuka sudah biasa dengan pendekatan ini. Strategi ini memberikan kelebihan berikut: pembangunan boleh berlaku dalam repositori fork tanpa memberikan kebenaran untuk pembangunan bersama dalam cawangan asal. Sememangnya, pemilik repositori asal mempunyai hak untuk menolak perubahan yang dicadangkan. Atau untuk menerima dan menggabungkan mereka. Ini mudah untuk pemilik repositori asal dan pembangun yang ingin membantu mencipta produk. Sebagai contoh, anda boleh mencadangkan perubahan pada kernel Linux . Jika Linus memutuskan bahawa mereka masuk akal, perubahan akan ditambah (!!!).

Contoh aliran kerja forking

Aliran kerja forking digunakan pada GitHub apabila terdapat perpustakaan yang anda ingin gunakan. Ia mempunyai pepijat yang menghalang anda daripada menggunakannya sepenuhnya. Katakan anda menyelami masalah dengan cukup mendalam dan mengetahui penyelesaiannya. Menggunakan aliran kerja forking, anda boleh menyelesaikan masalah tanpa hak untuk bekerja dalam repositori asal perpustakaan. Untuk bermula, anda perlu memilih beberapa repositori, contohnya, Rangka Kerja Spring . Cari dan klik butang "Fork" di penjuru kanan sebelah atas: Ini akan mengambil sedikit masa. Kemudian salinan repositori asal akan muncul dalam akaun peribadi anda, yang akan menunjukkan bahawa ia adalah garpu:Kini anda boleh bekerja dengan repositori ini seperti biasa, menambahkan perubahan pada cawangan induk, dan apabila semuanya sudah sedia, anda boleh membuat permintaan tarik ke repositori asal. Untuk melakukan ini, klik butang Permintaan tarik baharu :

Strategi mana yang hendak dipilih

Git ialah alat yang fleksibel dan berkuasa yang membolehkan anda bekerja menggunakan pelbagai proses dan strategi. Tetapi lebih banyak pilihan yang anda ada, lebih sukar untuk menentukan strategi yang hendak dipilih. Adalah jelas bahawa tidak ada jawapan tunggal untuk semua orang. Semuanya bergantung kepada keadaan. Walau bagaimanapun, terdapat beberapa garis panduan yang boleh membantu dengan ini:

1. Sebaiknya pilih strategi yang paling mudah dahulu. Beralih kepada strategi yang lebih kompleks hanya apabila diperlukan.
2. Pertimbangkan strategi yang mempunyai sedikit jenis cawangan yang mungkin untuk pembangun.
3. Lihat kebaikan dan keburukan pelbagai strategi, dan kemudian pilih yang anda perlukan untuk projek anda.

Itu sahaja yang saya ingin katakan tentang strategi percabangan dalam Git. Terima kasih atas perhatian anda :) Ikuti saya di GitHub , tempat saya sering menyiarkan ciptaan saya yang melibatkan teknologi dan alatan berbeza yang saya gunakan dalam kerja saya.