Bu Git Dallanma Modeli ile Herhangi Bir Kusur Var mı?

Bu git dallanma modelini veya iş akışını soruyorum . Bunu gerçekten beğendim. Bana çok sezgisel ve üretken geliyor, ancak istediğim şey bu yaklaşıma henüz net olmayan (ClearCase'in günü yönettiği başka bir dünyadan gelen) herhangi bir kusur veya negatif olup olmadığı.

(Her soruyu cevaplamanıza gerek yoktur, her ne olursa olsun yardımcı olur)

1. Bunu veya benzer bir git dallanma iş akışını kullanıyor musunuz?

2. Bunun üretken bir yaklaşım olduğunu düşünüyor musunuz?

3. Bu yaklaşımda herhangi bir kusur görüyor musunuz? Potansiyel bir dezavantaj var mı?

4. Daha iyi bir yaklaşımınız varsa, bir makaleyi veya onunla ilgili bir tartışmayı paylaşmak veya bir bağlantı sağlamak ister misiniz?

Çoğunlukla, bu şimdiye kadar kullandığımız herhangi bir VCS ile kullanılan normal iş akışıdır. Bazılarıyla (CVS, SVN) yapmak daha zordur, GIT ile önemsizdir. Bununla birlikte, iki görüşüm var:

Birincisi, branşlar söz konusu olduğunda iki düşünce okulu vardır:

1. Onları birleştir
2. Onları geri al

(1) makalenin önerdiği şeydir. Birleştirme taahhütleriyle ilgili sorun, Evil Merges olarak adlandırılır . Özellikle, bir işlevin dallardan birinde semantiği değiştirdiği, ancak otomatik birleştirme diğer daldan gelen koddaki tüm oluşumları çözemeyen geliştirme yollarına katılanlar. Bu yolla getirilen regresyonların hatalarını ayıklamak zordur. Bir GIT kullanıcısı olarak, regresyonlar hakkında genellikle çok daha rahat olabilirsiniz, çünkü sizin git bisectiçin nedenlerini otomatik olarak bulmanız gerekir . Ancak, açıklanan durumda, git bisectsize hiç yardımcı olmayan birleştirme taahhüdüne işaret edecektir.

(2) mümkün olduğunca doğrusal bir tarih tutmaya çalışarak bu sorunu önler. Rakiplere karşı çıkanlar, geri ödeme öncesinde yapmış olabileceğiniz testleri geçersiz kıldığını iddia ediyor.

Şahsen, kampa sıkıca katıldım (2), çünkü git bisectsonuçların geçerliliğine, uygun bir CI sistemi kullanılarak kolayca telafi edilebilen potansiyel test kapsamı kaybından daha fazla değer veriyorum .

İkincisi, geliştiriciler arasında itmenin nadiren iyi bir fikir olduğuna karar verdim. Herkesin kutunuza ssh atmasına veya yerel olarak git-deamon'u çalıştırmasına izin veren güvenlik sorunları var ve daha da önemlisi, aşırı küçük olmayan ekiplerde gözetim oldukça hızlı bir şekilde kaybolabilir.

Bununla birlikte , alt ekiplerin devam eden çalışmalarını ana sunucudan (genellikle dışa doğru) merkezi bir sunucu aracılığıyla paylaşmalarına izin veren bir hazırlama havuzundan (bazen sıfırdan da denir ) yanayım. herkese açık değilse). Tipik olarak, her bir alt ekip bir konu dalını kendisi için muhafaza eder ve bir CI sistemi , tüm konu dallarının periyodik ahtapot birimlerini büyük bir entegrasyon dalında gerçekleştirir ve çatışmalardan şikayet eder ve hatalar oluşturur.

Şu anda büyük ve uzun süreli yeniden düzenleme işlemleri (bir uygulamayı başka bir GUI araç setine dönüştürme) ve başarılı bir rebase merkezli iş akışı gerçekleştiriyorum, çünkü diğer ekip üyeleri yeni özellikler üzerinde çalışmaya devam ediyor:

Çoğunlukla masteryeni özelliklerin geliştirildiği iki şube ve toolkit-conversionşube vardır. En önemli kural basittir: yalnızca toolkit-conversiondalda dönüşümle ilgili olan şeyleri yapın . master(Eski GUI araç setinde) yapılabilecek bir şey olduğunda, bunu orada yaparım toolkit-conversionve yeni masterkafaya yaptığım değişiklikleri geri atarım . Başka bir kural da toolkit-conversionşubeyi oldukça kısa tutmaktır . Bu nedenle, daha küçük taahhütleri daha büyük olanlara (sonunda aynı amaca sahip olan) yapıştırmak için genellikle sıfırlama, kiraz toplama ve değiştirme-taahhüt ve rebase kullanıyorum. Bu değişiklik "geri almak" için iyi çalışmadı bir şey denedim veya geçici yardımcı kodu ile bazı kodu yeniden yaptıktan sonra da iyi çalışır.

Ben değişiklikleri birleştirme karşı karar verdik masteriçine toolkit-conversiono çok zor temiz ve gözden kolay dalı tutmak için daha erken kaydedilmesini rebase yapacak çünkü, şube. Ayrıca, birleşmeler, kararları temiz bir tarihte olduğu kadar net olmayan çatışmalara yol açabilir.

Tabii ki, bu iş akışının dezavantajları da vardır. En önemlisi, sadece tek bir kişi için iyi çalışmasıdır. toolkit-conversionŞube kafasına bastıktan sonra zorla ittiğimde master, başka bir depoya çekmek zorlaşır (dalın otomatik olarak izlenmesine yeniden basmak genellikle çatışmalarla başarısız olur).

