Şubeye veya şubeye değil mi?

Yakın zamana kadar geliştirme iş akışım şuydu:

1. Özelliği ürün sahibinden alın
2. Şube yapın (özellik 1 günden fazla ise)
3. Bir dalda uygulamak
4. Ana şubeden şubemdeki değişiklikleri birleştirme (geriye doğru birleşme sırasındaki çatışmaları azaltmak için)
5. Şubemi ana şubeye dön

Bazen birleşme sorunları vardı, ama genel olarak hoşuma gitti.

Ancak son zamanlarda sürekli entegrasyon, sürekli teslimat vb. Uygulamalarını zorlaştırdığı için şubeleri yapmama fikrinin giderek daha fazla takipçisi olduğunu görüyorum. Git, Mercurial, vb.

Öyleyse soru şu ki, bugünlerde şubeler kullanmalı mıyız?

Eğer hepsi aynı çalışma ağacından çalışıyoruz sürece, olan o diyoruz olsun ya da olmasın, dalları kullanarak. Bir geliştirici çalışma ağacını her kontrol ettiğinde, ayrı bir yerel gelişim alanı oluşturur ve kontrol ettiği her seferde bir birleşme yapar. En ekipleri için, soru değil eğer sen dalları kullanın sorulardır kaç ve ne amaçla ?

Gerçekten "sürekli" entegrasyon yapmanın tek yolu, herkesin aynı çalışma ağacından çıkmasıdır. Bu şekilde, yaptığınız değişikliklerin başkasının değerini olumsuz yönde etkileyip etkilemediğini hemen anlarsınız. Açıkçası, bu düşünülemez. Bir şeyi başarmak için bir dalda belirli bir izolasyon derecesine ihtiyacınız vardır, bu "dal" yalnızca yerel çalışma diziniz olsa bile. Gereken şey uygun bir entegrasyon ve izolasyon dengesidir.

Tecrübelerime göre, daha fazla branş kullanmak entegrasyon derecesini arttırır , çünkü entegrasyon tam olarak yapılması gereken insanlarla yapılır ve diğer herkes ilgili olmayan problemleri gerektiği gibi daha kolay izole edebilir.

Örneğin, son günümüzü yapmamızda "gerçek" çalışmamı engelleyen üç yeni entegrasyonla ilgili hata tespit ederek geçirdim. Bu hataları, düzeltilmesi gereken kişilere bildirmedeki titizliğimi yaptıktan sonra, şimdi çalışmamı sürdürmek için bitinceye kadar beklemem gerekiyor mu? Tabii ki değil. Bu değişiklikleri geri alan geçici bir yerel şube yarattım, böylece yukarı akıştan en son değişiklikleri alırken, üzerinde çalışacak istikrarlı bir taban çizgisine sahip olabiliyorum.

Bu amaçla yeni bir şube oluşturma kabiliyeti olmasaydı, üç seçenekten birine düşürülecektim: ya merkezi repodaki değişiklikleri geri al, onları çalışan ağacımda geri döndüren yamaları manuel olarak tut ve onları yanlışlıkla kontrol etmemeye çalış , veya bu hataların ortaya çıkmasından önce bir sürüme dönün. İlk seçeneğin başka bir bağımlılığı kırması muhtemel. İkinci seçenek çok çalışmadır, bu nedenle çoğu insan üçüncü seçeneği seçer; bu, daha önce bulunan hatalar giderilene kadar daha fazla entegrasyon çalışması yapmanıza engel olur.

Örneğim özel bir yerel şube kullandı, ancak aynı prensip paylaşılan şubeler için de geçerli. Şubemi paylaşırsam, belki 5 kişi gereksiz entegrasyon çalışması yerine birincil görevlerine devam edebilir, böylece toplu olarak daha faydalı entegrasyon çalışmaları yapılır. Dallanma ve sürekli entegrasyonla ilgili sorun, kaç dalınız olduğunu değil, ne kadar sıklıkla birleştirdiğinizdir.

soru bugünlerde dalları kullanmalı mıyız?

Yaklaşık yarım yıl önce, bu soruyu cevaplamak için bir çalışma yapmak üzere görevlendirildim. İşte çalışılan referanslara göre özet (aşağıda listelenmiştir)

• Herhangi bir projeye uygulanabilir yaygın olarak kabul edilmiş "en iyi" dallanma stratejisi yoktur
  • Kaynakların çoğu, üretken strateji seçmenin belirli proje özelliklerine bağlı olduğunu kabul ediyor gibi görünmektedir.
  • kenar notu. Yukarıdakilere dayanarak, proje dallanma stratejisindeki herhangi bir değişikliğin test edilmesi, ölçülmesi ve test edilen diğer seçeneklerle karşılaştırılması gerektiği gibi görünüyor.
• popüler görüş, Subversion ile birleşmenin çok çaba harcadığı yönünde. SVN ve Git’i karşılaştıran herkes Git’le birleşmenin kritik derecede kolay olduğunu not ediyor.
• önemli bir faktör üretim bültenlerinin gövdeden mi dallardan mı kaynaklandığı gibi görünüyor. Bagajdan prod serbest bırakan takımlar (oldukça popüler bir yol gibi görünmüyor) esas olarak dengesiz gövde stratejisini kullanmak yasaktır . Şubelerden ürün bültenleri yapan ekipler, aralarından seçim yapabileceğiniz daha fazla dallanma seçeneğine sahiptir.
• popüler stratejiler istikrarlı bir ana hat, dengesiz ana hat ve gelişme (entegrasyon) dalı gibi görünmektedir

Referanslar

