Sekitar setengah tahun yang lalu saya ditugaskan untuk melakukan studi untuk menjawab pertanyaan itu. Berikut ringkasannya, berdasarkan referensi yang dipelajari (tercantum di bawah)
http://msdn.microsoft.com/en-us/library/aa730834%28v=vs.80%29.aspx
... Menentukan strategi percabangan terbaik adalah tindakan penyeimbangan. Anda harus menukar keuntungan produktivitas dengan peningkatan risiko. Salah satu cara untuk memvalidasi strategi yang dipilih adalah dengan mempertimbangkan skenario perubahan. Misalnya, jika Anda memutuskan untuk menyelaraskan cabang dengan arsitektur sistem (misalnya, cabang mewakili komponen sistem) dan Anda mengharapkan perubahan arsitektur yang signifikan, Anda mungkin harus merestrukturisasi cabang Anda dan proses serta kebijakan terkait dengan setiap perubahan. Memilih strategi percabangan yang tidak memadai dapat menyebabkan overhead proses dan integrasi yang panjang dan melepaskan siklus yang terbukti membuat frustasi bagi seluruh tim ...
http://www.cmcrossroads.com/bradapp/acme/branching/
... Integrasi yang sering dan bertahap adalah salah satu rambu kesuksesan, dan ketidakhadirannya sering merupakan karakteristik kegagalan. Metode manajemen proyek saat ini cenderung untuk menghindari model air terjun yang ketat dan merangkul model spiral seperti pengembangan iteratif / inkremental dan pengiriman evolusioner. Strategi integrasi tambahan, seperti Gabungkan Dini dan Sering dan variannya, adalah suatu bentuk manajemen risiko yang mencoba membuang risiko lebih awal dalam siklus hidup ketika ada lebih banyak waktu untuk meresponsnya. Keteraturan irama antara integrasi dilihat oleh [Booch], [McCarthy], dan [McConnell] sebagai indikator utama kesehatan proyek (seperti "denyut nadi" atau "detak jantung").
Tidak hanya integrasi awal dan sering menyempurnakan risiko lebih cepat dan dalam "potongan kecil", itu juga mengkomunikasikan perubahan di antara rekan satu tim ...
http://www.codinghorror.com/blog/2007/10/software-branching-and-parallel-universes.html
... Di sebagian besar sistem kontrol sumber, Anda dapat membuat ratusan cabang tanpa masalah kinerja apa pun; itu adalah overhead mental untuk melacak semua cabang yang benar-benar perlu Anda khawatirkan ... Bercabang adalah binatang yang kompleks. Ada banyak cara untuk bercabang, dan tidak ada yang bisa memberi tahu Anda jika Anda melakukannya dengan benar atau salah ...
http://www.lostechies.com/blogs/derickbailey/archive/2010/02/24/branching-strategies-when-to-branch-and-merge.aspx
... Ada banyak aspek dari suatu sistem yang harus dipertimbangkan ketika melakukan percabangan kode Anda ... Pada akhirnya, tujuannya adalah untuk menyediakan kotak pasir untuk konteks di mana kode sedang ditulis. Memahami opsi yang tersedia, ketika setiap opsi paling cocok dengan situasi yang dihadapi dan biaya dari opsi ini akan membantu Anda dalam memutuskan bagaimana dan kapan akan ...
http://www.snuffybear.com/ucm_branch.htm
Catatan diberikan referensi lain yang tercantum di sini, klaim penulis bahwa "Artikel ini menjelaskan tiga model percabangan utama yang digunakan dalam proyek Rekayasa Perangkat Lunak" tidak terlihat dibenarkan. Terminologi yang digunakan tidak terlihat luas ( EFIX , Model-1,2,3 dll).
http://svn.haxx.se/users/archive-2007-10/att-0101/SCMBranchingModels-talkback.pdf
Referensi menyajikan contoh menarik tentang kesulitan dalam mengkomunikasikan strategi percabangan.
http://simpleprogrammer.com/2010/06/04/simple-branching-strategy-part-1-back-to-basics/
... Tetap sederhana. Bekerja langsung dari bagasi sejauh ini merupakan pendekatan terbaik menurut saya.
Itu hampir terdengar seperti bid'ah ketika saya benar-benar mengetiknya di layar saya, tetapi jika Anda akan bertahan dengan saya sebentar, tidak hanya akan saya tunjukkan mengapa saya pikir ini sangat penting untuk proses Agile, tetapi saya akan menunjukkan kepada Anda bagaimana untuk membuatnya bekerja ...
... Jika saya harus mendasarkan alasan saya pada satu argumen yang solid, itu akan menjadi nilai integrasi yang berkelanjutan. Saya membuat blog tentang nilai CI dan praktik terbaik di masa lalu. Saya seorang penganjur CI ...
... Anda benar-benar harus bertanya pada diri sendiri pertanyaan di sini: "Apakah semua overhead yang Anda keluarkan karena melakukan strategi percabangan dan penggabungan yang rumit menghasilkan nilai nyata yang tidak ada dibandingkan strategi yang lebih sederhana?" ...
.. Strategi. Saya telah menggunakan secara efektif di masa lalu dan telah berkembang dari waktu ke waktu. Saya akan meringkasnya sebentar di sini.
- Semua orang bekerja di luar bagasi.
- Cabang ketika Anda merilis kode.
- Pangkas rilis ketika Anda perlu membuat perbaikan bug untuk kode yang sudah dirilis.
- Cabang untuk prototipe.
...
http://www.codelathe.com/blog/index.php/2009/07/02/a-svn-branching-strategy-that-works/
... Akhirnya, ingatlah bahwa tidak ada strategi percabangan dan penggabungan yang ideal. Ini sangat tergantung pada lingkungan pengembangan unik Anda ...
http://blog.perforce.com/blog/?cat=62
... Skenario kasus terburuk adalah Anda memperkenalkan masalah "penggabungan semantik", di mana hasil penggabungan otomatis salah, tetapi mengkompilasi OK dan menyelinap melewati pengujian, bahkan mungkin bertahan cukup lama untuk menjadi bug yang terlihat oleh pelanggan. Eek!
Menambahkan penghinaan pada cedera, karena mereka dapat lolos dari deteksi lebih lama, masalah penggabungan semantik lebih sulit untuk diperbaiki nanti, karena perubahan tidak lagi segar dalam pikiran pengembang yang memulai perubahan. (Biasanya yang terbaik untuk menggabungkan perubahan segera setelah dilakukan, idealnya oleh pengembang yang memulai perubahan jika itu praktis) ...
https://stackoverflow.com/questions/34975/branching-strategies
Anggota komunitas berbagi pengalaman berbeda dalam berbagai proyek menggunakan berbagai strategi percabangan. Tidak ada konsensus yang disepakati tentang "terbaik" atau "terburuk".
http://www.stickyminds.com/s.asp?F=S16454_COL_2
Intinya ringkasan singkat tentang hal-hal yang disajikan di http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf
- http://www.stickyminds.com/s.asp?F=S16511_COL_2
... Ada tiga pendekatan umum untuk memutuskan kapan dan bagaimana cara melakukan percabangan:
- Buat cabang rilis ketika Anda "fitur selesai," dan berencana untuk memperbaiki masalah menit terakhir pada baris kode ini. Dalam hal ini, cabang rilis benar-benar merupakan "baris kode persiapan-rilis," seperti yang dijelaskan dalam Pola Manajemen Konfigurasi Perangkat Lunak , karena Anda berharap masih ada pekerjaan yang harus dilakukan.
- Ubah gaya kerja Anda untuk menghindari pekerjaan integrasi akhir, bekerja di luar jalur pengembangan aktif.
- Cabang untuk pekerjaan baru dengan membuat cabang tugas dan menggabungkan pekerjaan itu ke jalur pengembangan aktif setelah rilis selesai.
... Alasan untuk percabangan adalah mengisolasi kode pada akhir rilis sehingga dapat stabil. Isolasi melalui percabangan seringkali menutupi masalah kualitas yang pada akhirnya akan memanifestasikan dirinya dalam biaya tambahan untuk mempertahankan aliran paralel sebelum suatu produk dirilis. Percabangan itu mudah. Alih-alih, ini merupakan penggabungan dan overhead kognitif untuk memahami bagaimana perubahan mengalir di antara cabang-cabang yang sulit, jadi penting untuk memilih proses yang meminimalkan biaya percabangan dan penggabungan ...
http://nvie.com/posts/a-successful-git-branching-model/ strategi berorientasi-Git.
... Kami menganggap asal / master sebagai cabang utama tempat kode sumber HEAD selalu mencerminkan status siap-produksi .
Kami menganggap asal / berkembang sebagai cabang utama di mana kode sumber HEAD selalu mencerminkan keadaan dengan perubahan pengembangan yang disampaikan terakhir untuk rilis berikutnya. Beberapa orang akan menyebut ini "cabang integrasi". Di sinilah setiap bangunan malam otomatis dibangun dari ....
http://svnbook.red-bean.com/en/1.5/svn.branchmerge.html
... kebijakan proyek sangat bervariasi mengenai kapan tepatnya tepat untuk membuat cabang fitur. Beberapa proyek tidak pernah menggunakan cabang fitur sama sekali: komit ke / trunk adalah gratis untuk semua. Keuntungan dari sistem ini adalah sederhana - tidak ada yang perlu belajar tentang percabangan atau penggabungan. Kerugiannya adalah bahwa kode trunk sering tidak stabil atau tidak dapat digunakan. Proyek lain menggunakan cabang secara ekstrem: tidak ada perubahan yang dilakukan secara langsung ke trunk. Bahkan perubahan yang paling sepele dibuat pada cabang yang berumur pendek, ditinjau dengan hati-hati, dan digabungkan ke bagasi. Kemudian cabang dihapus. Sistem ini menjamin batang yang sangat stabil dan dapat digunakan setiap saat, tetapi dengan biaya yang luar biasaproses overhead.
Sebagian besar proyek mengambil pendekatan tengah jalan. Mereka umumnya bersikeras bahwa / trunk mengkompilasi dan lulus tes regresi setiap saat. Cabang fitur diperlukan hanya ketika perubahan membutuhkan sejumlah besar komitmen destabilisasi. Aturan praktis yang baik adalah untuk mengajukan pertanyaan ini: jika pengembang bekerja berhari-hari dalam isolasi dan kemudian melakukan perubahan besar sekaligus (sehingga / trunk tidak pernah tidak stabil), apakah itu terlalu besar untuk ditinjau? Jika jawaban untuk pertanyaan itu adalah "ya," perubahan harus dikembangkan pada cabang fitur. Karena pengembang melakukan perubahan tambahan ke cabang, mereka dapat dengan mudah ditinjau oleh rekan-rekan.
Akhirnya, ada masalah tentang cara terbaik menjaga cabang fitur dalam "sinkronisasi" dengan trunk saat pekerjaan berlangsung. Seperti yang kami sebutkan sebelumnya, ada risiko besar bekerja di cabang selama berminggu-minggu atau berbulan-bulan; perubahan batang mungkin terus mengalir, ke titik di mana dua garis perkembangan sangat berbeda sehingga dapat menjadi mimpi buruk mencoba menggabungkan cabang kembali ke batang.
Situasi ini sebaiknya dihindari dengan secara teratur menggabungkan perubahan batang ke cabang. Buat kebijakan: seminggu sekali, gabungkan nilai perubahan bagasi minggu lalu ke cabang ...
http://thedesignspace.net/MT2archives/000680.html
... Bagian tutorial Eclipse CVS ini didasarkan pada artikel Paul Glezen di situs web Eclipse: Bercabang dengan Eclipse dan CVS , dan digunakan dengan izinnya berdasarkan persyaratan dari lisensi EPL. Perubahan yang saya lakukan pada versinya terutama untuk memperluasnya dengan lebih banyak gambar langkah demi langkah dan penjelasan, dan mengintegrasikannya dengan tutorial pemula saya sendiri dalam upaya untuk membuatnya lebih mudah diakses oleh pemula dan desainer. Pengembang yang berpengalaman mungkin akan lebih suka bekerja dari versi Paul ...
http://learnsoftwareprocesses.com/2007/12/29/common-branching-strategies/
... Berikut adalah beberapa model percabangan yang umum:
- Branch-by-release Model: Salah satu strategi percabangan yang paling umum adalah menyelaraskan cabang dengan rilis produk. Cabang memegang semua aset pengembangan perangkat lunak untuk satu rilis. Terkadang, pembaruan harus digabungkan dari satu rilis ke rilis lainnya, tetapi biasanya tidak pernah bergabung. Cabang akan dihentikan ketika rilis sudah pensiun.
- Cabang per Promosi: Pendekatan lain yang sangat umum adalah menyelaraskan cabang dengan tingkat promosi aset perangkat lunak. Versi pengembangan spesifik bercabang menjadi cabang Uji, di mana semua integrasi dan pengujian sistem dilakukan. Ketika Anda menyelesaikan pengujian, aset pengembangan perangkat lunak bercabang ke cabang Produksi dan akhirnya dikerahkan.
- Cabang per Tugas: Untuk menghindari tugas yang tumpang tindih (atau kegiatan) dan hilangnya produktivitas, Anda dapat mengisolasi mereka di cabang yang terpisah. Ingatlah bahwa ini adalah cabang jangka pendek yang harus digabung segera setelah tugas selesai, karena jika tidak, upaya penggabungan yang diperlukan dapat melebihi manfaat produktivitas dari menciptakannya.
- Cabang per Komponen: Anda dapat menyelaraskan setiap cabang dengan arsitektur sistem. Dalam strategi ini, Anda bercabang komponen individu (atau subsistem). Kemudian setiap tim yang mengembangkan komponen memutuskan kapan untuk menggabungkan kode mereka kembali ke jalur pengembangan yang berfungsi sebagai cabang integrasi. Strategi ini dapat bekerja dengan baik jika arsitektur sistem ada dan masing-masing komponen memiliki antarmuka yang terdefinisi dengan baik. Fakta bahwa Anda mengembangkan komponen pada cabang memungkinkan kontrol yang lebih baik atas aset pengembangan perangkat lunak.
- Cabang per Teknologi: Strategi percabangan lain yang selaras dengan arsitektur sistem. Dalam hal ini cabang diselaraskan dengan platform teknologi. Kode umum dikelola pada cabang terpisah. Karena sifat unik dari aset pengembangan perangkat lunak yang dikelola di cabang, mereka mungkin tidak pernah ...
http://msdn.microsoft.com/en-us/library/bb668955.aspx
... Lihat panduan percabangan dan penggabungan dalam "Pedoman Kontrol Sumber" dalam panduan ini untuk ringkasan panduan percabangan dan penggabungan. ... Saat bercabang, pertimbangkan hal berikut:
- Jangan bercabang kecuali tim pengembangan Anda perlu bekerja pada set file yang sama secara bersamaan. Jika Anda tidak yakin tentang ini, Anda bisa memberi label bangunan dan membuat cabang dari bangunan itu di titik kemudian. Menggabungkan cabang bisa memakan waktu dan rumit, terutama jika ada perubahan yang signifikan di antara mereka.
- Struktur pohon cabang Anda sehingga Anda hanya perlu menggabungkan sepanjang hierarki (naik dan turun pohon cabang) daripada melintasi hierarki. Bercabang di hierarki mengharuskan Anda menggunakan penggabungan tanpa dasar, yang membutuhkan lebih banyak resolusi konflik manual.
- Hirarki cabang didasarkan pada induk cabang dan anak cabang, yang mungkin berbeda dari struktur fisik kode sumber pada disk. Saat merencanakan penggabungan Anda, perhatikan struktur cabang logis daripada struktur fisik pada disk.
- Jangan bercabang terlalu dalam. Karena diperlukan waktu untuk mengeksekusi setiap penggabungan dan menyelesaikan konflik, struktur percabangan yang dalam dapat berarti bahwa perubahan dalam cabang anak mungkin membutuhkan waktu yang sangat lama untuk menyebar ke cabang utama. Ini dapat berdampak negatif pada jadwal proyek dan meningkatkan waktu untuk memperbaiki bug.
- Cabang di tingkat tinggi dan sertakan konfigurasi dan file sumber.
- Evolusikan struktur percabangan Anda dari waktu ke waktu.
- Penggabungan membutuhkan satu atau beberapa pengembang untuk menjalankan penggabungan dan menyelesaikan konflik. Sumber yang digabung harus diuji secara menyeluruh karena tidak jarang membuat keputusan penggabungan yang buruk yang dapat mengacaukan pembangunan.
- Menggabungkan hierarki cabang sangat sulit dan mengharuskan Anda untuk menangani banyak konflik secara manual yang dapat ditangani secara otomatis.
Keputusan untuk membuat cabang dapat dikurangi menjadi apakah biaya menggabungkan konflik secara real time lebih tinggi daripada biaya overhead menggabungkan konflik antara cabang ...
http://kashfarooq.wordpress.com/2009/11/23/bazaar-branching-strategy-with-a-subversion-trunk/
- http://kashfarooq.wordpress.com/2010/12/16/bazaar-branching-strategy-with-a-subversion-trunk-revised/
- http://kashfarooq.wordpress.com/2009/11/02/using-bazaar-feature-branches-with-a-subversion-trunk/
- http://kashfarooq.wordpress.com/2009/09/08/bazaar-or-git-moving-away-from-subversion/
... Apakah salah satu keluhan Subversi ini terdengar familier?
- Anda diinstruksikan secara acak bahwa "Anda harus menjalankan pembaruan". Anda kemudian melakukan pembaruan - yang membutuhkan waktu lama untuk menyelesaikannya. Dan akhirnya, Anda melihat bahwa tidak ada perubahan yang perlu diunduh.
- Anda diinstruksikan secara acak bahwa "Anda harus menjalankan pembersihan".
- Anda memiliki masalah penggabungan yang sangat besar. Misalnya, Anda menggunakan ReSharper untuk mengubah nama kelas, dan yang lain telah memperbarui kelas itu untuk sementara. Anda kemudian melihat kesalahan konflik pohon yang ditakuti (bergidik). Atau lebih buruk lagi, Anda mengganti nama seluruh namespace dan folder (double shudder). Sekarang Anda benar-benar berada dalam dunia kesakitan.
- Penggabungan Anda cenderung lebih dan lebih manual. Anda sering harus menggunakan WinMerge karena Subversion tidak punya petunjuk.
- Anda sering menunggu Tortoise untuk memperbarui / memeriksa modifikasi / apa pun.
Saya memiliki repositori subversi pada pen drive USB saya. Saya mendapatkan konflik pohon dan menggabungkan masalah dengan itu, dan saya satu-satunya pengguna!
Masalah utamanya adalah menggabungkan ...
- "subversi menyebalkan" terdengar familier. Waktunya mendengarkan Joel dan Linus ?
http://social.msdn.microsoft.com/Forums/en/tfsversioncontrol/thread/f127676c-8f05-410c-9a30-0eb43a26a9fa
diskusi tentang praktik terbaik untuk rilis strategi cabang isolasi dalam kasus sistem yang berkembang.
http://branchingguidance.codeplex.com/
"Panduan Percabangan Server Server Yayasan Microsoft" - dokumen besar dan terperinci dengan rekomendasi yang disesuaikan dengan proyek yang berbeda: Versi HTML di sini . Membuktikan bahwa Microsoft tidak percaya pada strategi percabangan one-size-fits-all approach wrt.
https://stackoverflow.com/questions/597707/best-branching-strategy-when-doing-continuous-integration
Apa strategi percabangan terbaik untuk digunakan ketika Anda ingin melakukan integrasi berkelanjutan? ... Jawabannya tergantung pada ukuran tim Anda dan kualitas kontrol sumber Anda dan kemampuan untuk menggabungkan set perubahan yang kompleks dengan benar ...
- http://www.zeroturnaround.com/blog/continuous-integration-and-feature-branches/
analisis yang lebih terperinci tentang interaksi percabangan dengan integrasi berkelanjutan, berdasarkan pada pengalaman nyata dengan Hudson / Jenkins - bersama dengan beberapa referensi yang bermanfaat
.. . Penemuan terbesar saya adalah bahwa meskipun CI adalah tentang melakukan, mendorong dan mendapatkan umpan balik sering (yaitu cluster CI memberi Anda umpan balik bahwa workstation Anda tidak pernah bisa memberi Anda dalam jumlah waktu yang sama), CI purist sejati sebenarnya memiliki satu persyaratan lagi - bahwa tim perlu bekerja pada garis dasar yang sama ...
Bahan yang digunakan
http://codicesoftware.blogspot.com/2010/03/branching-strategies.html
... CVS dan SVN tidak mendukung seluruh strategi percabangan / penggabungan karena mereka sama sekali tidak dapat melakukannya ... ... Aturan sederhana: buat cabang tugas untuk setiap fitur baru atau perbaikan bug yang Anda laksanakan ... Ini mungkin terdengar berlebihan bagi pengguna SVN / CVS tetapi Anda tahu SCM modern akan membiarkan Anda membuat cabang dalam sedetik, sehingga tidak ada overhead nyata.
Catatan penting: jika Anda melihatnya dengan cermat, Anda akan melihat bahwa saya sedang berbicara tentang menggunakan cabang tugas sebagai daftar perubahan orang kaya ...
http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.cc_proj.doc/c_bntr_plnbrstrat.htm
... Kebijakan percabangan dipengaruhi oleh pengembangan tujuan proyek dan menyediakan mekanisme untuk mengontrol evolusi basis kode. Ada banyak variasi kebijakan percabangan sebagai organisasi yang menggunakan kontrol versi ClearCase Rational. Tetapi ada juga kesamaan yang mencerminkan kepatuhan umum terhadap praktik terbaik ...
http://blogs.open.collab.net/svn/2007/11/branching-strat.html
... Model Subversion (atau model open source umum lebih akurat) adalah apa yang ditampilkan dalam model trunk yang tidak stabil .. .
http://en.wikipedia.org/wiki/Trunk_%28software%29
Di bidang pengembangan perangkat lunak, trunk merujuk pada cabang (versi) pohon file yang tidak disebutkan namanya di bawah kendali revisi . Batang pohon biasanya dimaksudkan sebagai pangkalan proyek di mana pembangunan berlangsung. Jika pengembang bekerja secara eksklusif pada trunk, itu selalu berisi versi terbaru dari proyek, tetapi karena itu mungkin juga versi yang paling tidak stabil. Pendekatan lain adalah dengan memisahkan cabang dari batang, menerapkan perubahan di cabang itu dan menggabungkan perubahan kembali ke batang ketika cabang telah terbukti stabil dan berfungsi. Tergantung pada mode pengembangan dan komitkebijakan trunk mungkin berisi versi paling stabil atau paling tidak stabil atau sesuatu di antara keduanya.
Seringkali pekerjaan pengembang utama terjadi di versi trunk dan stabil bercabang, dan perbaikan bug sesekali digabungkan dari cabang ke trunk. Ketika pengembangan versi masa depan dilakukan di cabang-cabang non-trunk, biasanya dilakukan untuk proyek-proyek yang tidak sering berubah, atau di mana perubahan diharapkan membutuhkan waktu lama untuk berkembang sampai siap untuk dimasukkan ke dalam batang. .
http://www.mcqueeney.com/roller/page/tom/20060919
... Ini adalah catatan dari webinar tentang praktik terbaik Subversion , yang dilakukan 30 Agustus 2006 oleh CollabNet. ... Dua strategi organisasi: trunk tidak stabil vs trunk stabil ... ... MEMILIH trunk tidak stabil bila memungkinkan ...
https://stackoverflow.com/questions/153812/subversion-is-trunk-really-the-best-place-for-the-main-development
Di SVN, trunk adalah tempat yang direkomendasikan untuk pengembangan utama dan saya menggunakan konvensi ini untuk semua proyek saya. Namun, ini berarti bahwa trunk kadang-kadang tidak stabil, atau bahkan rusak ... ... tidak akan lebih baik untuk melakukan "perkembangan liar" pada beberapa cabang seperti / branch / dev dan hanya bergabung ke trunk ketika bangunan cukup padat?
- ... Batang adalah tempat pengembangan yang sedang berlangsung seharusnya terjadi. Anda benar-benar seharusnya tidak memiliki masalah dengan kode "rusak", jika semua orang menguji perubahan mereka sebelum melakukannya. Aturan praktis yang baik adalah melakukan pembaruan (dapatkan semua kode terbaru dari repo) setelah Anda membuat kode perubahan. Kemudian buat dan lakukan beberapa pengujian unit. Jika semuanya membangun dan berfungsi, Anda harus memeriksa ...
- ... Trunk bukan tempat terbaik. Di organisasi kami, kami selalu mengikuti pendekatan ini: Batang berisi kode rilis, jadi selalu dikompilasi. Dengan setiap rilis / tonggak baru kami membuka cabang baru. Kapan pun pengembang memiliki item, ia membuat cabang baru untuk cabang rilis ini dan menggabungkannya ke cabang rilis hanya setelah mengujinya. Cabang rilis digabung ke dalam bagasi setelah pengujian sistem ...
http://blog.yclian.com/2009/03/working-on-branches-and-stable-trunk.html
... Saya dulu bekerja di trunk karena untuk semua proyek yang saya kerjakan, saya juga pengembang tunggal atau tim memastikan bahwa semua orang kode check-in telah lulus tes lokal. Kalau tidak, kami membuat (kami masih) cabang untuk perbaikan bug, kode besar untuk fitur baru, dll.
Sekitar 2 bulan yang lalu, saya memiliki sesi git singkat dengan Kamal dan dia berbagi dengan saya ide cerita / cabang . Dan ketika tim saya mulai tumbuh dengan lebih banyak orang-orang dev, saya merasa perlu mendorong lebih banyak cabang dan sekarang ini telah menjadi aturan. Untuk proyek dengan tes otomatis yang didefinisikan dengan pengaturan CI, batang yang stabil dijamin dan praktik ini dapat sangat cocok dengannya.
Kami tidak menggunakan git tetapi Subversion karena itulah cara kami memulai dan kami masih nyaman dengan itu sekarang (sebagian besar waktu) ...
http://www.ericsink.com/scm/scm_branches.html
Ini adalah bagian dari buku online bernama Source Control HOWTO , panduan praktik terbaik tentang kontrol sumber, kontrol versi, dan manajemen konfigurasi ...
... Eric's Preferred Branching Berlatih ... Simpanlah koper "yang pada dasarnya tidak stabil". Apakah pengembangan aktif Anda di bagasi, stabilitas yang meningkat saat Anda mendekati rilis. Setelah Anda mengirim, buat cabang pemeliharaan dan selalu sangat stabil ...
... Pada bab berikutnya saya akan membahas topik menggabungkan cabang ...
http://marc.info/?l=forrest-dev&m=112504297928196&w=2
Memulai email dari utas yang membahas strategi percabangan untuk proyek Apache Forrest
- perhatikan saat ini proyek tampaknya menggunakan model trunk yang tidak stabil dengan cabang rilis:
- "Pekerjaan pengembangan dilakukan pada bagasi SVN ... Ada" rilis cabang "dari SVN, misalnya forrest_07_branch." ( pedoman proyek )
- "Membangun paket kandidat rilis ... 17. Buat cabang pemeliharaan di SVN ..." ( Cara merilis )
Dokumen cabang O'Reilly CVS:
http://commons.oreilly.com/wiki/index.php/Essential_CVS/Using_CVS/Tagging_and_Branching#Basically_stable
- ... Filosofi percabangan yang pada dasarnya stabil menyatakan bahwa trunk harus berisi data proyek yang selalu siap untuk dirilis ... ... Variasi yang lebih fleksibel dari filosofi ini memungkinkan apa pun yang melewati pengujian unit pengembang untuk digabungkan ke dalam bagasi. Pendekatan yang santai seperti itu membutuhkan kandidat rilis untuk bercabang dan melakukan analisis QA penuh sebelum publikasi ...
- ... Filosofi yang pada dasarnya tidak stabil menyatakan bahwa bagasi harus berisi kode terbaru, terlepas dari stabilitasnya, dan bahwa kandidat rilis harus bercabang untuk QA.
... Variasi yang lebih lunak juga memungkinkan percabangan untuk kode eksperimen, refactoring, dan kode kasus khusus lainnya. Penggabungan cabang kembali ke bagasi dilakukan oleh manajer cabang. ...
- Catatan sumber daya di atas tidak muncul di salah satu pencarian yang saya lakukan (pedoman terkait CVS tidak populer lagi?)
Praktik terbaik dalam SCM (perforce artikel) di
http://www.perforce.com/perforce/papers/bestpractices.html
... enam area umum penyebaran SCM, dan beberapa praktik terbaik berbutir kasar dalam setiap area tersebut. Bab-bab berikut menjelaskan setiap item ...
Ruang kerja, Codelines, Branching, Change Propagation, Builds, Process ...