SVN, Branch nasıl kullanılır? Etiket? Gövde?

Biraz dolaşıyordum ve SVN için iyi bir "yeni başlayanlar" kılavuzu bulamadım , bunun yerine "komutları nasıl kullanırım" anlamında değil; Kaynak kodumu nasıl kontrol ederim?

Temizlemek istediğim şu konular:

• Ne sıklıkla taahhüt ediyorsunuz? Ctrl+ Tuşuna ne kadar sık basarsınız s?
• Şube nedir ve Etiket nedir ve bunları nasıl kontrol edersiniz?
• SVN'ye ne giriyor? Sadece Kaynak Kod mu yoksa burada başka dosyalar da paylaşıyor musunuz? (Sürüm dosyaları dikkate alınmaz ..)

Şube ve etiketin ne olduğu hakkında hiçbir fikrim yok, bu yüzden amacını bilmiyorum, ama vahşi tahminim, gövdeye bir şeyler yüklemeniz ve büyük bir yapı yaptığınızda şubeye taşımanız mı? Peki, bu durumda ana yapı nedir?

Yıkılma kitabı , deponuzu dışarı atarken dallanma ve etiketleme için stratejiler üzerinde mükemmel bir bilgi kaynağıdır.

Ayrıca bakınız:

Bir dalda veya bagajda gelişmeye devam ediyor musunuz

Dallanma stratejileri

Subversion'u burada uygulamaya geldiğimizde kendime aynı soruları sordum - 4-6 projeye yayılmış yaklaşık 20 geliştirici. `` Cevap '' ile iyi bir kaynak bulamadım. Cevabımızın son 3 yılda nasıl geliştiğinin bazı bölümleri:

- yararlı olduğu kadar sık ​​taahhütte bulunma; başarımız kural, yeterli iş yaptığınızda, değişikliklerin kaybolması durumunda bunu yeniden yapmak zorunda kalmanın bir sorun olacağını taahhüt eder; bazen her 15 dakikada bir taahhüt ederim, bazen de günler olabilir (evet, bazen 1 satır kod yazmak bir günümü alır)

- şubeleri, daha önceki cevaplarınızdan biri olarak, farklı gelişim yolları için kullanıyoruz; şu anda programlarımızdan biri için 3 aktif branşımız var: 1 ana geliştirme için, 1 henüz programı paralel hale getirmek için tamamlanmamış çaba için ve 1 XML girdi ve çıktı dosyalarını kullanmak için gözden geçirme çabası için;

- Etiketleri nadiren kullanıyoruz, ancak bunları üretime yönelik sürümleri tanımlamak için kullanmamız gerektiğini düşünüyoruz;

Gelişimin tek bir yolda ilerlediğini düşünün. Bir zamanlar veya geliştirme aşamasındaki pazarlama, ürünün ilk sürümünü yayınlamaya karar verir, böylece '1' (veya '1.0' veya ne var) etiketli yola bir bayrak yerleştirirsiniz. Başka bir zaman, bazı parlak kıvılcımlar programı paralel hale getirmeye karar verir, ancak bunun haftalar alacağını ve insanların bu arada ana yoldan devam etmek istediklerine karar verir. Böylece yolda bir çatal inşa edersiniz ve farklı insanlar farklı çatallardan aşağı inerler.

Yoldaki bayraklara 'etiketler' denir ve yoldaki çatallar 'dalların' bölündüğü yerdir. Bazen, şubeler tekrar bir araya gelir.

- depoya yürütülebilir (veya sistem) oluşturmak için gerekli tüm materyalleri koyduk; Bu, en azından kaynak kodu ve make dosyası (veya Visual Studio için proje dosyaları) anlamına gelir. Ancak simgeler ve yapılandırma dosyaları ve diğer tüm şeyler olduğunda, bu depoya girer. Bazı belgeler repoya giriyor; kesinlikle programa entegre olabilecek yardım dosyaları gibi herhangi bir belge yapar ve geliştirici belgelerini koymak için yararlı bir yerdir.

