Cabang atau tidak cabang?

Hingga saat ini alur kerja pengembangan saya adalah sebagai berikut:

1. Dapatkan fitur dari pemilik produk
2. Buat cabang (jika fitur lebih dari 1 hari)
3. Menerapkannya di cabang
4. Gabungkan perubahan dari cabang utama ke cabang saya (untuk mengurangi konflik selama penggabungan mundur)
5. Gabungkan cabang saya kembali ke cabang utama

Terkadang ada masalah dengan penggabungan, tetapi secara umum saya menyukainya.

Tetapi baru-baru ini saya melihat semakin banyak pengikut ide untuk tidak membuat cabang karena semakin sulit untuk mempraktikkan integrasi berkelanjutan, pengiriman terus-menerus, dll. Dan itu terdengar sangat lucu dari orang-orang dengan latar belakang VCS terdistribusi yang banyak berbicara tentang implementasi penggabungan yang hebat dari Git, Mercurial, dll.

Jadi pertanyaannya adalah apakah kita harus menggunakan cabang saat ini?

Kecuali Anda semua bekerja dari pohon kerja yang sama, Anda sedang menggunakan cabang, apakah Anda memanggil mereka itu atau tidak. Setiap kali seorang pengembang memeriksa pohon kerjanya, ia membuat cabang pengembangan lokal yang terpisah, dan setiap kali ia memeriksa ia melakukan penggabungan. Untuk sebagian besar tim, pertanyaannya bukan apakah Anda menggunakan cabang, pertanyaannya adalah berapa banyak dan untuk tujuan apa ?

Satu-satunya cara untuk melakukan integrasi yang benar-benar "berkelanjutan" adalah agar semua orang bekerja di pohon yang sama. Dengan begitu, Anda segera tahu jika perubahan Anda berdampak buruk pada orang lain. Jelas, itu tidak bisa dipertahankan. Anda memerlukan tingkat isolasi tertentu di cabang untuk mencapai apa pun, bahkan jika "cabang" itu hanyalah direktori kerja lokal Anda. Yang dibutuhkan adalah keseimbangan integrasi dan isolasi yang tepat.

Dalam pengalaman saya, menggunakan lebih banyak cabang meningkatkan tingkat integrasi, karena integrasi dilakukan dengan tepat orang-orang yang perlu dilakukan, dan semua orang dapat dengan mudah mengisolasi masalah yang tidak terkait yang diperlukan.

Sebagai contoh, saya menghabiskan hari terakhir melacak tiga bug terkait integrasi baru-baru ini di build kami yang menghalangi pekerjaan "nyata" saya. Setelah melakukan uji tuntas saya dalam melaporkan bug ini kepada orang-orang yang perlu memperbaikinya, apakah saya sekarang hanya harus menunggu sampai mereka selesai untuk melanjutkan pekerjaan saya? Tentu saja tidak. Saya membuat cabang lokal sementara yang mengembalikan perubahan itu sehingga saya dapat memiliki baseline yang stabil untuk bekerja melawan sementara masih menerima perubahan terbaru dari hulu.

Tanpa kemampuan untuk membuat cabang baru untuk tujuan itu, saya akan dikurangi menjadi salah satu dari tiga opsi: baik mengembalikan perubahan dalam repo pusat, secara manual menjaga patch yang mengembalikannya di pohon kerja saya dan mencoba untuk tidak sengaja memeriksanya di , atau mundur ke versi sebelum bug itu diperkenalkan. Opsi pertama kemungkinan akan memutuskan beberapa ketergantungan lainnya. Opsi kedua adalah banyak pekerjaan, jadi kebanyakan orang memilih opsi ketiga, yang pada dasarnya mencegah Anda melakukan lebih banyak pekerjaan integrasi sampai bug yang ditemukan sebelumnya diperbaiki.

Contoh saya menggunakan cabang lokal pribadi, tetapi prinsip yang sama berlaku untuk cabang bersama. Jika saya berbagi cabang saya, maka mungkin 5 orang lain dapat melanjutkan tugas utama mereka alih-alih melakukan pekerjaan integrasi yang berlebihan, sehingga secara agregat pekerjaan integrasi yang lebih bermanfaat dilakukan. Masalah dengan percabangan dan integrasi berkelanjutan bukanlah berapa banyak cabang yang Anda miliki, tetapi seberapa sering Anda menggabungkannya.

