Kütüphanenizin farklı versiyonlarını versiyon kontrolü altına nasıl sokarsınız? Etiket kullanıyor musunuz? Veya dallar? Veya başka bir yöntem?

Kodumu sürüm kontrol altına almaya yeni başladım (çalışmakta olduğum laboratuarda, SVN ve kendi kodlarım github'da (tabii ki git ile). Sürüm kontrolünü kullanmadan önce, böyle bir şey yapardım. Sürüm numarası olan birçok klasörün içinde kütüphanenin adını taşıyan bir klasör vardı. Ne zaman yeni bir sürüm üzerinde çalışmaya başlamak istersem, son sürümün bir kopyasını çıkarır, adını yeni sürüme değiştirir ve uygulamaya başlardım.

Ancak bu, klasör sürüm kontrolü altına alındığında çok gereksiz görünüyor. Artıklık dışında, biri en son sürümü edinmek isterse, sadece sürüm import/ sürümleri varsa tüm sürümleri indirir clone.

Şimdi bunu sürüm kontrolü ile yapmanın birçok yolunu görüyorum, ancak yeni olduğum için hangisinin daha iyi olacağını bilmiyorum.

Yöntem 1: etiketleri kullanma

Etiketleri doğru anlamış olsaydım, ana şubenize sahip olurdunuz, ne gibi değişiklikler yapsanız onu bir versiyonla etiketlersiniz. Sonra, çalışan bir kopyasını almak istediğinizde, belli bir etiketi olanı elde edersiniz. (Yanlışsam düzelt)

Yöntem 2: Dallanma sürümleri

Bu yöntemde ana şube gelişim kolu olacaktır. Her şimdi ve sonra istikrarlı bir sürüm yapıldı (diyelim v1.2.0), bu sürüm için bir dal oluşturup asla taahhüt etmiyorsunuz. Bu şekilde, belirli bir sürümü indirmek istiyorsanız, kodu bu daldan alırsınız. Asla taahhütte bulunmadığınızı söylememe rağmen, eski sürümün çalışmaya devam etmesi için hata düzeltmeleri yapmak ve eski sürümün şubesine söz vermek mümkün olabilir. Örneğin güncel sürümü ise v2.0ancak kullanmak isteyen insanlar var v1.2, aralarından başka bir şube alabilirsiniz v1.2yani v1.2.1ve hata düzeltmeleri yapmak veya tıpkı sürüm aynı tutmak v1.2ve sadece hata düzeltmeleri taahhüt.

Böylece dallar şöyle görünür:

                  v1.2.1  v1.2.2
                 /       /
 v1.0.0   v1.2.0---------     v2.0.0
/        /                   /
-------------------------------------- dev

Bu şekilde her küçük sürüm güncellemesi için şubeleriniz vardır. (Yukarıdaki grafikte, v1.2.1 ve v1.2.2'nin veya v2.0.0 yayımlandıktan sonra yaratıldığından, v1.2.0 ve v2.0.0 arasındaki gelişimin bir parçası olmadıklarını unutmayın. Eski sürümleri destek olarak düşünün)

Yöntem 3: Dallanma gelişimi

Bu yöntem öncekinin tersidir. Ana şube en son kararlı sürüm olacaktır. Ne zaman yeni bir sürüm üzerinde çalışıyorsanız, bir şube (geliştirme için) oluşturursunuz, kodunuz üzerinde çalışırsınız ve stabil olduğunda ana dalı ile birleştirirsiniz.

Bu durumda, dallar şöyle görünür:

 ________  ____  ________________  _____ dev
/        \/    \/                \/
---------------------------------- latest_version

Muhtemelen bu bir doğru etiketleri ile birlikte yapılması gerekiyor?

Soru!

Her neyse, sorum şu ki, deneyimlerinize dayanarak, bu yöntemlerden hangisi daha pratiktir? Orada bilinen en iyi yöntem var mı (muhtemelen kendimi çözemedim)? Bunlar genel olarak nasıl yapılır?

Etiketler ve dallar karşılıklı değildir, ikisini de kullanabilirsiniz (ve IMO genellikle kullanmalıdır). Etiketler geliştirme aşamasında kilometre taşlarını işaretlemek için orada. Örneğin size ürünün sürüm 1.2 için bir şube açın ve işaretlemek v1.2 Beta, RC1, RC2, Final(ve daha sonra, gerekirse, SP1aynı dal üzerinde etiketleri ile vb.)

Ben şahsen Yöntem 2'yi varsayılan yaklaşım olarak tercih ediyorum (birçok dal seviyesinden kaçınmaya çalışsam da, hayatı mümkün olduğunca basit tutmak için). Yöntem 1 sadece gerçek hayatta çalışmayacak - etiketler yeterli değil, dallara ihtiyacınız var. Ve yöntem 3, her zaman sadece tek bir kararlı sürüme sahip olduğu için esnek değildir, bu yüzden (Yöntem 2 ile birleştirmezseniz), birden fazla (en yeni ve eski) sürümü paralel olarak tutamazsınız. Bu, gerçek hayatta neredeyse tüm projeler için gereklidir - sürüm 2 üzerinde çalışırken, v1.9 için ve hatta daha önceki sürümlerde hala yama / yükseltme yayınlayabilmelisiniz. Çok tabii ki uygulamanın türüne bağlıdır. Bir web uygulaması geliştiriyoruz, bu nedenle herhangi bir zamanda yalnızca bir üretim sürümü var, yine de sık sık 3 farklı sürümle oynarız (biri üretimde, Biri UAT'de konuşlandırmaya hazırlanıyor, bir tanesi de bagajdaki en son sürüm. Paralel olarak kullanılan ve sürdürülen birden fazla eski sürümü olan bir masaüstü / istemci uygulaması için daha karmaşık hale gelebilir.

Sürüm numarası olan birçok klasörün içinde kütüphanenin adını taşıyan bir klasör vardı.

Bu, etkili bir şekilde, not ettiğiniz gibi, yanlış bir yaklaşım çünkü sürümleri kontrol etmek için zaten sürüm kontrolü var.

Şimdi, numaralandırdığınız farklı tekniklerin hepsi eşit derecede doğru görünüyor. Etiketler ve dallar hakkında bilgiler içeren çok ayrıntılı bir makaleyi Kaynak Denetimi Tamamlandı adlı makaleyi okuyabilirsiniz .

Üç yöntem birbirini dışlamaz ve sürüm kontrolünüzden en iyi şekilde yararlanmak için üçünü birleştirmelisiniz.

Benim açımdan, varsayılan olarak 1 ve 3 yöntemlerinin bir birleşimini kullanırdım, yani bir özellik üretime hazır olana kadar bir özellik veya geliştirme dalında gelişir ve daha sonra tekrar bagaja birleştirilir. Bu şekilde, ana hat her zaman istikrarlı, kullanılacak bir geliştirme mevcut durumunu temsil eder ve svn: harici projelerle güvenle bağlanabilir. Bir sürümü serbest bıraktığınızda, etiketleyin.

Ben sadece kütüphanede eski sürümleri bir hata olduğunda, bir talebe, üzerinde şube ediyorum sahiptir düzeltilmesi. Kırık sürümün etiketinden o dalı kolayca oluşturabilirsiniz. Gereksiz yere dallanmadığınız için, dal sayısını düşük tutarsınız ve bakımı gereken kanama kenarları (gövde ve tüm dallar) hakkında hızlı bir genel bakışa sahip olursunuz.

Yöntem 2'yi kullanırdım . Bunu kullandım ve mevcut geliştirmenin ilerlemesine izin verirken birden fazla sürümü yönetmenin ve sürdürmenin etkili bir yolu olduğunu gördüm. İhtiyacınız olursa, etiketleri bu yöntemle birlikte de kullanabilirsiniz.

Birden fazla sürüm sürümünü korumak için dallanma kullanma hakkında daha fazla bilgi için buradaki cevaba bakın .