• http://msdn.microsoft.com/en-us/library/aa730834%28v=vs.80%29.aspx
  

  ... En iyi dallanma stratejisine karar vermek dengeleyici bir eylemdir. Artan riske karşı verimlilik kazancınızı arttırmalısınız Seçilen bir stratejiyi doğrulamanın bir yolu, bir değişim senaryosunu dikkate almaktır. Örneğin, dalları sistem mimarisiyle hizalamaya karar verirseniz (örneğin, bir dal sistem bileşenini temsil eder) ve önemli mimari değişiklikler beklerseniz, şubelerinizi ve her bir değişiklikle ilgili işlemlerinizi ve politikalarınızı yeniden yapılandırmanız gerekebilir. Yetersiz bir dallanma stratejisi seçmek, genel masraflara ve uzun süreli entegrasyona neden olabilir ve tüm ekip için sinir bozucu olan serbest bırakma döngüleri ...

• http://www.cmcrossroads.com/bradapp/acme/branching/
  

  ... Sık sık, artımlı entegrasyon başarının işaretlerinden biridir ve yokluğu genellikle başarısızlığın bir özelliğidir. Mevcut proje yönetimi yöntemleri, katı şelale modellerinden kaçınma ve yinelemeli / artımlı gelişim ve evrimsel teslimin spiral benzeri modellerini benimseme eğilimindedir. Merge Early ve Often ve varyantları gibi artımlı entegrasyon stratejileri, buna yanıt verecek daha fazla zaman olduğunda yaşam döngüsünün başlarında riski ortadan kaldırmaya çalışan bir risk yönetimi şeklidir. Entegrasyonlar arasındaki ritmin düzenliliği, proje sağlığının öncü bir göstergesi olarak [Booch], [McCarthy] ve [McConnell] tarafından görülür ("nabız" veya "kalp atışı" gibi).  
   
  Sadece erken ve sık entegrasyon değil, aynı zamanda daha erken ve daha küçük "parçalarda" riski de ortadan kaldırmaz, aynı zamanda takım arkadaşları arasındaki değişiklikleri iletir

• http://www.codinghorror.com/blog/2007/10/software-branching-and-parallel-universes.html
  

  ... Çoğu kaynak kontrol sisteminde, performans sorunu olmayan yüzlerce şube oluşturabilirsiniz; Gerçekten endişelenmen gereken tüm dalları takip etmenin zihinsel yükü ... Dallanma karmaşık bir canavar. Dallanmanın düzinelerce yolu var ve doğru veya yanlış yaptığınızı kimse size söyleyemez ...

• http://www.lostechies.com/blogs/derickbailey/archive/2010/02/24/branching-strategies-when-to-branch-and-merge.aspx
  

  ... Kodunuzu dallarken göz önünde bulundurulması gereken bir çok nokta var ... Sonunda amaç, kodun yazıldığı bağlam için bir sanal alan sağlamaktır. Mevcut seçeneklerin anlaşılması, her bir seçenek eldeki duruma en uygun olduğunda ve bu seçeneklerin maliyeti, nasıl ve ne zaman şube açılacağına karar vermenize yardımcı olur ...

• http://www.snuffybear.com/ucm_branch.htm
  Burada listelenen diğer referansları not edin , yazarın "Bu makale, Yazılım Mühendisliği projelerinde kullanılan üç anahtar dallanma modelini açıklar" iddiasında bulunmadığını iddia ediyor . Kullanılan terminoloji yaygın görünmüyor ( EFIX , Model-1,2,3 vb.).

• http://svn.haxx.se/users/archive-2007-10/att-0101/SCMBranchingModels-talkback.pdf
  Referans, dallanma stratejilerini ifade eden zorluklara ilginç bir örnek sunar.

• http://simpleprogrammer.com/2010/06/04/simple-branching-strategy-part-1-back-to-basics/
  ... Basit tutun. Doğrudan bagajdan çalışmak, bence en iyi yaklaşım.  
   
  Ekranıma yazdığımda neredeyse sapkınlık gibi geliyor, ama bir anlığına yanımda olacaksanız, bunun neden Çevik bir işlem için gerekli olduğunu düşündüğümü göstermeyeceğim, ama size bunun nasıl olacağını göstereceğim çalışmasını sağlamak için ...  
   
  ... akıl yürütmemi sağlam bir argümana dayandırmak zorunda olsaydım, sürekli bütünleşmenin değeri olurdu. Ben blogged hakkında CI değeri ve en iyi uygulamaların geçmişte. Ben CI'nin oldukça büyük bir savunucusuyum.  
   
  ... burada gerçekten kendinize bir soru sormak zorundasınız: "Karmaşık dallanma ve birleştirme stratejinizi gerçekleştirmekten kaynaklanan tüm masraflar, daha basit bir stratejide bulunmayan gerçek bir değere neden oluyor mu?" ...  
   
  .. . Geçmişte etkili bir şekilde kullandığım ve zaman içinde geliştiğim bir strateji. Burada kısaca özetleyeceğim.

  • Herkes bagajda çalışıyor.
  • Kodu serbest bıraktığınızda şube.
  • Zaten yayımlanan kod için bir hata düzeltmesi oluşturmanız gerektiğinde, bir yayını dağıtın.
  • Prototip için şube.
    ...
    • http://simpleprogrammer.com/2010/06/07/simple-branching-strategy-part-2-implementation/
      ... oldukça detaylı gözden geçirme ...

• http://www.codelathe.com/blog/index.php/2009/07/02/a-svn-branching-strategy-that-works/
  ... Son olarak, ideal bir dallanma ve birleştirme stratejisi olmadığını unutmayın. Neredeyse eşsiz gelişim ortamınıza bağlı ...

