SVN ile başlıyorum. Temel komutları biliyorum ve temel ilkeleri anlıyorum. Bir ekip ortamında Subversion ile çalışmak için herhangi bir ipucu veya en iyi uygulama olup olmadığını merak ediyordum.
Kodu işlerken makul ölçüde ayrıntılı mesajlar eklemenin faydasını görebiliyorum, ancak aklımda tutmam gereken başka şeyler var mı?
Tüm harika cevaplar için teşekkürler - çok yardımcı oldular.
Yanıtlar:
Sık taahhütleri teşvik edin. Sürüm kontrolüne yeni başlayan takım arkadaşları, kodu "düzgün çalışana kadar" havuzun dışında tutmaları gerektiğini hissedebilirler. Herkese erken ve sıklıkla sorunları mümkün olan en kısa sürede bulmayı öğretin. Kodu işe yarayana kadar tutmak yerine, ekip arkadaşlarınızın gövdeyi kırabilecek özellikler için dallar oluşturmasını önerin. Şuna gider...
Dallara ayırma ve etiketleme uygulaması oluşturun. Özelliklere yönelik dallara ek olarak, ekip arkadaşlarınızı büyük hata düzeltmeleri için dalları kullanmaya teşvik edin. Çalışmanın başında ve sonunda önemli hata düzeltmelerini etiketleyin. Üretim / qa sürümleri için etiketleri (ve muhtemelen dalları) koruyun.
Gövde için bir politika belirleyin ve ona bağlı kalın. Bir örnek, "gövde her zaman hatasız inşa edilmelidir" olabilir. veya "gövde her zaman tüm birim testlerini geçmelidir". Henüz gövde standartlarını karşılamayan herhangi bir iş bir şubede yapılmalıdır.
Kod değişiklikleriyle biçimlendirme değişiklikleri yapmayın
Devasa bir dosyanın boş alanını yeniden yapılandırmak istiyorsanız ( Control+ K+D ) , sorun yok. Biçimlendirme değişikliğini gerçek mantıksal değişiklikten ayrı olarak gerçekleştirin. Dosyalarda işlevleri taşımak istiyorsanız da aynı şey geçerli. Taşıma işlemini gerçek düzenlemeden ayrı olarak gerçekleştirin.
Her zaman bağlı kaldığım temel kavramlardan biri, ilgili kod değişikliklerini birlikte uygulamaktır . Sonuç , aynı işlemede ilgisiz kod değişikliklerini işlememektir . Bu, bir işlemede 2 hatayı düzeltmeyin (aynı düzeltme olmadığı sürece) ve 2 işlemin her birinde yarım hata düzeltmesi yapmayın. Ayrıca, sistemin ilgisiz bir bölümüne yeni bir geliştirme veya başka bir iş için ihtiyaç duyduğum bir şey eklemem gerekirse, geliştirmeyi ayrı olarak (ve önce) yaparım. Buradaki fikir, herhangi birinin kendi başına sahip olmak isteyebileceği (veya kendi başına geri döneceği) herhangi bir değişikliğin ayrı bir taahhüt olması gerektiğidir. Birleştirme yapma veya bozuk özellikleri geri alma zamanı geldiğinde sizi tonlarca baş ağrısından kurtaracaktır.
Zaten çok şey bahsedildi ve işte biraz daha:
Kaynak kontrolünde istemediğiniz dosyalarınız varsa (ör. Yapılandırma, derlenmiş dosyalar, vb.), Bunları yok sayma listesine ekleyin . Bu şekilde, eklemeyi unuttuğunuz dosyaları, her zaman SVN tarafından bilinmeyen olarak gösterilen boş bir dosya listesi bekleyerek fark edersiniz.
Taahhüt edilen değişiklikle ve ideal olarak bunun için yama ile ilgili olarak geliştirici posta listenize (veya bu hedef için belirli bir e-posta) gönderecek bir post commit etkinliği ekleyin .
Hata izleyicinizle entegre edin, böylece taahhütlere referanslar, farklara bağlantılarla hatalar / özellik isteklerinde gösterilir. MantisBT gibi hata izleyiciler bunu destekliyor.
Sürekli entegrasyon (örneğin CruiseControl.NET ), NAnt for Build ve birim testleri için NUnit / VS ile entegre etmeyi düşünün . Bu şekilde, bir kullanıcı kodu kontrol ettiğinde veya programlanmış bir aralıkta kod derlendiğinde, birim testleri çalıştırılır ve geliştirici işlemle ilgili geri bildirim alır. Bu aynı zamanda havuzun kırılması (yani oluşturulmaması) durumunda ekibin geri kalanını da uyarır.
Temel bilgiler:
İnsanların verdiği cevaplar harika. Bunun çoğu, SVN için en iyi uygulamalar için svn kullanıcı belgesinde özetlenmiştir .
Tekrarlamak için:
Bağlı olduğum en iyi uygulamaları şu şekilde özetlemek isterim:
Depo yapısı olmalıdır . Şahsen aşağıdaki depo yapısını kullanıyorum:
/trunk
/tags
/builds
/PA
/A
/B
/releases
/AR
/BR
/RC
/ST
/branches
/experimental
/maintenance
/versions
/platforms
/releases
PA(alfa öncesi), A(alfa), B(beta), AR(alfa sürümü), BR(beta sürümü), RC(sürüm adayı), ST(kararlı).En iyi yıkım uygulamalarımın ana hatlarını, kullandığım yazılım konfigürasyon yönetimi yaklaşımının ana ilkelerini gösteren şema şeklinde bulabilirsiniz .
Çok yararlı bulduğum bir şey svn: external property, yani diğer depolardan kendi dizinlerine de başvurabilirsiniz. Kodunuzu ve verilerinizi düzenlemenin gerçekten güzel yollarını sunar. Bazı örnekler:
Hata izleme yazılımınızla entegrasyonu kullanın. Eğer kullanırsanız Bugzilla yorumunuz "Bug XXXX" SVN açıklamaya otomatik olarak bu değişikliğin SVN web arayüzü size bir bağlantısı da dahil verilen hatadan bir yorum olarak eklenir ile başlıyorsa, bunu o kadar ayarlayabilirsiniz.
SVN'nin dallanma ve birleştirme araçları ve kuralları hakkında bilgi edinin.
Diğer ekip üyeleriyle çalışmanın en iyi yolu, çalışmayı eksiksiz geliştirme özelliklerine / düzeltmelerine ayırmak, ardından her biri bir dalda bireysel değişiklikler üzerinde çalışmaktır. Ardından, tamamlandığında / birleştirilmek üzere hazır olduğunda / onaylandığında değişiklikleri ana hat dalına / ana hatla birleştirin.
Bu şekilde bireyler, diğer değişikliklerle çarpışmadan ortak bir hedef için (aynı dalda veya ayrı dallarda) çalışabilirler.
Kilometreniz değişebilir ve bu sadece iki veya daha fazla kişi için aşırı olabilir.
SVN ile iyi entegre olan iyi araçlar kullanıyorsanız, bu çok daha kolay hale gelir. Bunlar, nelerin değiştirildiğini görmenizi ve ardından değişikliklerinizin tamamını veya bir kısmını gerçekleştirmenizi ve çalışma kopyanızı SVN'deki en son sürüme sık sık güncellemenizi kolaylaştırır.
Tortoise SVN (Windows kullanıyorsanız) ve Visual SVN'yi öneririm (VS kullanıyorsanız) .
Ayrıca, herhangi bir değişiklik yapıldığında e-posta veya benzer bir bildirim alacak şekilde ayarlayıp ayarlayamayacağınıza bakın (genellikle ayrıca commit mesajı ve değiştirilen dosyaların bir listesi dahil). CVSDude gibi hizmetler bunu sunar. Çalışma kopyamı güncellemeden önce hem bir güncellemenin yapıldığını bilmek hem de bu güncellemede neler olduğuna dair bir fikir sahibi olmak bana yardımcı oluyor.
Dallanma politikalarının yanı sıra ve diğerleri. (tek bir boyut kesinlikle herkese uymadığında), iyi taahhütlere sahip olmalısınız:
Kaynak kontrolü için altın kural: Erken Giriş, Sık Kontrol Et
Deponuzu nasıl organize edeceğiniz konusunda ipuçları için:
Herhangi bir birleştirme çakışmasını düzeltmeden önce, değişiklikleri hakkında ekibinize danışın veya en azından farka çok dikkatli bakın. Eklemelerinin birleştirme sırasında kaybolmadığından emin olmak için birleştirilmiş kodu kendilerinin gözden geçirmelerini isteyin.
Bozuk taahhütleri azaltan gördüğüm bir şey, iyi pre-commit komut dosyalarına sahip olmaktır. Örneğin, değişiklik yapılmadan önce herhangi bir birim testi çalıştırabilirsiniz. Bu, taahhütlerin biraz yavaş olmasına neden olur, ancak birinin ayak parmaklarına basmaktan ve özür dilemek zorunda kalmadan zaman kazanırsınız. Elbette, büyük bir geliştirme ekibiniz ve çok sık taahhütleriniz olduğunda bunu yönetmek çok daha zor hale geliyor.
Hata izleyici ve commit politikası uygulama ile entegrasyon örneklerinden biri Trac'ın svn pre / post-commit kanca betikleri olabilir; bu komut dosyaları, commit mesajı hata izleyicideki herhangi bir bileti referans almıyorsa ve mevcut mesaj içeriğine dayalı biletler (yani taahhüt mesajı "Düzeltme # 1, # 2 ve # 8" gibi bir şey içerebilir, burada # 1, # 2, # 8 bilet numaralarıdır).
SVN'yi kullanmak için en iyi uygulama :
Eclipse projenizi ilk kez ofise geldiğinizde ve açtığınızda , yapılması gereken ilk adım projenizi güncellemektir.
Güncellemeyi aldıktan sonra işinize başlayın. Kodlamanızı bitirdiğinizde, uygulamanızın istisnasız düzgün çalışıp çalışmadığını kontrol edin. Kodunuzun iyi çalıştığından emin olduktan sonra, kodu işleme zamanı.
Not: Kodu işlerken doğrudan kaydetmeyin. Sunucu ile bir senkronizasyon yapın ve nelerin yapılması gerektiğini kontrol edin. Not: Tüm klasörü bir kez kaydetmeyin. Çünkü gereksiniminiz için dosyada bazı değişiklikler yapmış olabilirsiniz veya yerel sisteminizdeki bazı dosyaları silmiş olabilirsiniz. Ancak sunucuda ayarlar farklıdır. Bu yüzden dosyaları ayrı ayrı kontrol edin ve kodu işleyin.
Çatışma dosyalarını doğrudan işlemeyin / güncellemeyin.
Geçersiz kılma ve güncelleme ne zaman yapılmalı?
Yerel değişikliklerinizin hiçbirine ihtiyacınız olmadığından hemen hemen emin olduğunuzda ve sunucu kopyasını tamamen güncellemek istediğinizde. Bir kez geçersiz kılma ve güncelleme yaparsanız, yerel değişikliklerinizden hiçbirini almayacağınızı unutmayın.
Not: Güncellemeden projeyi bir günden fazla tutmayın. Ayrıca kodu günlerce taahhüt etmeden saklamayın.
Kimlerin aynı bileşende çalıştığını iletin ve her gün hangi değişiklikleri yaptıklarını tartışın.
Herhangi bir sebep olmadıkça özellikleri ve yapılandırma dosyasını işlemeyin. Çünkü ayarlar bir sunucuda ve bulutta farklı olacaktır.
Hedef klasörleri SVN'ye kaydetmeyin, yalnızca kaynak kodu ve kaynak klasörleri bir SVN deposunda tutulmalıdır.
Kodunuzu kaybettiğinizde panik yapmayın! SVN geçmişinden önceki kopyayı geri alabilirsiniz.
Projeyi diskinizin birden fazla yerine teslim etmeyin. Tek bir yerde kontrol edin ve onunla çalışın.
SVN kendi başına iyi bir başlangıçtır ve diğer bazı posterler en iyi uygulamalarla ilgili harika önerilerde bulunmuştur.
Ekleyeceğim tek şey, Sürekli Entegrasyon sürecini yürütmek için SVN'yi CruiseControl veya TeamCity ile bağlamanız gerektiğidir. Bu, yapı e-postaları gönderecek ve biri yapıyı bozduğunda herkesin bilmesini sağlayacaktır.
Sürecinizi kimin takip ettiği ve kimin olmadığı konusunda erkenden çok şey söyleyecektir. Biraz sürtüşmeye yol açabilir, ancak takımınız uzun vadede daha iyi durumda olacaktır.
Her işlem için kesin yorum
(Ana hat) yapısını bozmayın!
Mantıksal birim değişir değişmez taahhüt et
Subversion'ı bir yedekleme aracı olarak kullanmaktan kaçının
Mümkün olduğunca biraz dallanma / birleşme
.
SVN en iyi uygulamalarında daha fazla ayrıntı bulunabilir .
Taahhütlerinizi ne kadar artımlı, modüler, ayrık ve özlü yaparsanız, sizin (veya muhtemelen başkalarının) şunları yapmanın o kadar kolay olacağını unutmayın:
Bunu yorum şablonu için kullanın:
[görev / hikaye xxx] [ikincil / büyük] [yorum] [yorumu takip et] [Hatanın URL'si]