Hatta yazılım arayan insanlar için tek bir konum sağlamak için üretim sürümlerimiz için Windows yürütülebilir dosyaları koyduk - Linux sürümlerimiz bir sunucuya gidiyor, bu yüzden saklanmasına gerek yok.

- deponun her zaman derlenen ve yürütülen en son sürümü sunabilmesini istemiyoruz; bazı projeler bu şekilde çalışır, bazıları işe yaramaz; karar proje yöneticisine aittir ve birçok faktöre bağlıdır, ancak bir programda büyük değişiklikler yaparken kararın bozulduğunu düşünüyorum.

* How often do you commit? As often as one would press ctrl + s?

Mümkün olduğu kadar sık. Kaynak kontrolü altında olmadığı sürece kod mevcut değildir :)

Sık yapılan işlemler (bundan sonra daha küçük değişiklik kümeleri), değişikliklerinizi kolayca entegre etmenizi ve bir şeyi kırmama şansınızı artırmanızı sağlar.

Diğer insanlar, işlevsel bir kod parçasına sahip olmanız gerektiğini taahhüt ettiler, ancak biraz daha sık işlem yapmayı yararlı buluyorum. Birkaç kez kaynak kontrolünü hızlı bir geri alma / yineleme mekanizması olarak kullandığımı fark ettim.

Kendi şubemde çalıştığımda olabildiğince fazla taahhütte bulunmayı tercih ediyorum (kelimenin tam anlamıyla ctrl + s tuşlarına bastığım sıklıkta).

* What is a Branch and what is a Tag and how do you control them?

SVN kitabını okuyun - SVN öğrenirken başlamanız gereken bir yer:

• Şube nedir?
• Etiketler

* What goes into the SVN?

Belgeler, derleme için gereken küçük ikili dosyalar ve değeri olan diğer şeyler kaynak denetimine gider.

İşlem sıklığı, taahhüt mesajları, proje yapısı, kaynak kontrolü altına alınması gerekenler ve diğer genel yönergeler hakkında birkaç kaynak:

• Sürüm Denetimi için En İyi Uygulamalar (kendi blogum)
• Erken Giriş, Sıklıkla Giriş (Kodlama Korkusu) (yorumlar burada çok iyi tavsiye içerir)
• KDE'nin taahhüt politikası

Bu Yığın Taşması soruları ayrıca ilginizi çekebilecek bazı yararlı bilgiler içerir:

• İki veya daha fazla dili (Java ve C ++ gibi) karıştırırken kaynak kod tabanını düzenleme
• İyi bir taahhüt mesajı için öneriler: format / kılavuz?
• Kaynak kontrolünde ne sıklıkla değişiklik yapılır?
• Sürüm Kontrolünü Öğrenme ve iyi öğrenme

Dallanma ve etiketleme gibi temel Subversiyon kavramlarına gelince, bunun Subversion kitabında çok iyi açıklandığını düşünüyorum .

Konuyla ilgili biraz daha okuduktan sonra fark edebileceğiniz gibi, insanların bu alandaki en iyi uygulama hakkında fikirleri genellikle değişkendir ve bazen çelişkilidir. Sanırım sizin için en iyi seçenek, diğer insanların ne yaptığını okumak ve sizin için en anlamlı olduğunu düşündüğünüz yönergeleri ve uygulamaları seçmektir.

Eğer amacını anlamadıysanız veya arkasındaki mantığı kabul etmiyorsanız, bir uygulamayı benimsemenin iyi bir fikir olduğunu düşünmüyorum. Bu yüzden herhangi bir tavsiyeyi körü körüne takip etmeyin, bunun yerine sizin için en iyi olacağını düşündüğünüz şeyler hakkında kendi fikrinizi oluşturun. Ayrıca, bir şeyler yapmanın farklı yollarını denemek, en iyi nasıl çalışmaktan hoşlandığınızı öğrenmek ve öğrenmek için iyi bir yoldur. Buna iyi bir örnek, havuzu nasıl yapılandırdığınızdır. Bunu yapmanın doğru ya da yanlış bir yolu yoktur ve bunları pratikte gerçekten deneyene kadar hangi yolu tercih ettiğinizi bilmek genellikle zordur.