• http://blog.perforce.com/blog/?cat=62
  ... En kötü durum senaryosu, otomatik bir birleştirme sonucunun yanlış olduğu, ancak tamamlandığı ve geçmişe gizlice girdiği bir "anlamsal birleştirme" sorunu oluşturmanızdır. Test, muhtemelen müşteri tarafından görülebilen bir hata olacak kadar uzun süre hayatta kalmak. Eek!  
   
  Yaralanmaya hakaret ekleme, saptamanın daha uzun süre kalabilmesi nedeniyle, semantik birleştirme sorunlarının daha sonra düzeltilmesi daha zordur, çünkü değişiklik, değişimin kaynağı olan geliştiricinin aklında artık taze değildir. (Genellikle değişiklikleri yaptıktan hemen sonra birleştirmek en iyisidir, ideal olarak bu değişikliği uygulayan geliştirici tarafından uygulanabilirse) ...

  • http://blog.perforce.com/blog/?p=1635
    Not önerilen politika , http://www.infoq.com/articles/agile-version-control#q11 ve http de tanımlandığı gibi geliştirme dalına benzer göründüğünü unutmayın. : //msdn.microsoft.com/en-us/library/bb668955.aspx
  • Tanıtım modeli açıklaması: http://www.perforce.com/perforce/papers/life.html

• https://stackoverflow.com/questions/34975/branching-strategies
  Topluluk üyeleri, çeşitli dallanma stratejileri kullanarak çeşitli projelerdeki farklı deneyimleri paylaşırlar. "En iyi" ya da "en kötüsü" konusunda mutabakata varılan bir fikir birliği yok.

  • http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf
    "klasik" okuma - Mainline Model , Codeline vb. gibi terimler açıklandı.

• http://www.stickyminds.com/s.asp?F=S16454_COL_2
  Temel olarak http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf adresinde sunulan şeylerin kısa bir özeti

  • http://www.stickyminds.com/s.asp?F=S16511_COL_2
    ... Ne zaman ve nasıl dallanacağına karar vermek için üç genel yaklaşım vardır:
    • "Özellik tamamlandı" dığınızda yayın dalını oluşturun ve bu kod satırındaki son dakika sorunlarını düzeltmeyi planlayın. Bu durumda, sürüm şubesi, gerçekten yapılacak bir çalışma olmasını beklediğinizden, Yazılım Yapılandırma Yönetimi Modelleri'nde açıklandığı gibi gerçekten bir "sürüm hazırlığı kod satırı" dır.
    • Aktif entegrasyon çizgisinde çalışarak nihai entegrasyon çalışmasını önlemek için çalışma tarzınızı değiştirin.
    • Yeni iş için şube görev dalı oluşturarak ve bu işi serbest bıraktıktan sonra aktif gelişim hattına dahil ederek birleştirin.
      ... Dallanma için bir gerekçe, sürüm sonunda kodu sabitlemek için yalıtmaktır. Dallanma yoluyla izolasyon, çoğu zaman, bir ürün piyasaya sürülmeden önce paralel akışları sürdürmenin ek maliyetinde kendini gösteren bir kalite problemini maskeler. Dallanma kolaydır. Daha ziyade, dalları zorla değiştiren dalların nasıl değiştiğini anlamak birleşme ve bilişsel yüküdür, bu nedenle dallanma ve birleşme maliyetini en aza indiren bir süreç seçmek önemlidir ...

• http://nvie.com/posts/a-successful-git-branching-model/ Git odaklı strateji.
  ... menşei / master'ı , HEAD'ın kaynak kodunun her zaman üretime hazır bir durumu yansıttığı ana şube olarak görüyoruz .  
   
  Biz düşünün köken / geliştirmek HEAD kaynak kodu her zaman bir sonraki sürüm için son teslim geliştirme değişiklikleriyle bir durumunu yansıtır ana dal olmak. Bazıları buna "entegrasyon kolu" diyebilirdi. Herhangi bir otomatik gece inşası inşa edildiği yer burasıdır ....

  • Http://www.infoq.com/articles/agile-version-control#q11 ve http://msdn.microsoft.com/en-us/library/bb668955.aspx adresinde tanımlandığı gibi geliştirme dalı stratejisine biraz benziyor

• http://svnbook.red-bean.com/en/1.5/svn.branchmerge.html
  ... proje politikaları, bir özellik dalı oluşturmanın uygun olduğu durumlarda tam olarak değişkenlik gösterir. Bazı projeler hiçbir zaman özellik dalı kullanmaz: taahhüt / trunk herkes için ücretsizdir. Bu sistemin avantajı basit olmasıdır - kimsenin dallanma veya birleşme hakkında bilgi sahibi olması gerekmez. Dezavantajı, gövde kodunun genellikle kararsız veya kullanılamaz olmasıdır. Diğer projeler şubeleri aşırı derecede kullanır: hiçbir zaman doğrudan bagajda değişiklik yapılmaz . En önemsiz değişiklikler bile kısa ömürlü bir dalda yaratılır, dikkatlice incelenir ve bagajla birleştirilir. Daha sonra dal silinir. Bu sistem her zaman istisnai olarak istikrarlı ve kullanılabilir bir gövdeyi garanti eder, ancak çok pahalıya mal edergenel gider.  
   
  Çoğu proje yolun ortasında bir yaklaşıma sahip. Genelde / trunk'un derleme ve her zaman regresyon testlerini geçme konusunda ısrar ediyorlar . Bir özellik dalı yalnızca bir değişiklik çok sayıda kararsızlaştırıcı taahhüt gerektirdiğinde gerekir. Bu soruyu sormak iyi bir kuraldır: Eğer geliştirici günlerce tecrit altında çalışıyorsa ve sonra büyük değişikliği bir kerede yaptıysa (ki / trunk asla dengesizleştirildiyse), gözden geçirmek için çok büyük bir değişiklik olur mu? Bu sorunun cevabı "evet" ise, değişiklik bir özellik dalında geliştirilmelidir. Geliştirici şubeye artımlı değişiklikler yaptığında, meslektaşları tarafından kolayca incelenebilir.  
   
  Son olarak, çalışma ilerledikçe bir özellik dalının gövde ile "senkronizasyonda" en iyi şekilde nasıl tutulacağı sorunu var. Daha önce de belirttiğimiz gibi, bir dalda haftalarca ya da aylarca çalışmak büyük bir risk; ana hat değişiklikleri, iki gelişme çizgisinin o kadar büyük farklılıklar gösterdiği noktaya kadar dökülmeye devam edebilir ki, şubeyi tekrar gövdeye birleştirmeye çalışan bir kabus olabilir.  
   
  Bu durum en iyi şekilde daldaki gövde değişikliklerini birleştirerek önlenir. Politika oluştur: haftada bir kez, şubenin son haftasında yapılan gövde değişikliklerini birleştir ...

