Kerja berpasukan tanpa Kekeliruan: Memahami Strategi Cawangan dalam Git

pengenalan

Git telah menjadi standard industri de facto untuk kawalan versi dalam penciptaan perisian. Untuk mengetahui tentang apa itu git dan bagaimana untuk bermula, mula-mula baca artikel saya mengenainya. Adakah anda telah membacanya? Hebat, mari teruskan! Suka atau tidak, instrumen yang dicipta oleh Linus Towalds tidak akan bersara. Oleh itu, masuk akal untuk bercakap tentang cara pasukan teragih berfungsi dalam git dan strategi percabangan yang perlu dipilih untuk ini. Dan ini bukan soalan terbiar sama sekali. Selalunya, dalam situasi di mana pasukan pembangun baharu yang belum bekerjasama antara satu sama lain dipasang, strategi percabangan adalah salah satu perkara pertama yang perlu diputuskan. Dan akan ada orang yang akan berbuih mulut untuk membuktikan bahawa satu strategi lebih baik daripada yang lain. Oleh itu, saya ingin menyampaikan kepada anda maklumat tentang mereka secara amnya.

Adakah strategi cawangan perlu?

Tetapi mereka diperlukan, dan mereka masih diperlukan. Kerana jika anda tidak bersetuju dengan sesuatu dalam pasukan, ternyata semua orang akan melakukan apa yang mereka mahu:

• bekerja di cawangan yang dia mahu;
• bergabung ke cawangan lain yang dia mahu;
• padam beberapa cawangan;
• buat yang baru;
• dan seterusnya—setiap ahli pasukan berada dalam aliran yang tidak terkawal.

Oleh itu, di bawah adalah tiga strategi. Pergi!

Strategi Aliran GitHub

Strategi percabangan, tidak kira betapa peliknya, lebih disukai dalam GitHub :) Dilampirkan padanya ialah satu set peraturan yang perlu dipatuhi:

1. Kod dalam cawangan induk mestilah tidak terputus dan sedia untuk digunakan pada bila-bila masa (iaitu, anda tidak boleh meletakkan kod di sana yang akan menghalang anda daripada membina projek dan menggunakannya pada pelayan).
2. Apabila anda merancang untuk mengusahakan fungsi baharu, anda perlu mencipta cawangan baharu (cawangan ciri) 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 permintaan tarik di sini ) apabila terdapat perasaan yang jelas bahawa kerja itu sudah siap dan boleh digabungkan ke dalam cabang induk (atau jika anda tidak pasti, tetapi ingin mendapatkan maklum balas tentang kerja yang dilakukan).
4. Selepas ciri baharu dalam permintaan tarik telah diluluskan, ia boleh digabungkan ke dalam cawangan induk.
5. Apabila perubahan digabungkan ke dalam cawangan induk, ia perlu digunakan ke pelayan dengan segera.

Menurut Aliran GitHub, ternyata 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 bermula pada pelaksanaan. Anda perlu sentiasa menolak komit ke pelayan jauh dengan nama yang sama. Apabila anda memahami bahawa semuanya sudah sedia, anda perlu membuat permintaan tarik dalam cawangan induk. Kemudian sekurang-kurangnya seorang, atau lebih baik lagi, dua orang harus melihat kod ini dan klik Luluskan. Biasanya, ketua pasukan projek dan orang lain mesti melihatnya, dan kemudian anda boleh melengkapkan permintaan tarik. Aliran GitHub juga terkenal kerana memacu Penghantaran Berterusan (CD) pada projek. Kerana apabila perubahan dibuat pada cawangan induk, ia mesti segera digunakan ke pelayan.

Strategi GitFlow

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

• tuan: tiada siapa yang harus menyentuh cawangan ini atau menolak apa-apa ke sana. Dalam strategi ini, induk memaparkan versi stabil terkini yang digunakan dalam pengeluaran (iaitu, pada pelayan sebenar);
• pembangunan adalah cabang untuk pembangunan. Ia berkemungkinan tidak stabil.

Pembangunan dijalankan menggunakan tiga cawangan sementara tambahan :

1. Cawangan ciri - untuk membangunkan fungsi baharu.
2. Cawangan keluaran - untuk bersedia untuk keluaran versi baharu projek.
3. Cawangan hotfix ialah penyelesaian pantas kepada kecacatan yang telah ditemui oleh pengguna sebenar pada pelayan sebenar.

Cawangan ciri

Cawangan ciri dicipta oleh pembangun untuk fungsi baharu. Mereka harus sentiasa berdasarkan cabang pembangunan. Selepas menyelesaikan kerja pada fungsi baharu, anda perlu membuat permintaan tarik dalam cawangan pembangunan. Adalah jelas bahawa dalam pasukan besar boleh terdapat lebih daripada satu cabang ciri pada satu masa. Sekali lagi, perhatikan gambar pada permulaan penerangan strategi GitFlow.

Melepaskan cawangan