pertanyaannya adalah apakah kita harus menggunakan cabang saat ini?

Sekitar setengah tahun yang lalu saya ditugaskan untuk melakukan studi untuk menjawab pertanyaan itu. Berikut ringkasannya, berdasarkan referensi yang dipelajari (tercantum di bawah)

• tidak ada strategi percabangan "terbaik" yang disepakati secara umum yang berlaku untuk proyek apa pun
  • sebagian besar sumber daya tampaknya setuju bahwa memilih strategi produktif tergantung pada spesifik proyek tertentu
  • catatan tambahan. Berdasarkan hal di atas, tampaknya perubahan strategi percabangan proyek perlu diuji, diukur, dan dibandingkan dengan opsi lain yang diuji
• Pendapat umum adalah bahwa bergabung dengan Subversion membutuhkan banyak upaya. Semua yang membandingkan SVN dan Git mencatat bahwa penggabungan secara kritis lebih mudah dengan Git
• faktor penting tampaknya adalah apakah rilis produksi berasal dari batang atau cabang. Tim yang melakukan rilis prod dari trunk (yang tampaknya bukan cara yang populer) pada dasarnya dilarang untuk menggunakan strategi trunk yang tidak stabil . Tim yang melakukan rilis produk dari cabang memiliki lebih banyak opsi cabang untuk dipilih.
• strategi populer tampaknya adalah batang yang stabil, batang yang tidak stabil dan cabang pengembangan (integrasi)

referensi

• 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://simpleprogrammer.com/2010/06/07/simple-branching-strategy-part-2-implementation/
      ... walk-through yang cukup rinci ...

• 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) ...

  • http://blog.perforce.com/blog/?p=1635
    Catatan kebijakan yang disarankan muncul mirip dengan cabang pengembangan seperti yang didefinisikan dalam http://www.infoq.com/articles/agile-version-control#q11 dan http : //msdn.microsoft.com/en-us/library/bb668955.aspx
  • Penjelasan model promosi: http://www.perforce.com/perforce/papers/life.html

• 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://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf
    "klasik" membaca - menjelaskan terminologi seperti Mainline Model , Codeline dll

• 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 ....

  • Agak menyerupai strategi pengembangan cabang sebagaimana didefinisikan dalam http://www.infoq.com/articles/agile-version-control#q11 dan http://msdn.microsoft.com/en-us/library/bb668955.aspx

• 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://www.eclipse.org/articles/article.php?file=Article-BranchingWithEclipseAndCVS/article1.html
  • http://www.eclipse.org/articles/article.php?file=Article-BranchingWithEclipseAndCVS/article2.html

• http://learnsoftwareprocesses.com/2007/12/29/common-branching-strategies/
  ... Berikut adalah beberapa model percabangan yang umum:  

  1. 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.  
  2. 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.  
  3. 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.  
  4. 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.  
  5. 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
    • Beberapa Cabang Praktik Terbaik - posting ke daftar Jenkins
    • Apakah mungkin untuk menangani banyak cabang di mana beberapa pekerjaan harus dijalankan pada masing-masing tanpa duplikasi - posting ke daftar Jenkins
    • Pengembangan Paralel dengan Cabang - posting ke daftar Jenkins
    • Konfigurasikan atau Buat Pekerjaan Hudson Secara Otomatis - stackoverflow.com
    • Integrasi Berkelanjutan dengan Pengembangan Beberapa Cabang - stackoverflow.com
    • Menangani Beberapa Cabang dalam Integrasi Berkelanjutan - stackoverflow.com
    • Integrasi berkelanjutan - Martin Fowler
    • Integrasi berkelanjutan - Wikipedia

• 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 ...

Jika Anda memiliki beberapa tim yang bekerja pada fitur yang berbeda pada saat yang sama, tidak mungkin Anda bisa menghilangkan percabangan. Anda harus membagikan kode (sebagian diimplementasikan) dengan anggota tim, mencegah tim lain mendapatkan fitur yang belum selesai.

Cabang adalah cara termudah untuk mencapai itu.

Meskipun itu baik untuk memperpendek siklus hidup cabang dan menghindari bekerja pada modul yang sama di dua cabang pada saat yang sama - Anda tidak akan memiliki konflik \ menggabungkan masalah saat itu.