• http://thedesignspace.net/MT2archives/000680.html
  ... Eclipse CVS eğitiminin bu bölümü, Eclipse web sitesindeki Paul Glezen'in makalesine dayanmaktadır: Eclipse ve CVS ile Dallanma ve bu koşullar altındaki izni ile kullanılmaktadır. EPL lisansı. Sürümünde yaptığım değişiklikler, daha çok adım adım görseller ve açıklamalar ile genişletmek ve yeni başlayanlar ve tasarımcılar için daha erişilebilir hale getirmek amacıyla onu başlangıç ​​seviyesindeki eğitmenlerimle bütünleştirmek. Deneyimli geliştiriciler muhtemelen Paul'ün sürümünden çalışmayı tercih edecektir

  • 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/
  ... Yaygın dallanma modellerinden bazıları:  

  1. Şube Bazında Model: En yaygın dallanma stratejilerinden biri şubeleri ürün bültenleri ile uyumlu hale getirmektir. Bir şube, tüm yazılım geliştirme varlıklarını tek bir sürüm için tutar. Nadiren, güncellemelerin bir sürümden diğerine birleştirilmesi gerekir, ancak genellikle hiçbir zaman birleştirilmezler. Bir serbest bırakma emekli olduğunda şubeler durdurulur.  
  2. Promosyon Başına Şube: Yaygın olarak kullanılan diğer bir yaklaşım da dalları yazılım varlıklarının tanıtım düzeyleriyle aynı seviyeye getirmek. Özel bir geliştirme sürümü tüm entegrasyon ve sistem testlerinin gerçekleştirildiği bir Test dalına ayrılmıştır. Testi tamamladığınızda, yazılım geliştirme varlıkları Üretim dalına ayrılır ve sonuçta dağıtılır.  
  3. Görev Başına Şube: Üst üste binen görevleri (veya etkinlikleri) ve verimlilik kaybını önlemek için, bunları ayrı bir dalda izole edebilirsiniz. Bunların, görev tamamlanır tamamlanmaz birleştirilmesi gereken kısa vadeli şubeler olduklarını unutmayın, aksi takdirde gereken birleştirme çabası, ilk başta onları yaratmanın verimlilik avantajlarını aşabilir.  
  4. Bileşen Başına Dal: Her dalı sistem mimarisiyle hizalayabilirsiniz. Bu stratejide, tek tek bileşenleri (veya alt sistemleri) ayırırsınız. Daha sonra, bir bileşen geliştiren her ekip, kodlarını ne zaman bütünleştirme kolu olarak hizmet veren geliştirme hattına ne zaman birleştireceklerine karar verir. Bu strateji, sistem mimarisi yerinde olduğunda ve her bir bileşen iyi tanımlanmış arayüzlere sahipse işe yarayabilir. Branşlar üzerinde bileşen geliştirmeniz, yazılım geliştirme varlıkları üzerinde daha hassas kontrol sağlamanızı sağlar.  
  5. Teknoloji Başına Dal: Sistem mimarisine uygun başka bir dallanma stratejisi. Bu durumda dallar teknoloji platformlarına hizalanır. Ortak kod ayrı bir dalda yönetilir. Şubelerde yönetilen yazılım geliştirme varlıklarının kendine özgü doğası nedeniyle, muhtemelen asla birleşmezler ...

• http://msdn.microsoft.com/en-us/library/bb668955.aspx
  ... Dallanma ve birleştirme kılavuzlarının özeti için bu kılavuzdaki "Kaynak Kontrol Kılavuzları" bölümündeki dallanma ve birleştirme kılavuzlarına bakın. ... Dallanırken aşağıdakileri göz önünde bulundurun:

  • Geliştirme ekibinizin aynı anda aynı dosya kümesinde çalışması gerekmiyorsa şube olmayın. Bundan emin değilseniz, bir derlemeyi etiketleyebilir ve bu derlemeden daha sonra bir dal oluşturabilirsiniz. Dalları birleştirmek, özellikle aralarında önemli değişiklikler olması durumunda zaman alıcı ve karmaşık olabilir.
  • Şube ağaçlarınızı, hiyerarşi boyunca değil, yalnızca hiyerarşi boyunca (dal ağacı aşağı ve yukarı) birleştirmeniz gerekir. Hiyerarşi içinde dallanma, daha fazla manuel çatışma çözümü gerektiren temelsiz bir birleştirme kullanmanızı gerektirir.
  • Şube hiyerarşisi, diskteki kaynak kodun fiziksel yapısından farklı olabilen şube ebeveyni ve şube çocuğunu temel alır. Birleştirmelerinizi planlarken, diskteki fiziksel yapı yerine mantıksal dal yapısını unutmayın.
  • Çok fazla dallanma. Her bir birleştirme ve çakışmaları çözme zaman aldığından, derin bir dallanma yapısı, bir çocuk dalındaki değişikliklerin ana dallara yayılmasının çok uzun zaman alabileceği anlamına gelebilir. Bu, proje programlarını olumsuz yönde etkileyebilir ve hataları düzeltmek için gereken zamanı artırabilir.
  • Şube yüksek düzeyde ve yapılandırma ve kaynak dosyaları içerir.
  • Dallanma yapınızı zamanla geliştirin.
  • Birleştirme, birleştirme işlemini yürütmek ve çakışmaları çözmek için bir veya daha fazla geliştirici gerektirir. Birleştirilen kaynak tamamen test edilmelidir, çünkü yapıyı dengesizleştirebilecek kötü birleştirme kararları almak nadir değildir.
  • Şube hiyerarşisinde birleştirmek özellikle zordur ve aksi takdirde otomatik olarak ele alınabilecek birçok uyuşmazlığı manuel olarak ele almanızı gerektirir.  
    Şube oluşturup yaratmama kararı, gerçek zamanlı olarak birleşme çatışmalarının maliyetinin, şubeler arasında birleşme çatışmalarının genel giderinden daha yüksek olup olmadığına düşürülebilir ...