Taahhüt sıklığı, proje yönetimi tarzınıza bağlıdır. Birçok kişi, yapıyı (veya işlevselliği) bozarsa taahhüt etmekten kaçınır.

Dallar tipik olarak iki yoldan biriyle kullanılabilir: 1) Geliştirme için bir aktif dal (ve gövde sabit kalır) veya 2) alternatif geliştirme yolları için dallar.

Etiketler genellikle sürümleri tanımlamak için kullanılır, bu nedenle karışımda kaybolmazlar. 'Release' tanımı size kalmış.

Bence asıl sorun kaynak kontrolünün zihinsel tablosunun karıştırılmasıdır. Genellikle gövde ve şubelerimiz var, ancak daha sonra etiketler / sürümler veya bununla ilgili bir şeyle ilgili olmayan fikirler alıyoruz.

Bir ağaç fikrini daha eksiksiz kullanırsanız, en azından benim için daha net olur.

Gövde -> form dalları -> meyve üretiyoruz (etiketler / bültenler).

Projeyi bir gövdeden büyütmeniz fikri, daha sonra gövde dalı tutacak kadar kararlı olduğunda dallar oluşturur. Daha sonra dal bir meyve ürettiğinde daldan koparır ve bir etiket olarak serbest bırakırsınız.

Etiketler aslında teslim edilebilir. Oysa gövde ve dallar onları üretir.

Diğerlerinin söylediği gibi, SVN Kitabı başlamak için en iyi yer ve deniz bacaklarınızı aldıktan sonra harika bir referans. Şimdi, sorularınıza ...

Ne sıklıkla taahhüt ediyorsunuz? Biri ne sıklıkla ctrl + s tuşlarına basar?

Genellikle, ancak ctrl + s tuşlarına bastığınız sıklıkta değil. Bu kişisel zevk ve / veya ekip politikası meselesidir. Şahsen ben küçük ama işlevsel bir kod parçası tamamladığınızda taahhüt söyleyebilirim.

Şube nedir ve Etiket nedir ve bunları nasıl kontrol edersiniz?

Birincisi, gövde aktif gelişiminizi yaptığınız yerdir. Kodunuzun ana hattıdır. Bir şube, ana hattan bir sapmadır. Önceki bir sürüm gibi büyük bir sapma veya denemek istediğiniz küçük bir değişiklik olabilir. Etiket, kodunuzun bir anlık görüntüsüdür. Belirli bir düzeltmeye etiket veya yer işareti eklemenin bir yoludur.

Ayrıca, yıkımda, gövde, dallar ve etiketlerin sadece kongre olduğunu belirtmek gerekir. Hiçbir şey, etiketlerde çalışma yapmanıza veya ana hattınız olan dallara sahip olmanıza veya etiket-şube-gövde düzenini birlikte göz ardı etmenize engel olmaz. Ancak, çok iyi bir nedeniniz olmadıkça, konvansiyona sadık kalmak en iyisidir.

SVN'ye ne giriyor? Sadece Kaynak Kod mu yoksa burada başka dosyalar da paylaşıyor musunuz?

Ayrıca kişisel veya takım seçimi. Veri havuzumdaki yapı ile ilgili her şeyi saklamayı tercih ederim. Yani Sen gerektiğini vb yapılandırma dosyaları, inşa komut dosyalarını, ilgili medya dosyalarını, dokümanlar, içermektedir değil ihtiyaç her geliştiricinin makinede farklı olması o dosyalarda kontrol edin. Kodunuzun yan ürünlerini de kontrol etmeniz gerekmez. Ben çoğunlukla yapı klasörleri, nesne dosyaları ve benzeri düşünüyorum.

Ocak 2009'da SO podcast # 36'da yer alan Eric Sink, Source Control How-to başlığı altında mükemmel bir dizi makale yazdı .