Tetapi baru-baru ini saya melihat semakin banyak pengikut ide untuk tidak membuat cabang karena semakin sulit untuk mempraktikkan integrasi berkelanjutan, pengiriman berkelanjutan, dll.

Nah apakah itu membuat lebih sulit untuk mempraktikkan integrasi terus menerus, pengiriman terus menerus, dll untuk Anda secara konkret?

Jika tidak, saya tidak melihat alasan untuk mengubah cara Anda bekerja.

Tentu saja, ini adalah praktik yang baik untuk mengikuti apa yang terjadi dan bagaimana praktik terbaik saat ini berkembang. Tapi saya tidak berpikir kita perlu meninggalkan proses / alat / yang lainnya hanya karena X (dan / atau Y dan / atau Z) mengatakan mereka tidak iseng lagi :-)

Seperangkat jawaban yang menarik. Dalam 20+ tahun saya tidak pernah bekerja di perusahaan yang membuat lebih dari penggunaan percabangan yang sepele (Umumnya hanya untuk rilis cabang).

Sebagian besar tempat saya bekerja mengandalkan check-in yang cukup cepat dan deteksi / resolusi tabrakan yang cepat - Metodologi Agile mengajarkan bahwa Anda dapat menyelesaikan masalah dengan lebih cepat jika Anda melihatnya sementara kedua belah pihak secara aktif memikirkan potongan kode itu.

Di sisi lain, saya belum terlalu sering menggunakan git dan mungkin itu termasuk dari tag git yang mempengaruhi jawaban ini - saya mengerti bahwa branch / merge diberikan dengan git karena sangat mudah.

Ya, Anda harus menggunakan cabang untuk mengisolasi setiap upaya pengembangan (setidaknya sedang). Lihat " Kapan Anda harus bercabang? ".

Masalahnya lebih banyak menggunakan penggabungan maju-cepat (yang mencakup riwayat cabang di dalam yang lain), asalkan Anda menekan semua "komit pos pemeriksaan menengah" terlebih dahulu (yang bisa menjadi masalah jika mundur atau git bisect).
Lihat " Memahami alur kerja Git ", untuk membedakan cabang pribadi (tidak dimaksudkan untuk didorong) dari cabang publik, yang akan dilengkapi oleh penggabungan (penyambung cepat) asalkan Anda melakukan pembersihan yang diperlukan dalam cabang yang Anda gabungkan .
Lihat juga " Mengapa git menggunakan penggabungan maju-cepat secara default? ".

Anda harus benar-benar menggunakan cabang. Ada sejumlah kekuatan untuk itu.

• Anda dapat memeriksa pekerjaan Anda saat bepergian jika Anda khawatir kehilangan pekerjaan karena kegagalan HD, kehilangan laptop, dll. Dan itu tidak akan merusak CI utama.
• Anda masih dapat melakukan CI, cukup mengatur CI lokal Anda sendiri untuk menonton cabang Anda.
• Jika fitur tiba-tiba ditunda (itu tidak pernah terjadi, lakukan) Anda bisa memarkirnya.

Terlalu keras tidak pernah menjadi alasan. Selalu dibutuhkan lebih banyak upaya untuk melakukannya dengan benar.

Jika dua tim bekerja di cabang mereka sendiri, mereka tidak akan melihat perubahan tim lain, bahkan jika keduanya mengintegrasikan mastercabang. Itu berarti cabang pengembangan mereka akan terpisah dan jika salah satu tim bergabung master, tim lain harus mengubah banyak perubahan.

Jadi, bahkan jika Anda memiliki cabang untuk fitur, saya akan mendorong Anda untuk membuat 'backports' dari semua refactoring ke cabang master dan menjaga cabang hanya untuk fitur baru.

• Backport refactorings

Saya pikir kadang-kadang mungkin lebih mudah untuk menggunakan sakelar fitur untuk menonaktifkan fitur baru yang belum diuji yang belum masuk ke dalam produksi. Dengan begitu semua tim lain akan melihat perubahan dan tidak ada penggabungan big bang yang harus terjadi.

• Gunakan sakelar fitur

Kami baru saja melalui ini (lagi) .. Pertama kami memiliki seluruh debat GIT / SVN, yang mengarahkan kami ke strategi percabangan secara umum.