• 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-f-subversion/
    ... Bu Subversion şikayetlerinden herhangi biri tanıdık geliyor mu?
    • Rasgele "güncellemeyi çalıştırmanız gerekir" talimatı verilir. Daha sonra bir güncelleme yapın. Ve sonra, nihayet, indirilmesi gereken bir değişiklik olmadığını görüyorsunuz.
    • Rasgele "temizliği çalıştırmanız gerekir" talimatı verilir.
    • Çok büyük bir birleşme problemin var. Örneğin, bir sınıfı yeniden adlandırmak için ReSharper kullanın ve bu arada bir kısmı da bu sınıfı güncelledi. Daha sonra korkunç ağaç çakışması hatasını görüyorsunuz (titreme). Daha da kötüsü, tüm bir ad alanını ve klasörü yeniden adlandırırsınız (çift titreme). Şimdi gerçekten acı dolu bir dünya için varsın.
    • Birleşmeleriniz gittikçe daha fazla elle olma eğilimindedir. Subversion'ın bir ipucu olmadığı için sık sık WinMerge kullanmanız gerekir.
    • Genellikle Kaplumbağa'nın değişiklikleri / bir şeyleri güncellemesini / kontrol etmesini bekliyorsunuz.  
       
      USB kalem sürücümde bir subversion deposu var. Ağaç çatışması alıyorum ve bununla ilgili sorunları birleştiriyorum ve tek kullanıcı benim!  
       
      Asıl sorun birleşme ...  
       
  • "Yıkılma berbat" tanıdık geliyor. Joel ve Linus'u dinleme zamanı geldi mi?

• http://social.msdn.microsoft.com/Forums/en/tfsversioncontrol/thread/f127676c-8f05-410c-9a30-0eb43a26a9fa
  , gelişen sistemler için salınım izolasyonu dallanma stratejisi için en iyi uygulamanın tartışılması.

• http://branchingguidance.codeplex.com/
  "Microsoft Team Foundation Server Branching Guidance" - farklı projelere uyarlanmış önerileri olan çok büyük ve ayrıntılı bir belge: burada HTML sürümü . Microsoft'un tek bedene uyan her şeye dallanma stratejilerine inanmadığını kanıtlar.

• https://stackoverflow.com/questions/597707/best-branching-strategy-when-doing-continuous-integration
  Sürekli entegrasyon yapmak istediğinizde kullanmak için en iyi dallanma stratejisi nedir? ... Cevap ekibinizin büyüklüğüne ve kaynak kontrolünüzün kalitesine ve karmaşık değişiklik kümelerini doğru şekilde birleştirme yeteneğine ...

  • http://www.zeroturnaround.com/blog/continuous-integration-and-feature-branches/ Hudson / Jenkins ile ilgili somut deneyimlere dayanarak sürekli entegrasyonla dallanma etkileşiminin daha ayrıntılı analizi - birkaç faydalı referansla birlikte
    . En büyük keşif, CI'nın sık sık geri bildirimde bulunmak, zorlamak ve geri bildirim almakla ilgili olmasına rağmen (yani, CI kümesi iş istasyonunuzun aynı miktarda size asla veremeyeceği geri bildirimi sağlar), gerçekte gerçek bir safha CI'in bir ihtiyacı daha var. - ekibin aynı temelde çalışması gerekiyor ...
    Kullanılan malzemeler
    • Birden Çok Dallı En İyi Uygulama - Jenkins listesine gönderim
    • Bazı işlerin çoğaltılmadan her biri üzerinde çalışması gereken birden fazla şubeyi idare etmek mümkün müdür - Jenkins listesine gönder
    • Dallarla Paralel Gelişim - Jenkins listesine gönderim
    • Hudson Job'u Otomatik Olarak Yapılandırma veya Oluşturma - stackoverflow.com
    • Çoklu Şube Geliştirme ile Sürekli Entegrasyon - stackoverflow.com
    • Sürekli Entegrasyonda Birden Fazla Şube Kullanarak - stackoverflow.com
    • Sürekli entegrasyon - Martin Fowler
    • Sürekli entegrasyon - Vikipedi

• http://codicesoftware.blogspot.com/2010/03/branching-strategies.html
  ... CVS ve SVN, tamamen yapamadıkları için bütün dallanma / birleşme stratejisini caydırıyorlardı ... ... Basit kural: Uygulamanız gereken her yeni özellik veya hata düzeltmesi için bir görev dalı oluşturun ... SVN / CVS kullanıcıları için fazladan bir kulağa benzeyebilir, ancak herhangi bir modern SCM'nin bir saniyede şube oluşturmanıza izin vereceğini biliyorsunuz, bu nedenle gerçek bir ek yük yok.  
   
  Önemli not: Dikkatlice bakarsanız, görev dallarını zengin adam değişmezleri olarak kullanmaktan bahsettiğimi göreceksiniz ...

