Tiga pendekatan
Anda dapat menggunakan salah satu dari teknik populer ini, atau Anda dapat menggunakannya sebagai dasar untuk membuatnya sendiri.
Aliran GitHub . Strategi tersebut digunakan oleh tim layanan GitHub. Persyaratan utamanya adalah sebagai berikut:
- Tidak ada kesalahan dalam kode di cabang master, dan harus siap diterapkan kapan saja;
- untuk mulai mengembangkan fitur baru, Anda perlu membuat cabang fitur di cabang master dan memberinya nama yang jelas bagi semua orang. Saat pekerjaan siap, pekerjaan perlu digabungkan ke cabang master melalui permintaan tarik;
- setelah menggabungkan perubahan, Anda harus segera menerapkannya ke server.
Pendekatan ini biasanya digunakan untuk produk dengan versi tunggal yang tidak terlalu sering diperbarui. Misalnya, situs web. Sisi positifnya, pendekatan ini memudahkan pengembang untuk memahami dan mengatur pekerjaan mereka. Kerugian utamanya adalah jika proyek Anda cukup kompleks dan sering diperbarui, lebih baik menggunakan strategi yang berbeda.
GitFlow . Harus segera dikatakan bahwa strategi ini bisa diperdebatkan. Ada banyak ulasan positif dan negatif tentangnya.
Intinya adalah sebagai berikut. Ada dua jenis cabang persisten: cabang master, untuk memahami seperti apa versi terbaru saat ini, dan cabang pengembangan, tempat pengembangan berlangsung. Ada tiga jenis cabang sementara darinya.
- Fitur, untuk menambah fitur baru. Setelah menyelesaikan pekerjaan, Anda perlu membuat permintaan tarik di cabang pengembangan.
- Lepaskan untuk mengerjakan versi baru. Penting untuk menambahkan nomor versi ke judul, ini akan membantu Anda menghindari kebingungan dan melacak perubahan.
- Perbaikan terbaru, untuk perbaikan bug cepat.
Pendekatan ini dianggap salah satu yang terbaik untuk proyek di mana beberapa versi terus dikembangkan untuk platform yang berbeda.
Pada tahun 2010, teks programmer Belanda Vincent Driessen " Model percabangan Git yang sukses " diterbitkan, di mana dia pertama kali berbicara tentang GitFlow. Artikel tersebut menjadi sangat populer, terjemahan bahasa Rusia muncul , dan metode tersebut diadopsi oleh banyak tim.
Pada tahun 2020, programmer Amerika George Stoker menerbitkan artikel “ Tolong berhenti merekomendasikan Git Flow", Di mana dia mengkritik metode tersebut karena ketinggalan zaman dan tidak efektif dalam realitas modern. Driessen, sebagai tanggapan, melengkapi teks tahun 2010 dengan disclaimer, di mana ia mengakui bahwa metodenya bukanlah obat mujarab, tetapi hanya salah satu opsi untuk mengatur pekerjaan.
Alur Kerja Forking. Di sini pendekatannya adalah: ada repositori asli untuk menggabungkan semua perubahan dan salinannya, di mana pengembang lain bekerja. Pendekatannya sangat dekat dengan ideologi open source, tujuannya adalah untuk menggunakan semua keunggulan komunitas open-source dalam proyek tersebut. Namun, sebagian besar alur kerja percabangan menyalin GitFlow. Cabang fitur di sini akan bergabung dengan repositori pengembang lokal. Dengan demikian, pengembangan menjadi fleksibel bahkan untuk tim yang sangat besar dengan kontraktor.
Di antara mereka yang mengambil pendekatan ini adalah Linux . Anda dapat menawarkan opsi Anda sendiri untuk mengubah kode bahkan untuk inti sistem. Dan pendekatan ini tampaknya bekerja secara efektif.
Poin umum
Konsep apa pun yang Anda pilih, ada poin-poin dasar yang paling baik untuk dipegang. Misalnya, berikut adalah aturan Microsoft :
- jangan terlalu memperumit strategi cabang Anda;
- menggunakan cabang fitur untuk semua pembaruan dan perbaikan bug;
- menggabungkan cabang fitur menjadi cabang utama menggunakan permintaan tarik;
- Jaga kualitas upstream dan up-to-date.
Strategi yang didasarkan pada ide-ide ini akan mengarahkan tim Anda untuk bekerja dengan versi yang logis dan mudah dipahami.
Berikut beberapa pedoman yang lebih bermanfaat.
Sebut saja sederhana dan jelas
Ini akan membantu semua anggota tim memahami dengan benar siapa yang mengerjakan apa. Juga dapat diterima untuk memasukkan informasi tambahan atas nama cabang, misalnya, nama pembuatnya. Ini adalah kasus ketika Anda tidak perlu menghasilkan sesuatu yang orisinal. Nama cabang seperti "pengguna", "perbaikan bug", "fitur", "perbaikan terbaru" adalah yang Anda butuhkan. Untuk cabang yang tertunda, gunakan bendera khusus yang terpisah. Ini akan memungkinkan tim untuk segera memahami apa yang dipertaruhkan dan selalu mengingat tugas-tugas ini untuk jangka panjang.
Menggabungkan cabang hanya melalui permintaan tarik
Mekanisme permintaan tarik telah terbukti logis dan dipikirkan dengan baik. Karena proses ini membutuhkan waktu, Anda harus menyetujui di dalam tim apa dan dalam kerangka waktu apa yang diharapkan dari semua peserta dalam pull request. Tetapkan tanggung jawab peninjau dan bagikan dengan tim melalui basis pengetahuan internal.
Berikut beberapa tip khusus:
- menurut penelitian Microsoft , jumlah peninjau optimal adalah dua;
- jika tim Anda telah membentuk prinsip-prinsip tinjauan kode, patuhi dan cobalah untuk tidak melanggar;
- Permintaan tarik bekerja jauh lebih baik ketika lebih banyak anggota tim secara teratur ditagih untuk meninjau kode;
- Tinggalkan deskripsi pekerjaan Anda dengan cukup detail sehingga pengulas dapat dengan cepat memahami konteksnya.
Siapkan kebijakan cabang
Ada baiknya menghabiskan waktu untuk kebijakan bercabang karena beberapa alasan:
- dengan cara ini Anda dapat memisahkan pekerjaan saat ini dari pekerjaan yang sudah selesai di dalam cabang utama;
- membuat batasan yang wajar dengan menentukan siapa dan perubahan apa yang dapat dilakukan pada cabang tertentu;
- menyebarluaskan metode kerja yang efektif dengan cepat.
Ada dua aturan utama berdasarkan kebijakan mana yang harus dikonfigurasi:
- pengulas secara otomatis ditambahkan ke permintaan tarik pada saat pembuatannya. Pertama-tama Anda dapat menentukan daftarnya dan kemudian mengeditnya sambil jalan;
- build yang berhasil diperlukan untuk menyelesaikan permintaan penarikan. Kode yang dituangkan ke dalam cabang utama harus dibangun dengan rapi.
Tetapi prinsip yang paling penting saat membuat strategi cabang Anda adalah ini: Anda perlu memikirkannya lagi agar tim tidak memiliki pertanyaan tentang arti tindakan ini atau itu. Kemudian dalam proyek Anda setiap hari akan produktif.
Blog ITGLOBAL.COM - Managed IT, private cloud, IaaS, layanan keamanan informasi untuk bisnis: