Mengadopsi strategi percabangan Git

Layanan Azure DevOps | Azure DevOps Server 2022 - Azure DevOps Server 2019

Sistem kontrol versi terdistribusi seperti Git memberi Anda fleksibilitas dalam cara Anda menggunakan kontrol versi untuk berbagi dan mengelola kode. Tim Anda harus menemukan keseimbangan antara fleksibilitas ini dan kebutuhan untuk berkolaborasi dan berbagi kode secara konsisten.

Anggota tim menerbitkan, berbagi, meninjau, dan melakukan iterasi pada perubahan kode melalui cabang Git yang dibagikan dengan orang lain. Mengadopsi strategi percabangan untuk tim Anda. Anda dapat berkolaborasi dengan lebih baik dan menghabiskan lebih sedikit waktu untuk mengelola kontrol versi dan lebih banyak waktu untuk mengembangkan kode.

Strategi percabangan berikut didasarkan pada cara kami menggunakan Git di sini di Microsoft. Untuk informasi selengkapnya, lihat Cara menggunakan Git di Microsoft.

Jaga agar strategi cabang Anda tetap sederhana

Jaga agar strategi cabang Anda tetap sederhana. Bangun strategi Anda dari ketiga konsep ini:

• Menggunakan cabang fitur untuk semua fitur baru dan perbaikan bug.
• Gabungkan cabang fitur ke cabang utama menggunakan permintaan pull.
• Pertahankan cabang utama berkualitas tinggi dan terbaru.

Strategi yang memperluas konsep ini dan menghindari kontradiksi akan menghasilkan alur kerja kontrol versi untuk tim Anda yang konsisten dan mudah diikuti.

Menggunakan cabang fitur untuk pekerjaan Anda

Kembangkan fitur Anda dan perbaiki bug di cabang fitur berdasarkan cabang utama Anda. Cabang-cabang ini juga dikenal sebagai cabang topik. Cabang fitur mengisolasi pekerjaan yang sedang berlangsung dari pekerjaan yang selesai di cabang utama. Cabang Git murah untuk dibuat dan dirawat. Bahkan perbaikan dan perubahan kecil harus memiliki cabang fitur mereka sendiri.

Membuat cabang fitur untuk semua perubahan Anda membuat riwayat peninjauan menjadi sederhana. Lihatlah penerapan yang dibuat di cabang dan lihat permintaan pull yang menggabungkan cabang.

Beri nama cabang fitur Anda menurut konvensi

Gunakan konvensi penamaan yang konsisten untuk cabang fitur Anda untuk mengidentifikasi pekerjaan yang dilakukan di cabang. Anda juga dapat menyertakan informasi lain dalam nama cabang, seperti siapa yang membuat cabang.

Beberapa saran untuk menamai cabang fitur Anda:

• pengguna/nama pengguna/deskripsi
• users/username/workitem
• bugfix/description
• fitur/nama fitur
• feature/feature-area/feature-name
• perbaikan/deskripsi

Catatan

Untuk informasi tentang mengatur kebijakan untuk menerapkan strategi penamaan cabang, lihat Memerlukan folder cabang.

Menggunakan bendera fitur untuk mengelola cabang yang berjalan lama

Pelajari selengkapnya tentang menggunakan bendera fitur dalam kode Anda.

Meninjau dan menggabungkan kode dengan permintaan pull

Ulasan yang terjadi dalam permintaan pull sangat penting untuk meningkatkan kualitas kode. Hanya gabungkan cabang melalui permintaan pull yang melewati proses peninjauan Anda. Hindari menggabungkan cabang ke cabang utama tanpa permintaan pull.

Tinjauan dalam permintaan pull membutuhkan waktu untuk diselesaikan. Tim Anda harus menyetujui apa yang diharapkan dari pembuat dan peninjau permintaan pull. Distribusikan tanggung jawab peninjau untuk berbagi ide di seluruh tim Anda dan menyebarkan pengetahuan tentang basis kode Anda.

Beberapa saran untuk permintaan pull yang berhasil:

• Dua peninjau adalah angka optimal berdasarkan penelitian.
• Jika tim Anda sudah memiliki proses peninjauan kode, bawa permintaan pull ke dalam apa yang sudah Anda lakukan.
• Berhati-hatilah menetapkan peninjau yang sama ke sejumlah besar permintaan pull. Permintaan pull berfungsi lebih baik ketika tanggung jawab peninjau dibagikan di seluruh tim.
• Berikan detail yang cukup dalam deskripsi untuk mempercepat peninjau dengan cepat dengan perubahan Anda.
• Sertakan versi build atau tertaut dari perubahan Anda yang berjalan di lingkungan bertahap dengan permintaan pull Anda. Yang lain dapat dengan mudah menguji perubahan.

Pertahankan cabang utama berkualitas tinggi dan terbaru

Kode di cabang utama Anda harus lulus pengujian, membangun dengan bersih, dan selalu terkini. Cabang utama Anda membutuhkan kualitas ini sehingga cabang fitur yang dibuat oleh tim Anda dimulai dari versi kode yang dikenal baik.

Siapkan kebijakan cabang untuk cabang utama Anda yang:

• Memerlukan permintaan pull untuk menggabungkan kode. Pendekatan ini mencegah dorongan langsung ke cabang utama dan memastikan diskusi tentang perubahan yang diusulkan.
• Secara otomatis menambahkan peninjau saat permintaan pull dibuat. Anggota tim yang ditambahkan meninjau kode dan mengomentari perubahan dalam permintaan pull.
• Memerlukan build yang berhasil untuk menyelesaikan permintaan pull. Kode yang digabungkan ke cabang utama harus dibangun dengan bersih.

Tip

Alur build untuk permintaan pull Anda harus cepat diselesaikan, sehingga tidak mengganggu proses peninjauan.

Mengelola rilis

Gunakan cabang rilis untuk mengoordinasikan dan menstabilkan perubahan dalam rilis kode Anda. Cabang ini berumur panjang dan tidak digabungkan kembali ke cabang utama dalam permintaan pull, tidak seperti cabang fitur. Buat cabang rilis sebanyak yang Anda butuhkan. Perlu diingat bahwa setiap cabang rilis aktif mewakili versi lain dari kode yang perlu Anda dukung. Kunci cabang rilis saat Anda siap untuk berhenti mendukung rilis tertentu.

Menggunakan cabang rilis

Buat cabang rilis dari cabang utama saat Anda mendekati rilis atau tonggak pencapaian lainnya, seperti akhir sprint. Beri cabang ini nama yang jelas mengaitkannya dengan rilis, misalnya rilis/20.

Buat cabang untuk memperbaiki bug dari cabang rilis dan gabungkan kembali ke cabang rilis dalam permintaan pull.

Perubahan port kembali ke cabang utama

Pastikan bahwa memperbaiki lahan di cabang rilis dan cabang utama Anda. Salah satu pendekatannya adalah membuat perbaikan di cabang rilis, lalu membawa perubahan ke cabang utama Anda untuk mencegah regresi dalam kode Anda. Pendekatan lain (dan yang digunakan oleh tim Azure DevOps) adalah selalu membuat perubahan di garis utama, lalu memindahkannya ke cabang rilis. Anda dapat membaca lebih lanjut tentang strategi Alur Rilis kami.

Dalam topik ini, kita akan membahas pembuatan perubahan di cabang rilis dan memindahkannya ke garis utama. Gunakan cherry-picking alih-alih menggabungkan sehingga Anda memiliki kontrol yang tepat atas penerapan mana yang di-port kembali ke cabang utama. Menggabungkan cabang rilis ke cabang utama dapat membawa perubahan khusus rilis yang tidak Anda inginkan di cabang utama.

Perbarui cabang utama dengan perubahan yang dilakukan di cabang rilis dengan langkah-langkah berikut:

1. Buat cabang fitur baru dari cabang utama untuk memindah perubahan.
2. Cherry-pilih perubahan dari cabang rilis ke cabang fitur baru Anda.
3. Gabungkan cabang fitur kembali ke cabang utama dalam permintaan pull kedua.

Alur kerja cabang rilis ini menjaga pilar alur kerja dasar tetap utuh: cabang fitur, permintaan pull, dan cabang utama yang kuat yang selalu memiliki versi terbaru kode.

Mengapa tidak menggunakan tag untuk rilis?

Alur kerja pencabangan lainnya menggunakan tag Git untuk menandai penerapan tertentu sebagai rilis . Tag berguna untuk menandai titik dalam riwayat Anda sebagai penting. Tag memperkenalkan langkah tambahan dalam alur kerja Anda yang tidak diperlukan jika Anda menggunakan cabang untuk rilis Anda.

Tag dipertahankan dan didorong secara terpisah dari penerapan Anda. Anggota tim dapat dengan mudah melewatkan pemberian tag penerapan dan kemudian harus kembali melalui riwayat setelah itu untuk memperbaiki tag. Anda juga dapat melupakan langkah tambahan untuk mendorong tag, meninggalkan pengembang berikutnya yang bekerja dari versi kode yang lebih lama saat mendukung rilis.

Strategi cabang rilis memperluas alur kerja cabang fitur dasar untuk menangani rilis. Tim Anda tidak perlu mengadopsi proses kontrol versi baru selain pemilihan ceri untuk perubahan port.

Mengelola penyebaran

Anda dapat menangani beberapa penyebaran kode dengan cara yang sama seperti Anda menangani beberapa rilis. Buat konvensi penamaan yang jelas, seperti deploy/performance-test, dan perlakukan cabang lingkungan seperti cabang rilis. Tim Anda harus menyetujui proses untuk memperbarui cabang penyebaran dengan kode dari cabang utama Anda. Perbaikan bug Cherry-pick di cabang penyebaran kembali ke cabang utama. Gunakan langkah yang sama seperti memindahkan perubahan dari cabang rilis.

Pengecualian untuk rekomendasi ini adalah jika Anda menggunakan bentuk penyebaran berkelanjutan. Gunakan Azure Pipelines saat bekerja dengan penyebaran berkelanjutan untuk mempromosikan build dari cabang utama Anda ke target penyebaran Anda.