• http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.cc_proj.doc/c_bntr_plnbrstrat.htm
  ... Dallanma politikası gelişmeden etkilenir Projenin amacı ve kod tabanının gelişimini kontrol etmek için bir mekanizma sağlar. Rational ClearCase sürüm kontrolünü kullanan organizasyonlar kadar çok sayıda branş politikası vardır. Ancak, en iyi uygulamalara ortak bağlılığı yansıtan benzerlikler de var ...

• http://blogs.open.collab.net/svn/2007/11/branching-strat.html
  ... Subversion modeli (veya genel açık kaynak modeli daha doğru) kararsız ana hat modelinde gösterilen şeydir .. .

• http://en.wikipedia.org/wiki/Trunk_%28software%29
  Yazılım geliştirme alanında, gövde revizyon kontrolü altındaki bir dosya ağacının adsız dalına (versiyonuna) atıfta bulunur . Gövde genellikle gelişimin devam ettiği bir projenin temeli olarak düşünülüyor. Geliştiriciler yalnızca gövde üzerinde çalışıyorsa, projenin her zaman en yeni sürümünü içerir, ancak bu nedenle en dengesiz sürüm de olabilir. Diğer bir yaklaşım, bir dalın gövdeden ayrılması, o dalda değişiklikler yapılması ve dalın kararlı ve çalıştığı kanıtlandığında değişiklikleri tekrar bagaja birleştirmektir. Geliştirme moduna bağlı kal ve bağlı kalİlke, gövde en sağlam veya en az kararlı olan veya arada bir modeli içerebilir.  
   
  Çoğunlukla ana geliştirici çalışmaları bagajda gerçekleşir ve kararlı sürümleri dallanır ve zaman zaman hata düzeltmeleri şubelerden gövdeye birleştirilir. Gelecekteki sürümlerin gövde dışı branşlarda gelişimi yapıldığında, genellikle sıklıkla değişmeyen projeler için veya bir değişimin, bagaja dahil olmaya hazır olana kadar gelişmesi uzun zaman alacağı yerlerde yapılır. .

• http://www.mcqueeney.com/roller/page/tom/20060919
  ... Bunlar, 30 Ağustos 2006 tarihinde CollabNet tarafından yapılan Subversion en iyi uygulamaları hakkında bir web seminerinden gelen notlar . ... İki organizasyon stratejisi: kararsız bagaja karşı istikrarlı bagaj ... ... mümkün olduğunda kararsız bir bagaja HAZIRLANIN ...

• https://stackoverflow.com/questions/153812/subversion-is-trunk-really-the-best-place-for-the-main-development
  SVN'de ana geliştirme için gövde tavsiye edilir ve bu sözleşmeyi kullanırım tüm projelerim için. Bununla birlikte, bu, bagajın bazen dengesiz olduğu veya hatta kırıldığı anlamına gelir ... ... / branch / dev gibi bazı dallarda "vahşi gelişme" yapmak daha iyi olmaz ve yalnızca yapı makul olduğunda bagajla birleştirilir. katı?

  • ... Gövde devam eden gelişimin gerçekleşmesi gereken yerdir. Herkes değişiklik yapmadan önce değişikliklerini test ediyorsa, gerçekten "bozuk" kodla ilgili bir sorun yaşamamalısınız. Değişikliklerinizi kodladıktan sonra bir güncelleme yapmak (depolardaki en yeni kodu almak) için iyi bir kuraldır. Ardından bazı ünite testleri yapın ve yapın. Her şey oluşur ve çalışırsa, kontrol etmeniz iyi olur ...
  • ... Hayır gövde, en iyi yer değil. Kuruluşumuzda daima bu yaklaşımı izleriz: Trunk sürüm kodu içerir, bu yüzden her zaman derler. Her yeni sürüm / dönüm noktası ile birlikte yeni bir şube açıyoruz. Bir geliştirici ne zaman bir öğeye sahipse, bu yayın dalına yeni bir dal oluşturur ve yalnızca test ettikten sonra bir yayın dalına birleştirir. Bırakma kolu sistem testinden sonra bagaja birleştirilir ...

• http://blog.yclian.com/2009/03/working-on-branches-and-stable-trunk.html
  ... Çalıştığım tüm projeler için sandıkta çalışırdım tek geliştirici veya ekip, herkesin kod girişini yerel testlerden geçmesini sağlamıştır. Aksi halde hata düzeltmeleri için şubeler yarattık (yeni özellikler için büyük kodlar vs.).  
   
  Yaklaşık 2 ay önce Kamal'la kısa bir git seans yaptım ve benimle hikaye / dal fikrini paylaştı . Ekibim daha dev erkeklerle birlikte büyümeye başladığında, daha fazla dallanmayı teşvik etme ihtiyacım olduğunu hissediyorum ve şimdi bu bir kural haline geldi. CI kurulumu ile tanımlanan otomatik testlere sahip bir proje için, sabit bir gövde garanti edilir ve bu uygulama buna çok iyi uyum sağlayabilir.  
   
  Git'i kullanmıyoruz ama Subversion, çünkü böyle başladık ve şu anda hala rahatız (çoğu zaman) ...

• http://www.ericsink.com/scm/scm_branches.html
  Bu, Source Control HOWTO adlı , kaynak kontrolü, sürüm kontrolü ve konfigürasyon yönetimi hakkında en iyi uygulamalar rehberi olan çevrimiçi bir kitabın parçasıdır ...  
   
  ... Eric'in Tercih Edilen Dallanması Pratik ... Bir "temelde dengesiz" bir gövde tutun. Aktif gelişiminizi bagaja sürün ve stabilite serbest bırakıldıkça artar. Gemiden sonra, bir bakım kolu yaratın ve her zaman çok sabit kalmasını sağlayın ...  
   
  ... Bir sonraki bölümde dalları birleştirme konusuna değineceğim ...