Apabila bilangan ciri baharu yang diperlukan disediakan dalam cawangan pembangunan, anda boleh bersedia untuk mengeluarkan versi baharu produk. Cawangan pelepasan akan membantu kami dengan ini. yang diwujudkan berdasarkan cabang pembangunan. Semasa bekerja dengan cawangan pelepasan, anda perlu mencari dan membetulkan semua kecacatan. Sebarang perubahan baharu yang diperlukan untuk menstabilkan cawangan keluaran juga mesti digabungkan semula ke dalam pembangunan. Ini dilakukan untuk menstabilkan dan membangunkan cawangan. Apabila penguji mengatakan bahawa cawangan itu cukup stabil untuk keluaran baharu, ia digabungkan ke dalam cawangan induk. Seterusnya, teg dibuat pada komit ini (tag: anda boleh membaca lebih lanjut mengenainya di sini ), yang diberikan nombor versi. Sebagai contoh, anda boleh melihat gambar pada permulaan strategi. Jadi, terdapat Tag 1.0 hanyalah label yang menunjukkan versi 1.0 projek. Dan perkara terakhir ialah hotfix cawangan.

Cawangan hotfix

Cawangan hotfix juga bertujuan untuk mengeluarkan versi baharu dalam master. Satu-satunya perbezaan ialah keluaran ini tidak dirancang. Terdapat situasi apabila kecacatan mencapai pelepasan dan sudah ditemui dalam pengeluaran. Contohnya, iOS: sebaik sahaja mereka mengeluarkan versi baharu, anda serta-merta mendapat banyak kemas kini dengan pembetulan kecacatan yang ditemui selepas keluaran. Dalam hal ini, adalah perlu untuk membetulkan kecacatan ini dengan cepat dan mengeluarkan versi baharu. Dalam gambar kami ini sepadan dengan versi 1.0.1. Ideanya ialah kerja pada fungsi baharu mungkin tidak berhenti pada saat anda perlu membetulkan kecacatan pada pelayan sebenar (seperti yang kita katakan, "dalam pengeluaran": sekali lagi, salinan pengeluaran perkataan Inggeris). Cawangan hotfix harus dibuat daripada cawangan induk, kerana ia mewakili keadaan yang berfungsi dalam pengeluaran. Sebaik sahaja penyelesaian kepada kecacatan itu sedia, ia digabungkan menjadi induk, dan label baharu dibuat. Sama seperti menyediakan cawangan keluaran, cawangan hotfix harus menggabungkan penyelesaiannya ke dalam cawangan pembangunan.

Strategi Aliran Kerja Forking

Sebagai sebahagian daripada strategi Aliran Kerja Forking, pembangunan dijalankan sedemikian rupa sehingga terdapat dua repositori:

1. Repositori asal di mana semua perubahan akan digabungkan.
2. Repositori fork (ini ialah salinan repositori asal yang dimiliki oleh pembangun lain yang ingin membuat perubahan kepada yang asal).

Bunyi agak pelik setakat ini, bukan? Bagi mereka yang telah menemui pembangunan sumber terbuka, pendekatan ini sudah biasa. Strategi ini memberikan kelebihan berikut: pembangunan boleh dijalankan dalam repositori garpu tanpa memberikan hak untuk pembangunan bersama dalam yang asal. Sudah tentu, pemilik repositori asal mempunyai hak untuk menolak perubahan yang dicadangkan. Atau bersetuju dan membunuh mereka. Ini sesuai untuk pemilik repositori asal dan pembangun yang ingin mengambil bahagian dalam penciptaan beberapa 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 Forking digunakan pada GitHub apabila terdapat beberapa perpustakaan yang anda ingin gunakan. Ia mempunyai kecacatan yang menghalangnya daripada digunakan sepenuhnya. Katakan anda telah cukup mendalami masalah tersebut dan mengetahui penyelesaiannya. Menggunakan strategi The Forking Workflow, anda boleh menyelesaikan masalah ini tanpa memberikan hak untuk bekerja dalam repositori perpustakaan asal. Untuk bermula, anda perlu memilih repositori, contohnya, teras Spring Framework . Cari butang Fork di penjuru kanan sebelah atas dan klik padanya: Ini akan mengambil sedikit masa, selepas itu salinan repositori asal ini akan muncul dalam anda akaun peribadi, yang akan menunjukkan bahawa ia adalah garpu: Kemudian anda boleh bekerja dengan repositori ini seperti biasa, tambahkan perubahan pada cawangan induk dan apabila semuanya sudah sedia, buat 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 semakin besar pilihan, semakin sukar untuk memutuskan strategi mana yang hendak dipilih sekarang. Jelas sekali, tiada jawapan yang sesuai untuk semua. Semuanya bergantung kepada keadaan. Walau bagaimanapun, terdapat beberapa cadangan yang boleh membantu dengan ini:

1. Adalah lebih baik untuk memilih strategi yang paling mudah dahulu. Beralih kepada strategi yang lebih kompleks hanya apabila perlu.
2. Pertimbangkan strategi yang mempunyai sedikit jenis cawangan pembangun yang mungkin.
3. Lihat kebaikan dan keburukan strategi yang berbeza dan, mengikut projek, pilih yang betul.

Itu sahaja yang saya ingin beritahu anda tentang strategi percabangan dalam git. Terima kasih atas perhatian anda :) Langgan akaun GitHub saya , saya sering menyiarkan kerja saya di sana dalam pelbagai teknologi dan alatan yang saya gunakan dalam kerja saya

pautan yang berguna

• Aliran GitHub: cara terbaik untuk menggunakan Git dan GitHub
• Tarik permintaan pada GitHub atau Bagaimana saya boleh membuat perubahan pada projek orang lain
• GitHub: Perihal Permintaan Tarik
• Penyepaduan Berterusan, Penyampaian dan Penerapan Dibezakan
• Asas Git: Bekerja dengan Teg
• Habr: Model percabangan yang berjaya untuk Git