Ne zaman yeni bir proje başlarsa, genellikle "istikrarlı" bir şey elde edinceye kadar doğrudan usta taahhüt ederek başlamak mantıklı olur ve ardından şubelerde çalışmaya başlarsınız.
En azından normalde böyle yapıyorum. Şubeleri hemen ikinci işlemden başlatmak için bir yol var mı? Bu şekilde yapmak mantıklı mı? Açıkçası, "İlk Taahhüt" her zaman usta olacak, ancak ondan sonra, yeni özellikler için dal oluşturmaya başlamanın tam zamanı ne zaman olacak?
Yanıtlar:
Hemen.
Anahtar, Üstat için politikanın ne olduğu sorusudur. Git ile, genellikle, Master’daki şube politikası oluşturulabilir kararlı sürümdür. Bazen, Master, bir Dallanma dalına birleştirilmeden önce dalların yapıldığı ve birleştirildiği “ana hat” tır. Bunlar iki farklı rol / politika yaklaşımıdır.
İnsanların bir şubenin rolünü veya politikasını proje boyunca değiştirmesi genellikle bir hata kaynağıdır. Yalnız bir geliştiricinin bu değişiklikleri katkıda bulunanlara iletmesi daha kolaydır, ancak hepsine bir düzine programcının ulaşmasını sağlamak "Usta şu anda 1.0'dadır, lütfen herkesin kendisine itmek yerine özellikleri tanıtın"
Yukarıdaki politika yaklaşımına değindim. Master için politika, inşa edilebilir istikrarlı bir sürüm olmasıdır. Eğer bir şey yok bu yollarla içine küçük artımlı değişiklikler denetleme imara her zaman kararlı. Küçük değişikliklerde kontrol yapmamak, en iyi politika olma eğiliminde olan (ve kolay dallanma ile teşvik edilen) “çok sayıda küçük (ancak tamamlanmış) çeke” karşıdır.
Rol temelli bir bakış açısıyla, ustalık ana hat, yayın, bakım ve geliştirme rolleri ile başladınız ve ardından bir kısmı geliştirme ve bakım rolünün şubelere taşıdığı yolun altını çizin. Bu yine, ustada izin verilen şeyde bir değişiklik anlamına gelir ve katkıda bulunanların işlerin nereye ait olduğu konusunda kafalarını karıştırabilir. Aynı zamanda şube tarihini karıştırıp (biraz) birbirine karıştırabilir ve birleşmeleri anlamak için daha büyük ve daha büyük anlam ifade eden büyük taahhütleri teşvik edebilir.
Dallardaki rol ve politikaları en başından itibaren basit ve tutarlı bir şekilde ele alın.
Bu "politika değişikliği dalı" Dallanma Paternlerinde görülebilir . Her dalın rol aldığı fikri Gelişmiş SCM Dallanma Stratejileri'nde okunabilir . Bunların ikisi de çok güzel.
Genellikle şubelerle çalışmaya başlamak istediğiniz iki durum vardır:
Siz veya ekibiniz bir sonraki sürümde eklenmeyecek en düşük şansı olan yeni bir özellik başlatmanız gerektiğinde (bu, ilk kez yayınlanan ilk sürüm olabilir), ardından geliştirmeyi ayrı bir özellik dalında başlatın.
En son sürüme kadar ciddi hatalar için düzeltmeler yapmanız gerektiğinde ve yalnızca bu düzeltmeleri içeren yeni bir hata düzeltmesi oluşturmak istiyorsunuz, ancak yeni geliştirilen (ve muhtemelen dengesiz) özellikler yok
Bu tür kararlar için, her zaman programın derlenebilir / çalıştırılabilir bir sürümüne sahip olduğunuz noktadan "yeni özellikler" veya "hata düzeltmeleri" anlamında düşünmenin yararlı olacağını düşünüyorum.
Michael Feathers ünlü kitabında değişmesi için dört neden listeliyor , ancak "yeni özellik dalı" altında (işlevsel olmayan bir özellik için) "kaynakları optimize et" ve çoğu zaman "yeni özellik dalı" altında "tasarımı iyileştirme" koyacağım çünkü IMHO, tasarımı belirli bir özelliğin uygulanmasını kolaylaştırmak amacıyla tasarlanmadığında asla geliştirmemelidir .
Eğer izlerseniz git-akışı - doğrusunu ve Git kullanmak ve eğer, sana delidir düşünüyorum yok o zaman gereken - dallanma modeli kullanan asla taahhüt masterBir ortak sürümü için aslında hazır oluncaya kadar.
İlk taahhüdünüz masterboş bir depo olmalıdır. Bir sonraki taahhüdünüz master, developşubeden veya geçici bir yayın şubesinden bir birleştirme taahhüdü olmalı ve (kitaplık ise) dağıtımı (uygulama ise) ya da genel dağıtım için hazır olmalıdır.
Orada olan diğer dallanma modelleri Git için, ancak bunların çoğu eski merkezi SCM modelleri türetilmiştir ve bir DVCS ortamında ciddi sorunlara yol açabilir. Aslında git-flow uzantısını kullanmak zorunda değilsiniz ve tüm bu sürüm / düzeltme / özellik dallarına ihtiyacınız yok, ancak çıplak kemikler developve masterve kararsız kod giriyor develop.
master. Unutma ki bu mastergitmeye özel bir şey değil, orada olması gerekmiyor. Bir sürüm yapmak istediğinize kadar sadece bir geliştirme şubesine sahip olabilirsiniz.
Neal Ford, Thoughtworks'ün "birleşme cehennemi" sorununu önlemek için dallanma üzerindeki özellik değiştirme kullanımını savunuyor. İki programcının ana daldan günlük olarak incelikle birleştiği ve bazı programlardan birinin haftalar boyunca önemli değişiklikler yaptığı ve sonra taahhüt ettiği durumu göz önünde bulundurun. Diğer programcı birleşti cehenneme çok iyi sonuç verebilir. Ford, bu sorunu önlemek için, yalnızca bir dal alarak ve günlük olarak taahhüt ederek "acıyı öne çıkarmayı" (iyi bilinen bir çevik özellik) önerir. Tamamen sınanana kadar özelliği devre dışı bırakan özellik geçişleri aracılığıyla ek özellik eklenir.
Bu metodoloji, sürekli teslimatı gerçekleştiren bir ortamda en iyi sonucu verir, çünkü bir taahhütle ilgili sorunlar hemen yakalanır.
Bu sorunun son cevabından bu yana iki yıl geçti ve bence artık hikaye değişiyor. Bana göre cevabı "Ne zaman sürümleri izlemek için kaynak kodunu kontrol kullanıyorsanız."
Ayrıntılı olarak, bugünlerde proje kodlarını kaynak kod kontrolü ile takip etmek her zaman işe yaramıyor. (örneğin, bağımlılığı yönetmek için npm kullanmak ve '^' ile anlamsal sürümleri belirtmek için) Bu durumda, bir yapı gerçekleştiğinde her zaman proje eserleri değişir, her seferinde kaynak kodu değişikliklerine gerek kalmaz. Bu tür yeni zorlukların üstesinden gelmek için, bazı ekipler, proje sürümleri için yapay kontrol sisteminde (örneğin JFrog Artifactory) kaydedilen 'artefaktları' oluşturmayı seçti.
Açıkçası, zaten eserler sürüm kontrolü yerinde olduğunda, 'üretim kodunu' bir GIT şubesinden çekmez ve üretime / dağıtmaya başlamazsınız, bunun yerine doğrudan çalıştırılabilir bir sürüm için yapay nesneler kontrol sistemine danışırsınız. Bu gibi durumlarda, "serbest bırakma dalı" kavramı aniden anlamını kaybeder. Ve ekibiniz git şubesini sürüm sürümüyle ilişkilendirmemeye karar verdiğinde, doğrudan efendiye taahhüt etmek / itmek bir kez daha sağlam bir seçim haline gelir: repo klonlandığında varsayılan branş olarak gelir, bu nedenle otomatik olarak semantiklere geniş çapta kabul edilir ve iyi iletilir değiştirir. Yine de, kabul edilen cevabın önerdiği gibi, muhtemelen ana da dahil olmak üzere şubelere bir atama rolü üstlenmeli ve bu dalları sadece bu özel roller için kullanmalısınız.
Son olarak, bir adım daha ileri gidiyorum ve master'ı, yalnızca bir kaç temel müteahhit ile birlikte projelerde geliştirme dalı olarak kullanmanızı öneriyorum. Ekibim için geçerli olan durum budur ve çoğu mikro hizmet mağazası için muhtemelen aynıdır. Master'da işlem yapmak, değişiklik işlemlerinin iletişimini kaldırır ve birden fazla sprint üzerinde özellikler üzerinde çalışırken potansiyel olarak 'cehennemden' kaçınılmasını sağlar. Dahası, ana branştaki kodun 'çalışması' gerekmez, otomatik yapım / test işlemi size neyin yanlış gittiğini söyler ve yine de git geçmişini kontrol etmek ve yapı / testi kesen yazarla iletişim kurmak için yeterince kolaydır.
Radikal bir pozisyona gireceğim: Her fikre dal. Birincisi git şubelerinde ucuz, bir şubenin ana maliyeti ne için olduğunu hatırlamaktır. Ayrıca, ustalığa ilk söz vermenin serbest bırakma adayı olduğuna katılıyorum. Bir kavram dalı kanıtı ile başlamanızı öneririm. Konseptinizi kanıtladığınızda, boş deneme alanınızla birleştirebilir veya ilk denemenizin ne kadar iyi olduğuna bağlı olarak yeniden yazabilirsiniz. bu noktadan itibaren her böcek, özellik, soyutlama vb. için devel'den dal alırsınız.