• http://marc.info/?l=forrest-dev&m=112504297928196&w=2 Apache Forrest projesi
  için dallanma stratejilerini tartışan konu başlığının postaları

  • Şu anda, projenin salınım dalları olan dengesiz gövde modelini kullandığı görülüyor:
  • "SVN'nin gövdesi üzerinde geliştirme çalışmaları yapıldı ... SVN'nin" serbest bırakma dalları "var, örneğin forrest_07_branch." ( proje kuralları )
  • "Sürüm adayı paketlerini oluşturma ... 17. SVN'de bir bakım dalı oluşturun ..." ( Sürüm nasıl serbest bırakılır )

• O'Reilly CVS dallanma dokümanları:
  http://commons.oreilly.com/wiki/index.php/Essential_CVS/Using_CVS/Tagging_and_Branching#Basically_stable
  

  • ... Temel olarak kararlı dallanma felsefesi, bagajın her zaman serbest bırakılmaya hazır olan proje verilerini içermesi gerektiğini belirtir ... ... Bu felsefenin daha hafif varyasyonları, geliştirici birim testini geçen her şeyin birleştirilmesine izin verir. Bavulun. Böyle rahat bir yaklaşım, yayınlanmadan önce bir serbest bırakma adayının dallanmasını ve tam bir KG analizi yapmasını gerektirir ...
  • ... Temel olarak kararsız olan felsefe, istikrarına bakılmaksızın, bagajın en son kodu içermesi gerektiğini ve serbest bırakma adaylarının KG için dallanması gerektiğini belirtir.
     
     
    ... Daha yumuşak değişkenlikler ayrıca deneysel kod, yeniden düzenleme ve diğer özel durum kodları için dallanma olanağı sağlar. Bir şubenin gövdeye geri birleştirilmesi, şubenin yöneticileri tarafından yapılır. ...
    • Yukarıdaki not, yaptığım aramaların hiçbirinde görünmüyor (CVS ile ilgili kurallar artık popüler değil mi?)

• SCM'deki en iyi uygulamalar (performans makalesi)
  http://www.perforce.com/perforce/papers/bestpractices.html adresinde
  ... altı genel SCM dağıtım alanı ve bu alanların her birinde kaba taneli en iyi uygulamalar. Aşağıdaki bölümler her bir öğeyi açıklar ...
  Çalışma Alanları, Codelines, Dallanma, Yayılım Değişimi, Yapılar, Süreç ...

Farklı özellikler üzerinde aynı anda çalışan birkaç ekibiniz varsa, dallanmayı atlamanıza imkan yoktur. Diğer ekiplerin bitmemiş özelliklerinizi almasını engelleyerek (kısmen uygulanmış) kodu ekip üyeleriyle paylaşmalısınız.

Şubeler bunu başarmanın en kolay yoludur.

Her ne kadar dallar yaşam döngüsünü kısaltmak ve aynı modül üzerinde aynı anda iki dalda çalışmaktan kaçınmak iyi olsa da, o zaman çatışmayacaksınız.

Ancak son zamanlarda sürekli entegrasyon, sürekli teslimat vb.

Sizin için sürekli entegrasyon, sürekli teslimat, vb . Somut bir şekilde pratik yapmak sizin için daha mı zor ?

Olmazsa, çalışma şeklinizi değiştirmek için hiçbir neden göremiyorum.

Elbette, neler olup bittiğini ve mevcut en iyi uygulamaların nasıl geliştiğini takip etmek iyi bir uygulamadır. Fakat süreçlerimizden / araçlarımızdan vazgeçmemiz gerektiğini düşünmüyorum, çünkü sadece X (ve / veya Y ve / veya Z) artık solmadıklarını söylediler :-)

Ne ilginç bir cevap seti. 20 yıldan fazla bir süredir dallanmanın önemsiz kullanımından daha fazlasını yapan bir şirkette hiç çalışmamıştım (Genellikle sadece şube yayınlarına).

Çalıştığım yerlerin çoğu oldukça hızlı check-in'lere ve hızlı çarpışmaların saptanmasına / çözülmesine dayanıyor - Agile metodolojisi, her iki taraf da aktif olarak bu kod parçasını düşünürken, fark ederseniz, sorunları daha hızlı çözebileceğinizi öğretir.

Öte yandan, çok fazla gitmedim ve belki de bu cevapları etkileyen git etiketinin eklenmesiyle - dalın / birleştirmenin git ile birlikte verildiğini biliyorum, çünkü çok kolay.

Evet, herhangi bir (en azından orta) geliştirme çabasını yalıtmak için dalları kullanmalısınız. Bkz. " Ne zaman dal vermelisiniz? ".

Mesele, ileriye dönük bütünleşmeleri (başka birinin içindeki bir şube geçmişini içeren), ilk önce tüm "ara kontrol noktası taahhütlerini" (geri alma durumunda bir sorun olabilir) ezmeniz şartıyla kullanmaktır git bisect. Özel şubeleri (itilmemesi gereken) halka açık şubelerden ayırt etmek için, birleştireceğiniz şubede gerekli temizliği yapmanız şartıyla birleştirme işlemleri (hızlı ileri alma işlemleri) ile tamamlanan " Git iş akışını anlama
" konusuna bakın. . Ayrıca bkz. “ Git varsayılan olarak neden hızlı ileri birleştirmeyi kullanıyor? ”.

Dalları kesinlikle kullanmalısın. Bunun bir çok gücü var.

• HD arızası, dizüstü bilgisayar kaybı vb. Nedeniyle işinizi kaybetme konusunda endişeleriniz varsa, çalışmanızı kontrol edebilirsiniz ve ana CI'yi bozmaz.
• Yine de CI yapabilirsiniz, şubenizi izlemek için sadece kendi yerel CI'nizi kurun.
• Eğer özellik aniden beklemeye alınırsa (bu asla gerçekleşmez) sadece park edebilirsiniz.

