Seçtiğiniz {DVCS} içindeki adlandırılmış şubeler için iyi adlandırma kuralı

16

Mercurial'ı ofisimize yavaşça entegre ediyoruz ve adlandırılmış şubeler kullanmaya başladığımız web geliştirme yapıyoruz.

Yine de şubelerimizi adlandırmak kadar iyi bir kongre bulamadık.

Biz denedik:

FeatureName (Bu soruna neden olan sorunu görebilir)
DEVInitial_FeatureName (Geliştirici gelip satırdan çıktığında kafa karıştırıcı olabilir)
{uniqueID (int)} _ Özellik

Şu ana kadar uniqueID_featureName kazanıyor, sadece referans için küçük bir DB'de tutmayı düşünüyoruz.

Şunlara sahip olacaktır: branchID (int), featureName (varchar), featureDescription (varchar), date, who vb.

Bu bize şu gibi şubeler verecektir: 1_NewWhizBangFeature, 2_NowWithMoreFoo, ... ve bu şubenin günlüğü kontrol etmek zorunda kalmadan yaptıklarına ilişkin kolay bir referansımız olacaktır.

Daha iyi bir çözüm var mı?

version-control mercurial

— jfrobishow
kaynak

14

Sorun izleyiciniz yoksa, birini ayarlayıp {sorun izleyici adı} _ {bilet numarası} kullanmanızı öneririz. Bundan bir yıl sonra bir hata gönderdiğinde ve özelliğin nasıl çalışması gerektiğini tam olarak bilmediğinizde, dosyaya açıklama eklemek ve kullanıcının tam olarak bu işlevselliği istediği yere geri dönmek kolay olacaktır.

— Asa Ayers
kaynak

Bir hata takipçimiz var ve hata düzeltmeleri için şube adındaki bugID'yi kullanmayı planlıyoruz. Benim sorum tamamen yeni bir gelişme içindi, hiçbir şeyi düzeltmediğinizden, tamamen yeni bir şey eklediğinizde. Sanırım aptalca bir geliştirme bileti oluşturabilir ve oradan gidebiliriz.

— jfrobishow

5

Kesinlikle yeni özellikler için bilet oluşturmalısınız. Onlar da izlenecek iş. Benzersiz kimlik gerektirdiği için +1.

— AShelly

İzleyiciye yeni özelliklerin tüm ayrıntılarını koyduğunuzdan emin olursanız, daha sonra biri tasarlandığı gibi çalışıp çalışmadığını veya gerçekten bir hata olup olmadığını doğrulayabilir. 5 yıldan daha eski bir programı sürdüren bir geliştirme ekibi üzerinde çalışıyorum. İstemcinin bir hata dosyaladığı zamanlar vardır ve araştırdığımızda, tasarlandığı gibi çalıştığını ve orijinal geliştiricinin ve orijinal istek sahibinin her ikisinin de gittiğini görürüz. Bir şeyin neden böyle olduğunu bilmediğimiz benzer durumlara sahibiz ve özellikler izleyicide olmasaydı bunu öğrenemezdik.

— Asa Ayers

2

Bunu basit tutmanızı ve şubeleri FeatureName(veya feature-name) sözleşmeye göre adlandırmanızı öneririm . Evet, bu paylaşılan bir ad alanı anlamına gelir, ancak bu gerçek dünyada nadiren bir sorundur. Bir özellik yapıldığında ve ana hatta tamamen birleştirildiğinde, şube güvenli bir şekilde silinebilir.

Dağıtılmış sürüm kontrolünün ana fikri, şubenin kolay olması ve zorunlu benzersiz kimlik gibi ek bürokrasinin getirilmesinin sadece bunu daha da zorlaştıracağıdır.

— Adam Byrtek
kaynak

1

Katılıyorum, bu yol. Hangi dünyada çarpışmadan kaçınamayacak kadar çok dalınız olurdu?

— alternatif

Yeterince adil, sanırım isme bağlı bir açıklama almak bizim için daha önemlidir ... ilk taahhüt onu içermelidir, ancak bunu hızlı bir şekilde çıkarmanın herhangi bir yolunu bilmiyorum.

— jfrobishow

1

Büyük bir kurumsal ortamda, geliştiricilerin özellikler için adlar oluşturmalarına izin vermek er ya da geç baş ağrısına neden olur.

— AShelly

1

Görüyorum, çünkü "büyük şirket ortamında" geliştiricilere güvenilemez. Ama bekleyin, ayrıca değişkenler, fonksiyonlar ve dosyalar için isimler oluştururlar. Bunu kontrol etmek için bir komite kurmalıyız! (ironi)

— Adam Byrtek

2

Böyle bir form kullanmanızı öneririz (örnek olarak):

bug_id
HATA # Kimliği
TICKET_ID
BİLET # Kimliği
feature_bla-bla-bla
salgılamayı x.xx.xx
release_x.xx.xx
build_2010-20-12
build_4565
BRANCH_x.xx.xx

Sadece önek ( hg dallarından filtre çıktısına izin vermek için ), büyük harf yapma kuralı ve önek ile kimlik / adlar arasındaki sınırlayıcıyı seçin.

— gavenkoa
kaynak

+1 sonunda sonunda BUGID_ {freeCamelCasedTextDescription} ile gittik.

— jfrobishow