GitHub'daki projemin sürümlerini nasıl kontrol etmeliyim

Gerçek bir kurumsal uygulama için nasıl olacağını gerçekten hissetmek için bugünlerde GitHub'da olabildiğince fazla zaman geçirmeye çalışıyorum (hatta işteki takımdaki tek kişi benim bile) .

Bir sorum var sürümü kontrol etmek . Diyelim ki bir proje başlattık. Daha sonra ekip üyeleri bazı şubeler oluşturup orada gelişti. Üretime hazır olduğumuzda, tüm şubeleri şubeyle birleştirdik master. Sonunda, versiyonla yayına geçiyoruz 1.0.

Şimdi bu sürüm 1.0yayında ve bu yazılımın sürümüyle ilgili bazı sorunlar var. 1.1Projeyi acele ederek ortaya koyduğumuz sorunları düzeltmek için sürüm için geliştirmeye başlamak istiyoruz .

Şimdi soru şudur:

Burada sürüm oluşturmayı nasıl kontrol etmeliyiz?

Yazılımın v1.0sürümü için yeni bir şube oluşturmalı ve 1.0yazılımın sürümünü orada tutmalı ve bazı dallarda (ya da değil) geliştirmeli miyiz master, onları birleştirmeli 1.1miyiz , sürümle canlı kalsın mı?

Bu tür durumlar için bir anlaşma var mı?

— tugberk
kaynak

Yanıtlar:

Aşağıdaki şube modelini buldum (ve benimsemeye başladım) :

Görüntü nvie.com

^{(makaledeki resim)}

Bu makalede açıklanan birçok harika uygulama ve katı kural var, kesinlikle tavsiye ederim.

İlgi noktaları:

Ana dal, sürümlerinizi etiketlediğiniz yerdir. Burada hiçbir gelişme olmaz. Üretimde dağıtılan bir hata durumunda, bir düzeltme dalındaki hatayı düzeltir, birleştirir ve yeni bir sürümü etiketlersiniz.
Geliştirme devel ve özellik dallarında gerçekleşir. Şahsen, devel dalında hata düzeltme ve özellik dallarında özellikler yapıyorum.
Yazılım bir sürüme ulaşmaya başladığında, dalı serbest bırakmak için ayrılırım. Serbest bırakma dalı son dokunuşları yaptığım yerdir. Sürüm numaralarını çarp, meta verileri değiştir vb. Ve küçük hata düzeltmeleri. Tamamlandığında, master, tag ve bir sürüm olarak adlandırmak için birleştiriyorum.
İki ana dal: usta "kutsal dal" dır; HEAD her zaman en son üretim kodudur ve geliştirme, gece dalıdır; HEAD her zaman koda en son (ancak olası kararsız) eklemeleri yansıtır.

Özel durumunuzda, adımlar bu sürümün ne kadar acele edildiğine bağlı olacaktır. Dışarıda bırakılan özellikler varsa, geliştirme sürümüne geri dönüp her şeyi tekrar yaparım. Konuşlandırılmış sürümdeki hatalar varsa, bir düzeltme dalına dallar, hataları düzeltir, geri birleştirir ve v1.1 etiketlerim. Her ikisi de ise, önce hataları düzeltirim, sonra açıklandığı gibi ikinci özellikleri eklerdim.

— Tamás Szelei
kaynak

Çok bilgilendirici ve ayrıntılı. Ve ayrıca mükemmel bir uygulama. Ayrıca çok mantıklı. Ürüne hakim olmak sadece bakımını kolaylaştırır. Bir şube (veya taahhüt?) Etiketleme bilmiyorum. Bana bununla ilgili biraz ayrıntı verebilir misiniz? yukarıdaki modele göre nasıl yapabiliriz?

— tugberk

Git'te etiketlemenin hedefi bir taahhüttür. Bu demek oluyor ki: "işte bu taahhüt ve bundan sonra 'v1.3' diyorum". Pratikte bu, ana dala geçeceğiniz anlamına gelir, (şimdi kararlı) devel dalında birleştirin, taahhüt edin ve etiketleyin. Ardından, tüm etiketleri listeleyebilir, geçmiş bir sürümde üretime nelerin girdiğini görmeniz gerektiğinde bu koda geri dönebilirsiniz. Etiketlerden biraz daha fazlası var (linux çekirdeği gibi büyük ölçekli dağıtılmış geliştirme için yararlıdır). Eğer ilgileniyorsanız, progit kitabını öneriyorum .

— Tamás Szelei

ProGit kesinlikle sıfırdan okuyacağım kitaplardan biri. Şimdilik sadece işi yapmakla ilgilendiğim bölümleri okuyorum. Şimdiye kadar, ana dalda geliştik ve bence bunu sürdürmeliyim. Ama yukarıdaki modele göre denilen başka bir şube açacağım productionve şube olarak kullanacağım master.

— tugberk

bu modeli denerken, mücadele ettiğim bir şey var: verilen makalede, özellik ve serbest bırakma dallarında tartışıldığı gibi bazı destekleyici şubeler var. gelecekteki birden çok şube olabilir. Örneğin, FeedbackForm gelecekteki bir dal ve ContactForm başka bir daldır. Sanırım bu model için sorun değil mi? Birden fazla serbest bırakma dalı olmalı mı? ve eğer öyleyse, onları nasıl adlandırmalıyım?

— tugberk

Her şeyden önce, mektuba uymanıza gerek yok, sadece tuttuğunuz kurallar var. Sizin ve ekibinizin tarzı için en iyisini yapın. İkincisi, evet, bir özellik ve bir sürüm ile kısa ömürlü bir projeniz yoksa, çoklu özellik ve sürüm dalları normaldir :). Adlandırma, makaleye göre release- * ve feature- *. Gelecek sürüm numarasını sürüm için yıldız yerine ve özellik dallarında sorun izleyici kimliğini yerleştirdiğinizi tahmin ediyorum.

— Tamás Szelei

Çoğu zaman tanık olduğum şey:

Master size göre. Sonunda gelecekteki tüm sürüm x.0 master olacak.
Üretimdeki her sürüm için bir etiket / şube oluşturursunuz, böylece yine de bunu gerektiren herhangi bir müşteri için destekleyebilirsiniz.
Düzeltmeleri birinden veya diğerinden birleştirmek, vaka başına işlem yapmaktır.

— xsace
kaynak

Teşekkürler! v1.0 adlı bir dalı tutmanın mantıklı olduğunu düşünüyorsunuz, v1.2 mantıklı mı?

— tugberk

@ tugberk, ilgili yazılım bu sürümde mevcut olduğu sürece, dalları düzeltmek mantıklıdır, böylece belirli bir düzeltme dalına ihtiyacınız varsa bunları hızlı bir şekilde kesebilirsiniz. Yazılım artık bu sürümde mevcut değilse (artık desteklenmemektedir, böylece daha fazla iş yapılamaz) dalın son birleştirmesini yapıp daha sonra silebilirsiniz. Son bir boş taahhüt bile oluşturabilirsiniz (bunu dalın başlangıcında sık sık yaparım), sadece "XXXX dalı kapatılıyor" demek için, aksi takdirde şube geçmişini tutmayacaksınız (reflog biraz yardımcı olabilir, ancak bu depo başına)

— Patrick Mevzek