Çok zor asla bir bahane değil. Doğru yapmak her zaman daha fazla çaba gösterir.

Eğer iki takım kendi branşlarında çalışıyorsa, her iki masterdalı da entegre etmiş olsalar bile diğer takımın değişikliklerini görmezler . Bu, gelişim dallarının ayrılacağı ve takımlardan birinin birleşmesi masterdurumunda diğer takımın birçok değişikliği yeniden yapması gerektiği anlamına gelir .

Bu nedenle, özellikler için şubeleriniz olsa bile, tüm refactoring'leri ana şubeye “backports” yapmaya ve şubeyi sadece yeni özellikler için tutmaya davet ediyorum.

• Backport refactorings

Bazen üretime girmemesi gereken yeni, denenmemiş özellikleri devre dışı bırakmak için özellik anahtarlarını kullanmak daha kolay olabilir diye düşünüyorum. Bu şekilde diğer tüm takımlar değişiklikleri görecek ve büyük patlama birleşme gerçekleşmeyecek.

• Özellik anahtarlarını kullanın

Biz sadece bunu tekrar denedik .. İlk önce GIT / SVN tartışmasını yaptık, bu da bizi genel olarak dallanma stratejilerine yönlendirdi.

Daha büyük şirketler, herkesin aynı branşta çalıştığı ve bu daldan sürekli entegrasyon gerçekleşen, trunk tabanlı bir strateji kullanır. Çelişkiden kaçınma, kod modülerleştirme, özellik değiştirme ve akıllı takımlama kullanılarak yapılır. Bu zor geliyor .. çünkü öyle. Fakat eğer bu tartışmayı yaşıyorsanız, bunun nedeni insanların dallanma konusundaki fantezilerine kurban ettiğinizdendir. Bazı iddialar burada tam sarbanes-oxley uyumlu promosyon dallanma mekanizması ile SCM aracı kullanın iddia , ve hepsi mükemmel. Ya yalan söylüyorlar, kendilerini kandırıyorlar ya da olduğunuz sistemle aynı ölçekte çalışmıyorlar.

Dallanma ve birleşme zordur. Özellikle düzenli olarak fikrini değiştiren ve geri alma talepleri gerektiren bir işiniz varsa

Bu cümle hayatınızı kurtarabilir: SCM'de bulunanlar, sizin eserlerinizde olanlarla aynı değildir!

Dallanma ile ilgili sorun yaşıyorsanız bunun nedeni SCM'nizi yanlış kullanmanızdır. Hepimiz yıllardır yapıyoruz. Son derlemenize neyin gireceğini belirlemek için SCM'nin kullanıldığı bir sisteminiz var.

Bu SCM'nin işi değil. SCM, yüceltilmiş bir dosya sunucusudur. SCM'nizden hangi dosyaların derlemenize gireceğini belirleme işi derleme takımınıza ait.

Modül A çalışıyor ve haftalık sürümünüze giriyor. B modülü, A modülüdür ancak içinde X projesi bulunur ve aynı dalda üzerinde çalışır, ancak sürümünüze dahil edilmez. Gelecekte bir noktada, X projesini yayınlamak istiyorsunuz. Böylece, derleme aracınıza A modülünü koymaktan vazgeçmesini ve B modülünü yerleştirmeye başlamasını söyleyin.

Bu konuda çok fazla ağlama ve el sıkma olacak. Ne saçma ve genel uluyan. Ne kadar zeki olursa olsun, dosya deposu kadar basit bir şeyi çevreleyen duygu düzeyi budur.

Ama cevabınız burada.

Dallanma ile ilgili ana problem, gelişme tamamlandığında ana dal ile tekrar birleşmenin zorluğudur. Birleştirme manuel olabilir ve hataya açık bir işlem olabilir, bu nedenle çoğu zaman kaçınılmalıdır.

Dallanmayı tercih ettiğim bazı dikkate değer istisnalar, büyük yeniden ateşleme, bir sprintin geliştirilmesinden daha uzun süren dev özellikler veya o sprintin büyük çoğunluğu sırasında diğer özelliklerin gelişimini engelleyen yıkıcı özelliklerdir.

Bu tür bir şube şemasını öneririm:

sürüm - test - geliştirme

Ardından geliştirmeden, geliştiriciye ve / veya özelliğe göre şube.

Geliştiricilerin her birinin rutin olarak oynayacak ve onlarla birleşecek ve daha sonra geliştirme dalına düzenli olarak - her gün ideal olarak (derleme sağlayarak) bir dalı vardır.

Bu tür bir şema, aynı kod tabanında çok sayıda geliştirici ve çok sayıda projeyle gerçekten iyi çalışır.

Biz yapmak değil özelliğinin ayrıntılı düzeyde dalları kullanın. Her sprint için dallar kullanıyoruz. Özünde dallanma, kötü bir IMO değildir, çünkü özellikteki SOC kavramını veya sprint katmanını simüle eder . Hangi şubenin hangi özelliğe veya sprint'e ait olduğunu kolayca tanıyabilir ve yönetebilirsiniz.

IMHO, sonra cevap, EVET . Hala dallanma kullanmalıyız.

Organizasyonumdaki süreç, branşlardan ve (biraz benzeyen bir süreç) sürekli entegrasyondan yararlanmaktadır.

Yüksek düzeyde bakıldığında, geliştiriciler ana hat ile birleşme konusunda çok fazla endişe duymuyorlar, sadece şubeye bağlı kalıyorlar. (yarı) otomatik bir işlem, hangi özelliklerin ana hatta girmesi gerektiğini kontrol eder, bu dalları birleştirir ve ürünü oluşturur. Süreç işe yarıyor, çünkü sorun takipçiden bu birleşme sürecini gerçekten birleştiriyoruz, böylelikle yapım aracı hangi dalları birleştireceğini biliyor.