Semua perusahaan besar menggunakan strategi berbasis trunk, di mana setiap orang bekerja di cabang yang sama, dan pembangunan serta integrasi terus-menerus terjadi dari cabang itu. Menghindari konflik dilakukan dengan menggunakan modularisasi kode, pergantian fitur dan perkakas pintar. Ini terdengar sulit .. karena memang begitu. Tetapi jika Anda mengalami perdebatan ini, itu karena Anda telah menjadi korban fantasi orang tentang percabangan. Beberapa mengklaim bahwa mereka menggunakan alat SCM insert di sini dengan mekanisme percabangan promosi sepenuhnya sarbanes-oxley, dan semuanya brilian. Mereka berbohong, menipu diri sendiri, atau tidak bekerja pada skala sistem yang sama dengan Anda.

Bercabang dan menggabungkan itu sulit. Terutama jika Anda memiliki bisnis yang secara teratur berubah pikiran, dan menuntut kemunduran dll.

Kalimat ini dapat menyelamatkan hidup Anda: Apa yang ada di SCM tidak sama dengan apa yang ada di artefak buatan Anda!

Jika Anda mengalami masalah dengan percabangan itu karena Anda menyalahgunakan SCM Anda. Kita semua sudah melakukannya selama bertahun-tahun. Anda memiliki sistem di mana SCM digunakan untuk menentukan apa yang masuk ke bangunan final Anda.

Itu bukan pekerjaan SCM. SCM adalah server file yang dimuliakan. Pekerjaan menentukan file mana dari SCM Anda yang masuk ke build Anda adalah milik build tooling Anda.

Modul A sedang dikerjakan dan masuk ke rilis mingguan Anda. Modul B adalah modul A tetapi dengan proyek X di dalamnya, dan sedang dikerjakan, di cabang yang sama, tetapi tidak dibangun ke dalam rilis Anda. Di beberapa titik di masa depan Anda ingin melepaskan proyek X. Jadi, Anda memberi tahu alat pengembangan Anda untuk berhenti memasukkan modul A, dan mulai memasukkan modul B.

Akan ada banyak tangisan dan meremas-remas tangan tentang ini. Bagaimana iffery, dan melolong umum. Begitulah tingkat emosi yang mengelilingi sesuatu yang sederhana seperti repositori file, tidak peduli seberapa pintar.

Tapi ada jawaban Anda.

Masalah utama dengan percabangan adalah kesulitan untuk menggabungkan kembali ke cabang utama ketika pengembangan selesai. Penggabungan dapat menjadi proses manual dan rawan kesalahan karena itu harus dihindari sebagian besar waktu.

Beberapa pengecualian penting di mana saya lebih suka bercabang adalah untuk refactoring besar-besaran, fitur raksasa yang membutuhkan waktu lebih lama daripada sprint untuk dikembangkan, atau fitur mengganggu yang akan menghambat pengembangan fitur lain selama sebagian besar sprint itu.

Saya merekomendasikan skema cabang semacam ini:

rilis - tes - pengembangan

Kemudian dari pengembangan, cabang oleh pengembang dan / atau oleh fitur.

Masing-masing pengembang memiliki cabang untuk bermain, dan bergabung dari, dan kemudian masuk ke cabang pengembangan secara rutin - idealnya setiap hari (menyediakannya dikompilasi).

Skema semacam ini bekerja sangat baik dengan banyak pengembang dan beberapa proyek pada basis kode yang sama.

Kami memang menggunakan cabang, tetapi tidak pada tingkat fitur granular. Kami menggunakan cabang untuk setiap sprint. Bercabang pada dasarnya bukan hal yang buruk IMO, karena mensimulasikan konsep SOC dalam fitur, atau lapisan sprint. Anda dapat dengan mudah mengenali dan mengelola cabang mana yang termasuk fitur atau sprint mana.

IMHO, maka jawabannya adalah, YA . Kita masih harus menggunakan percabangan.

Proses di organisasi saya menggunakan cabang secara ekstensif dan (sebuah proses yang terlihat seperti) integrasi berkelanjutan.

Pada tampilan tingkat tinggi, pengembang tidak terlalu khawatir tentang penggabungan dengan arus utama, mereka hanya berkomitmen pada cabang. a (semi-) proses otomatis memeriksa fitur apa yang dijadwalkan masuk ke jalur utama, menggabungkan cabang-cabang itu dan membuat produk. Proses ini berfungsi karena kami benar-benar mengintegrasikan proses penggabungan dari pelacak masalah ini, sehingga alat build tahu cabang apa yang akan digabung.