Sonunda toolkit-conversionşubem kısa, temiz ve gözden geçirmesi kolay. SVN ile bu kadar güçlü bir şey yaptığımı hayal bile edemezdim.

Şu anda çalıştığım şirkette, bir süredir aynı dallanma modelinin bir varyasyonunu uyguluyoruz. Ayrıca scrum kullanıyoruz, böylece hikaye iş akışı başına bir şube yapıyoruz.

Şimdiye kadar yaşadığımız tek sorun, takımın yeterince büyük olması ve birden fazla hikayenin başlatılabilmesi ve bu hikayelerin birbirine bağımlı olması, şubeler arasındaki değişiklikleri birleştirmek ve ustaya geri dönmek bir karışıklık haline geliyor.

Bunun yanı sıra, bu güvenilir olduğu kanıtlanmıştır :).

Şu anda bu iş akışını uyarlamakla meşgulüm. Bunun oldukça iyi bir iş akışı olduğunu düşünüyorum, çünkü git'in mükemmelleştiği dallanma modelini kullanıyor.

Tek küçük dezavantajı, bu iş akışına basılı tutmanın ve kısayol almaya çalışmanın bir disiplini almasıdır.

Kohana geliştiricileri de bu iş akışını kullanıyorlar ve oldukça beğendiler.

Bunu veya benzer bir git dallanma iş akışını kullanıyor musunuz?

İş yerinde benzer bir iş akışı kullanıyoruz, ancak biraz daha az karmaşık. Ancak bu makaleyi birçok kez okuduğum için bu iş akışından büyük ölçüde ilham aldı. Hatta masamın yanındaki renklerde basılmış dallanma modelinin pdf'sine sahibim :)

Bunun üretken bir yaklaşım olduğunu düşünüyor musunuz?

Üretken. Verimliliği nasıl tanımlıyorsunuz? Aklımda, en azından her zaman daha iyi kalite elde etmek için yüksek kaliteye sahip olmak çok önemlidir. Süreci sürekli iyileştirmek vb. Eğer kalite kodu üretebiliyorsanız, verimlilik bundan faydalanacaktır. Yani soru gerçekten: Bu yazılımın kalitesini artırıyor mu? Ve buna cevabım kesinlikle evet.

Bu tür dallanma modeliyle en çok sevdiğim şey, farklı kalite katmanlarında dalları tanıtmasıdır. Resimde sağda daha fazla, daha yüksek stabilite ve daha yüksek kalite. Ana dal kutsaldır ve üzerindeki tüm taahhütler yazılımın kararlı sürümleri olarak kabul edilmelidir. Ne kadar sola giderseniz, o kadar deneysel olur ve stabilite o kadar düşük olur.

Yeni özellikleri ve hata düzeltmelerini test eder etmez, yavaş yavaş soldan sağa aktarabilir ve kodun kodun talep ettiğiniz kalite gereksinimlerini karşıladığını tam olarak bildiğinizde yüksek kalitede kodla hareket edebilirsiniz. En azından teoride, her şeyi% 100'e kadar test edemezsiniz ve kodun herhangi bir hata içermediğinden emin olamazsınız, çünkü her zaman hatalar olacaktır. Ancak yüksek bir güven sağlamanızı sağlar.

Hiçbir şey, bir programcı olarak, kimsenin koda güvenmediği bir sistemde çalışmaktan daha fazla berbat değildir, çünkü sadece berbat olduğunu ve içinde bir hata yükü olduğunu bilirler.

Bu yaklaşımda herhangi bir kusur görüyor musunuz? Potansiyel bir dezavantaj var mı?

Dallanma modeliniz aracılığıyla düşünmek önemlidir, böylece kuruluşunuzun ihtiyaçlarına iyi uyum sağlar. Bu modelin bazı insanlar için iyi çalıştığı için, mutlaka başkaları için en uygun veya istenen anlamına gelmez.

Her zaman değiş tokuşlar vardır ve bu durumda bile. Bir değiş tokuş karmaşıklık karşısında şube sayısıdır. Çok sayıda farklı dal türü ekleyerek iş akışının karmaşıklığını artırırsınız. Örneğin, birkaç satır kod değiştirerek basit bir hatayı düzeltmeye çalışırken insanları her zaman yeni bir özellik dalı oluşturmaya zorlamak yanlış olabilir.

Hepimiz biliyoruz ki hataların çözümü az çok karmaşıktır. Bu nedenle, önemsiz bir hata keşfedildiğinde, ekstra yükten kurtulmak için karmaşıklığı ve yönetimi kısmak ve sadece insanların doğrudan efendiye ya da şube geliştirmesine izin vermesini isteyebilirsiniz. Ancak, düzeltmelerinizin doğası daha karmaşık hale geldikçe, onlar için yeni dallar oluşturmak için ekstra yüke değer. Özellikle boyutundan ve uzunluğundan emin değilseniz veya siz ve diğer geliştiriciler arasındaki işbirliğini geliştirmek istiyorsanız.

Daha iyi bir yaklaşımınız varsa, bir makaleyi veya onunla ilgili bir tartışmayı paylaşmak veya bir bağlantı sağlamak ister misiniz?

Bu şüphesiz iyi bir yaklaşımdır ve çoğumuz benzer gelişme süreçlerine sahip olduğu için çoğu duruma uygun olabilir, ancak herkes için uygun olmayabilir. Kodunuzu şu anda nasıl ele aldığınızı düşünmenizi ve zaten sahip olduğunuza uyan bir dallanma modeli oluşturmaya çalışmanızı şiddetle tavsiye ediyorum.

En önemli nokta git ile başlamak ve gerisi doğal olarak takip edecek. Basit başlayın ve yavaş yavaş geliştirin! Yaratıcı ol!

Şerefe