(Eric, SourceSafe'nin fiş uyumlu bir sürümünü pazarlayan ancak korkunçluğu olmayan SourceGear'ın kurucusudur .)

Başka bir cevap kümesi eklemek için:

• Bir işi bitirdiğimde taahhüt ederim. Bazen sadece bir satırı değiştiren ve yapmam 2 dakika süren küçük bir hata; bazen de iki haftalık ter. Ayrıca, genel bir kural olarak, yapıyı bozan hiçbir şey taahhüt etmezsiniz. Bu nedenle, bir şey yapmanız uzun sürdüyse, taahhütte bulunmadan önce en son sürümü alın ve değişikliklerinizin yapıyı bozup bozmadığını görün. Tabii ki, taahhütte bulunmadan uzun bir süre gidersem, bu beni huzursuz ediyor çünkü bu işi kaybetmek istemiyorum. TFS'de bu güzel şeyi bunun için "raf setleri" olarak kullanıyorum. SVN'de başka bir şekilde çalışmak zorunda kalacaksınız. Belki kendi dalınızı oluşturun veya bu dosyaları manuel olarak başka bir makineye yedekleyin.
• Şubeler, tüm projenizin kopyalarıdır. Kullanımları için en iyi örnek, belki de ürünlerin versiyonlanmasıdır. Büyük bir projede çalıştığınızı düşünün (örneğin, Linux çekirdeği). Aylarca süren terden sonra nihayet halka sunduğunuz 1.0 sürümüne geldiniz. Bundan sonra ürününüzün 2.0 sürümü üzerinde çalışmaya başlayacaksınız ki bu çok daha iyi olacak. Ancak bu arada, 1.0 sürümünü kullanan birçok insan da var. Ve bu insanlar düzeltmeniz gereken hataları bulurlar. Şimdi, gelecek 2.0 sürümünde hatayı düzeltemez ve istemcilere gönderemezsiniz - hiç hazır değil. Bunun yerine, 1.0 kaynağının eski bir kopyasını çıkarmanız, hatayı orada düzeltmeniz ve insanlara göndermeniz gerekir. Şubeler bunun için. 1'i bıraktığınızda. 0 sürümü, bu noktada kaynak kodunun bir kopyasını yaptı SVN bir şube yaptı. Bu dal "1.0" olarak adlandırıldı. Daha sonra ana kaynak kopyanızdaki bir sonraki sürüm üzerinde çalışmaya devam ettiniz, ancak 1.0 kopya, yayınlandığı andaki gibi kaldı. Ve orada hataları düzeltmeye devam edebilirsiniz. Etiketler sadece kullanım kolaylığı için belirli düzeltmelere eklenen adlardır. "Kaynak kodun 2342 revizyonu" diyebilirsiniz, ancak "İlk kararlı revizyon" olarak adlandırmak daha kolaydır. :)
• Genellikle doğrudan programlamayla ilgili olan kaynak kontrolüne her şeyi koyarım. Örneğin, web sayfaları oluşturduğumdan, görüntü ve CSS dosyalarını yapılandırma kontrolünden bahsetmiyorum, kaynak kontrolüne de koydum. Proje belgeleri oraya gitmiyor, ancak bu sadece bir tercih meselesi.

Diğerleri bunun tarzınıza bağlı olduğunu belirtti.

Sizin için büyük soru, yazılımınızı ne sıklıkla "entegre ettiğiniz" dir. Test odaklı geliştirme, Agile ve Scrum (ve daha birçokları) küçük değişikliklere ve sürekli entegrasyona dayanır. Küçük değişiklikler yapıldığını vaaz ediyorlar, herkes araları bulur ve onları her zaman düzeltir.

Ancak daha büyük bir projede (hükümet, savunma, 100k + LOC düşünün) sürekli entegrasyonu mümkün olmadığı için kullanamazsınız. Bu durumlarda, dallamayı çok sayıda küçük taahhüt yapmak için kullanmak daha iyi olabilir, ancak SADECE işe yarayacak ve yapıya entegre edilmeye hazır olan bagajı geri getirmek daha iyi olabilir.

