Jawaban:
Ada beberapa kegunaan percabangan. Salah satu kegunaan paling umum adalah untuk memisahkan proyek yang pernah memiliki basis kode yang sama. Ini sangat berguna untuk bereksperimen dengan kode Anda, tanpa mempengaruhi trunk utama.
Secara umum, Anda akan melihat dua jenis cabang:
Cabang Fitur: Jika fitur tertentu cukup mengganggu sehingga Anda tidak ingin seluruh tim pengembangan terpengaruh pada tahap awalnya, Anda dapat membuat cabang untuk melakukan pekerjaan ini.
Fixes Branch: Sementara pengembangan berlanjut di trunk utama, cabang perbaikan dapat dibuat untuk menyimpan perbaikan ke versi software terbaru yang dirilis.
Anda mungkin tertarik untuk membaca artikel berikut, yang menjelaskan prinsip-prinsip percabangan, dan kapan menggunakannya:
Secara umum, tujuan utama percabangan (VCS - Fitur Sistem Kontrol Versi) adalah untuk mencapai isolasi kode .
Anda memiliki setidaknya satu cabang, yang cukup untuk pengembangan sekuensial, dan digunakan untuk banyak tugas yang sedang direkam (dilakukan) pada cabang unik yang sama.
Tetapi model itu dengan cepat menunjukkan batasnya:
Ketika Anda memiliki upaya pengembangan (pemfaktoran ulang, evolusi, perbaikan bug, ...) dan Anda menyadari bahwa Anda tidak dapat dengan aman membuat perubahan tersebut di cabang yang sama dengan cabang pengembangan Anda saat ini (karena Anda akan merusak API, atau memperkenalkan kode yang akan merusak semuanya), maka Anda membutuhkan cabang lain .
(Untuk mengisolasi kode baru itu untuk yang lama, meskipun dua set kode akan digabungkan nanti)
Jadi itulah jawaban Anda saat ini:
Anda harus bercabang setiap kali Anda tidak dapat mengejar dan mencatat dua upaya pengembangan dalam satu cabang.
(tanpa memiliki sejarah yang sangat rumit untuk dipertahankan).
Sebuah cabang dapat berguna bahkan jika Anda adalah satu-satunya yang mengerjakan kode sumber, atau jika Anda banyak.
Namun Anda tidak boleh membuat "satu cabang per pengembang":
tujuan "isolasi" dibuat untuk mengisolasi upaya pengembangan (tugas yang dapat bersifat umum seperti "mari kembangkan versi berikutnya dari perangkat lunak kita" atau sespesifik seperti "mari perbaiki bug 23 "),
bukan untuk mengisolasi" resource " .
(cabang bernama "VonC" tidak berarti apa-apa bagi pengembang lain: Bagaimana jika "VonC" keluar dari proyek? Apa yang harus Anda lakukan dengannya?
cabang bernama "perbaikan bug_212" dapat diinterpretasikan dalam konteks sistem pelacakan bug misalnya , dan pengembang mana pun dapat menggunakannya dengan setidaknya beberapa gagasan tentang apa yang seharusnya dia lakukan dengannya)
Sebuah cabang bukanlah sebuah tag (SVN adalah Sistem Revisi yang mencoba untuk mengusulkan fitur versi seperti percabangan dan penandaan melalui direktori dengan salinan file yang murah: itu tidak berarti sebuah tag adalah sebuah cabang)
Untuk menentukan cabang berarti juga mendefinisikan alur kerja gabungan : Anda perlu tahu di mana untuk menggabungkan cabang Anda saat Anda selesai dengannya.
Untuk itu, Bab 7 dari Praktis Perforce (Laura WINGERD - O'Reilly) adalah pengantar yang baik (VCS agnostik) untuk menggabungkan alur kerja antara berbagai jenis cabang: "" Bagaimana Evolusi Perangkat Lunak "(pdf)
Ini mendefinisikan istilah codeline (cabang yang merekam langkah evolusi kode yang signifikan, baik melalui tag pada titik tertentu, atau melalui penggabungan penting kembali ke cabang)
Ini memperkenalkan model jalur utama (garis kode pusat untuk merekam rilis), dan menjelaskan berbagai tujuan untuk percabangan:
Konsep menarik lainnya seputar VCS: Konsep dasar
(tentang ClearCase aslinya, tetapi juga berlaku untuk VCS apa pun)
Semua SCM abad ke-21 memberi tahu Anda:
Cabang untuk setiap tugas yang harus Anda kerjakan , tidak peduli apakah ini fitur baru, perbaikan bug, tes, apa pun. Ini disebut cabang topik, dan ini mengubah cara Anda bekerja dengan SCM Anda.
Anda mendapatkan:
Alat yang dapat melakukannya:
Alat yang TIDAK BISA melakukannya:
Itu juga tergantung pada alat SCM yang Anda gunakan. SCM modern (git, mercurial, dll.) Membuatnya semakin mudah untuk membuat dan menghancurkan cabang kapan pun diperlukan. Ini memungkinkan Anda, misalnya, membuat satu cabang per bug yang sedang Anda tangani. Setelah Anda menggabungkan hasil Anda ke dalam bagasi, Anda membuang cabangnya.
SCM lain, misalnya subversi dan CVS, memiliki paradigma percabangan yang jauh "lebih berat". Itu berarti, sebuah cabang dianggap tepat hanya untuk sesuatu yang lebih besar dari tambalan garis dua puluh sesuatu. Di sana, cabang secara klasik digunakan untuk melacak seluruh jalur pengembangan, seperti versi produk sebelumnya atau yang akan datang.
Saat Anda perlu membuat perubahan yang signifikan dan / atau eksperimental pada basis kode Anda, terutama jika Anda ingin melakukan perubahan perantara, tanpa memengaruhi trunk.
Itu tergantung pada jenis SCM yang Anda gunakan.
Dalam versi terdistribusi yang lebih baru (seperti git dan mercurial), Anda membuat cabang setiap saat dan tetap muncul kembali. Saya akan sering mengerjakan cabang terpisah untuk sementara waktu hanya karena seseorang merusak build di jalur utama, atau karena jaringan tidak aktif, dan kemudian menggabungkan perubahan kembali nanti ketika sudah diperbaiki, dan sangat mudah untuk melakukannya bahkan tidak mengganggu .
Dokumen (singkat dan dapat dibaca) yang paling membantu saya memahami apa yang terjadi dalam sistem terdistribusi adalah: UnderstandingMercurial .
Dalam sistem lama dengan repositori pusat, (seperti CVS, SVN, dan ClearCase), ini adalah masalah yang jauh lebih serius yang perlu diputuskan di tingkat tim, dan jawabannya harus lebih seperti 'mempertahankan rilis lama sambil mengizinkan pengembangan untuk melanjutkan di jalur utama ', atau' sebagai bagian dari eksperimen besar '.
Model terdistribusi jauh lebih baik, menurut saya, dan kekurangan alat grafis yang bagus untuk menjadi paradigma yang dominan. Namun ini tidak dipahami secara luas, dan konsepnya berbeda, sehingga dapat membingungkan pengguna baru.
Menurut saya, saran dari Laura Wingerd & Christopher Seiwald di Perforce sangat ringkas dan berguna:
* Branch only when necessary.
* Don't copy when you mean to branch.
* Branch on incompatible policy.
* Branch late.
* Branch, instead of freeze.
Lihat http://www.perforce.com/sites/default/files/pdf/perforce-best-practices.pdf untuk penjelasan rinci tentang masing-masing dan praktik terbaik lainnya.
Ada berbagai tujuan percabangan:
Kapanpun Anda merasa seperti itu.
Anda mungkin tidak akan terlalu sering jika Anda bekerja dengan SCM terpusat karena cabang adalah bagian dari repositori resmi, dan itu tidak terlalu mengundang banyak eksperimen, belum lagi penggabungan sangat merugikan.
OTOH, tidak ada perbedaan teknis antara cabang dan checkout di SCM terdistribusi, dan penggabungan jauh lebih mudah. Anda akan merasa ingin bercabang lebih sering.
Saat Anda perlu membuat perubahan, berdasarkan cabang Anda saat ini, tidak ditakdirkan untuk rilis berikutnya dari cabang itu (dan bukan sebelumnya).
Misalnya, kami biasanya mengerjakan bagasi. Sekitar waktu rilis, seseorang akan perlu melakukan perubahan yang tidak kita inginkan dalam rilis saat ini (mungkin sebelum rilis, saat ini biasanya setelah rilis). Ini adalah saat kita bercabang, untuk meletakkan rilis di cabangnya sendiri dan melanjutkan pengembangan untuk rilis berikutnya di bagasi.
Mengesampingkan semua hal teknis .....
Cabang saat Anda tahu lebih mudah untuk bergabung kembali!
Perlu diingat bahwa penggabungan akan selalu dipengaruhi oleh bagaimana pekerjaan tersebut dilakukan dalam sebuah proyek.
Setelah ini tercapai, semua masalah tersier lainnya akan ikut bermain.