Dallanma ile ilgili bir uyarı, eğer düzgün bir şekilde yönetilmezlerse, herkes gövdede çalışmak için deponuzda bir kabus olabilir, çünkü herkes gövdede farklı noktalardan gelişir (bu tesadüfen en büyük argümanlardan biridir. sürekli entegrasyon).

Bu soruya kesin bir cevap yok, en iyi yol en iyi uzlaşma çözümünü bulmak için ekibinizle çalışmaktır.

Subversion ile Sürüm Kontrolü hem yeni başlayanlar hem de yaşlı eller için rehberdir.

Subversion'u en azından ilk birkaç bölümünü okumadan etkili bir şekilde kullanabileceğinizi sanmıyorum.

Taahhüt için aşağıdaki stratejileri kullanıyorum:

• mümkün olduğunca sık taahhüt edin.

• Her özellik değişikliği / hata düzeltmesi kendi taahhüdünü almalıdır (bu dosyanın geçmişini belirsiz hale getireceğinden aynı anda birden fazla dosya işlemeyin - örneğin, bir günlükleme modülünü ve bir GUI modülünü bağımsız olarak değiştirirsem ve her ikisini de aynı anda taahhüt edersem, her iki değişiklik her iki dosya geçmişinde de görülebilir. Bu, dosya geçmişini okumayı zorlaştırır),

• herhangi bir taahhütte derlemeyi bozmayın - deponun herhangi bir sürümünü almak ve derlemek mümkün olmalıdır.

Uygulamayı oluşturmak ve çalıştırmak için gerekli olan tüm dosyalar SVN'de olmalıdır. Test dosyaları ve benzerleri, birim testlerin bir parçası olmadıkça olmamalıdır.

Burada birçok iyi yorum var, ancak bahsedilmeyen bir şey taahhüt mesajlarıdır. Bunlar zorunlu ve anlamlı olmalıdır. Özellikle dallanma / birleşme ile. Bu, hangi değişikliklerin hangi hata özellikleriyle alakalı olduğunu izlemenize olanak tanır.

örneğin svn commit . -m 'bug #201 fixed y2k bug in code', tarihe bakan herkese bu revizyonun ne için olduğunu söyleyecektir.

Bazı hata izleme sistemleri (örn. Trac) bu mesajların deposunu arayabilir ve bunları biletlerle ilişkilendirebilir. Bu da her biletle hangi değişikliklerin ilişkilendirildiğini bulmayı çok kolaylaştırır.

İşimizdeki politika şu şekildedir (nesne odaklı çerçeve üzerinde çalışan çok geliştirici ekip):

• Önceki günün değişikliklerini almak için her gün SVN'den güncelleme

• Her gün hasta olun veya ertesi gün (ler) iniz yoksa, başkası kaldığınız yerden kolayca geçebilir.

• Hiçbir şeyi kıran bir kod uygulamayın, çünkü bu diğer geliştiricileri etkileyecektir.

• Küçük parçalar üzerinde çalışın ve her gün ANLAMLI YORUMLARLA taahhütte bulunun!

• Ekip olarak: Bir Geliştirme dalını saklayın, ardından yayın öncesi kodunu (KG için) bir Üretim dalına taşıyın. Bu şubenin sadece tam olarak çalışan bir kodu olmalıdır.

TortoiseSVN TSVN El Kitabı yıkım kitabına dayanmaktadır , ancak çok daha fazla dilde mevcuttur.

Sıklık kazanmanın iki yolu olduğunu düşünüyorum:

1. Uygulanan her yöntem için, kodun küçük bir kısmı vb.
2. Modüller gibi kodun yalnızca tamamlanmış bölümlerini uygulayın.

İlkini tercih ediyorum - çünkü kaynak kontrol sistemini kullanmak sadece proje veya şirket için çok yararlı değil, her şeyden önce geliştirici için yararlı. Benim için en iyi özellik, en iyi atanan görev uygulamasını ararken tüm kodu geri almaktır.