Ekibim kaynak kontrolü için Team Foundation Server kullanıyor ve bugün kontrol etmeden önce bazı hataları ve duman testi uygulamalarını düzelttim ancak bazı kodları yorumlamayı unuttum. (Bu kod kullanıcı arabirimini biraz garipleştirdi.)
Kodları kontrol etmeden önce hangi iyi uygulamaların olduğunu bilmek istiyorum - bu tür bir hata yapmak istemiyorum.
Yanıtlar:
Yapma alışkanlığımı edindiğim bir şey de, teslim etmeden hemen önce, kontrol etmek üzere olduğum her dosyanın farkına bakmak.
Yorum yapma kodunu hiçbir zaman girmemelisiniz. Check-in işlemlerinden önce yorum yapmanız gereken bir kodunuz varsa, bunu yanlış yapıyorsunuz demektir.
Kurallara gelince:
İnşa etmek
3.1 Yapı hatalarını düzelt
Testleri çalıştırın
4.1 Bozuk testleri düzeltin
1’e gidin (elde edilecek yeni bir şey olmayana kadar)
Sadece tüm adımlar tamamlandığında kontrol edin.
Check-in dansına bakın .
Diğer iyi uygulamalar:
rebase -ive yerel tarihinizi temizleyin, gerektiği gibi ezilme taahhütleri verin, böylece ana hattın çirkin devam eden bir taahhütü yoktur.
Çok fazla burada pantsweasel ait olmaya çalışıyorum değilim, ama bu söz konusu varsayım (ve tüm ama cevapların bir) çoğunlukla TFS, SVN, Perforce, vb gibi merkeze bağlı VCS için geçerlidir
yeterince adil, ne var OP kullanıyor.
Öte yandan, DVCS (Mercurial ve Git gibi) kullanırken, genellikle kontrol etmeyi beklememelisiniz ve cevaplarda belirtilen şeylerin çoğu - fark, en son, birleştirme, vb. - gerekli değildir . Kod incelemeleri ve testler gibi şeyler bile kontrol ettikten sonra yapmak için daha iyidir (belki zorlamadan önce, bağlı olarak ...)
Burada (şu ana kadar) gördüğüm bir istisna, bir iş öğesiyle ilişkilendirmektir. Tabii ki, checkin hakkında yorum yapmak da iyidir ...
Diğer cevaplarda görmediğim üç şey:
Yeni dosyalar ekle
Değişmeyen dosyaları geri al
Gönderdiğiniz taahhütleri kontrol edin
Git'i kullandığımda iki şey:
Atomik taahhüt:
git add --patchGerekirse değişikliğimi birden fazla parçaya bölmek için kullanıyorum .Özetlerken farkları görüntüleme
git commit --verboseederim, böylece değişiklik mesajımı yazarken yaptığım değişikliğin farkını görebiliyorum. (Ya da farkı göstermek için yamalı git-vim'imi kullanırım.)Ekibimin sunucularında uygulayacağım birkaç 'iyi uygulama' öğesi oldukça açık. Öncelikle, check-in işlemine başlamadan önce, kodunuzda herhangi bir kimsenin çarpışmayacağını kontrol etmediğinden emin olmak için daima en son halini almalı ve yerel bir yapı kurmalısınız. Ayrıca, sunucunuzla değil yerel makinenizdeki kod çakışmalarına dikkat edin. Kodunuz, en son indirilen kod ile birlikte, doğru bir şekilde oluşturup, çalıştığı onaylandıktan sonra bir sonraki adıma hazırsınız. Herhangi bir otomatik sınama gerçekleştirin ve daha sonra düzgün çalıştıklarından emin olmak için girişinize başlayın. O zaman, sadece emin olmak için, en son tekrar alın.
Tüm check-in'lerde yorum yapmaya zorlamak bir TFS Yöneticisi olarak mümkündür. Uygulanıp uygulanmadığına bakılmaksızın, her zaman işiniz için check-in yorumları girmenizi tavsiye ederim. Bunu yapma seçeneğiniz varsa, uygulayın. Yorumların, en azından, kodunuzu en son kontrol ettiğinizden bu yana değiştirdiklerinizin genel bir özeti olduğundan emin olun. bu check-in sırasında değiştirildi. Kırık bir yapı hata ayıklama çok daha kolay hale getirir.
Ayrıca, TFS Yönetici ayrıcalıklarına sahipseniz, check-in işlemlerinde haddeleme yapılarını uygulayın (check-in işlemleri bir şeyi kırarsa hemen herkesin bildiğinden emin olmak için) ve sunucuyu kapılı bir check-in gerçekleştirecek şekilde ayarlayabilirsiniz ( işaretlenen kod yapıyı bozarsa, sunucu bunu reddeder), ya da basitçe bir hata oluşturmasını ve yapıştıran kişiye atamasını sağlayabilirsiniz.
Her şeyin yolunda gitmesini sağlamak için açabileceğiniz veya kapatabileceğiniz ya da TFS-Yöneticinize işleri güzel ve temiz tutmak için açmanızı önerebileceğiniz birkaç seçenek var ... ama bunlar büyük ölçüde tercih edilir
Windows’tan check-in yaptırıyorsanız, kodunuzun görünmez ^ M karakterleri olup olmadığını kontrol edin - UNIX’deki editörler genellikle bunun için hatalar / uyarılar verir.
Ayrıca sekmeleri de deneyin ve değiştirin; farklı kullanıcılar, bazılarının 4 boşluklu, bazılarının 8 kodlu ve kod okunabilirliği için iyi olmayan sekme çubuklarını farklı şekilde görmesini sağlar.
En iyi yaklaşım IMHO, önceden tanımlanmış bir komut dosyasının kodunuzu kuruluşunuzun kodlama kurallarına göre kontrol etmesini sağlamaktır. Kaynak kontrol sistemlerinin yükleri bu işlevselliğe sahiptir.
Şirketimde check-in incelemeleri kullanıyoruz. Bunların ayrıntılı olması gerekmez, ancak yalnızca bir kişiye changelistinizdeki farklılıkları göstermek ve onlarla konuşmak bazen testlerde kaçırdığınız tuhaf yazım tipini vurgulayacaktır.
Kaynak kontrol sunucumuz, yorum yazarının yorumlarına not vermediğiniz sürece check-in yapmanıza izin vermez (formda! Harfleri, örneğin, Bruce Wayne incelemenizi yaptıysa BW). Gözden geçiren kişi, incelemeye yardımcı olduklarını belirten bir e-posta alır. Bu bariz sömürüye açık, ancak gayet iyi çalışıyor gibi görünüyor.
Mümkün olduğunda, bir girişi bir iş öğesiyle ilişkilendirmeyi seviyorum. Bu size NEDEN değiştirildiği değil, NEDEN değiştirildiğine dair bazı bağlamsal bilgiler verir. TFS oldukça iyi bir iş öğesi izleme sistemine sahiptir, bu yüzden check-in sırasında yapması çok önemsizdir.
(Bu benim değişikliklerin farklılığını gözden geçirmenin yanı sıra)
Yaptığım küçük bir şey, gerçekten değişmemiş dosyaları teslim etmemek. Bu dosyalar istemeden değiştirilmiş veya geri alınmış ya da başka şekilde kararsız hale getirilmiş yeniden yapılanmalara dahil olmuş olabilir.
Bu şekilde, değişiklik kümeniz (bir iş öğesiyle ilişkilendirilmiş), iş öğesini tatmin etmek için gereken dosyaları tam olarak içerir.
Tüm cevapları burada birleştirmek ve eksiksiz bir kontrol listesi vermek için
[check-in / check-out] doğrudan diğerlerinin çalıştığı akıma giriş yapmamalısınız. Bir akış stratejisine sahip olmalısınız: örn. geliştirici başına, başkalarını rahatsız etmeden bağımsız olarak kontrol edip kontrol edebileceğiniz bir akış: Güvende olun ama kendi gelişim akışınızda [yalnızca kendi gelişim akışınızda]. İçinizdeki her kontrolde, değişikliklerinizi değişiklik kümesi adı verilen değişikliğe karşı atomik olacak şekilde bir değişiklik kaydıyla ilişkilendirin (böylece 'her şeyi' vermek zorunda kalmadan tek tek rfc / böcek vb. Dağıtabilirsiniz).
[daha sonra takım akışınızla yeniden derleyin] bu, diğer akışlardaki değişiklikleri kendi akışınızda aldığınız anlamına gelir. Bu işlem sırasında birleştirme iletişim kutusundaki tüm "farkları" görebilir ve bunlardan geçebilirsiniz veya ... binlerce varsa ve / veya kod kullanmıyorsanız, aynı zamanda örneğin veri modelleri / siebel projeleri vb. önemsiz olmayan birleşme, önemsiz-otomatik ve önemsiz manuel birleştirme, son kategoride zor olanları içerir. Hala kendi akışında çalıştığını unutma.
[tamam rebase] Her şey yolundaysa, ekip akışından yeni aldığınız tüm değişiklikleri kontrol edin: kendi akışınız artık güncel
[teslim et] şimdi çalışmanızı takım akışına iletin. Eğer her şeyi vermek istemezseniz, o belirli dosya sürümleriyle veya çözülmüş bir RFC / kusur kümesiyle örneğin 1 belirli RFC seçebilirsiniz.
[test sunumu] tamam olmalı, ancak bu arada bulunan birinin de değişiklik yapma şansı olduğu için değişiyor: çalışmanızın takım akışındaki en son değişikliklerle çalışıp çalışmadığını test edebilirsiniz. Aynı birleşme diyalogları ile farklılıklar gösteriyor.
[Teslimat tamamla] Teslimatı tamamla ve işin şimdi takım akışında.
Daha karmaşık hale getirmek için: Teslim ettiğin işin hala şansı olduğu için = tamam ANCAK, zaten bir başka sürüm üzerinde çalışıyorsun, her zaman teslim edildikten sonra temel almalısın ve hangisinin hangi kullanıcıların temel almasını istediğini belirle . Bu, diğer geliştiricilerin akıştaki en son sürümden değil önerilen bir sürüm aldıklarından emin olmanızı sağlar (bu senaryoda çalışıyorsanız). Bu aynı zamanda Üçlü bir kontroldür, böylece ekip akışındaki en son sürümler "kötü" olsa bile, hala başkalarının yeniden derlediği veya baktıkları sürümler değildir ve yapılandırma yöneticiniz geri almak için önceki sürümü bir sonraki sürümle birleştirebilir. senin teslimatın.
Örneğinizde, kodu yorumlamayı unuttuğunuzu belirtirsiniz. Hatalar olur. Çevresindeki konfigürasyon yönetim sistemi bununla ilgilenmelidir. Gerçekten de biri binlerce örnekte ortaya çıkıyor ve zaman içinde zincirlenmiş ve işlenmiş farklı sunucularda akışların hiyerarşisinde "inşa ediyor" ve "entegrasyonların" gerçekleşmesi olabilir. Bu yüzden, 5 ay sonra bile yorumlu kodunuz bir entegrasyon sunucusunda test edilir, çünkü kodunuz diğer kod ve sistemlerle entegrasyona ihtiyaç duyar, değişiklik setinizi atomik olarak almanız ve hala devam etmeniz mümkündür. Bu yüzden en iyi uygulama az ya da çok daha yüksek düzeydedir. Konfigürasyon yönetimi akışlarının genel tasarımı bununla ilgilenmelidir. Bireysel geliştiriciler için en iyi uygulama onaylama / ünite testini yapmaktır. Ama büyük resimden "
Aşağıdakilerden bazıları SCM'nize bağlı olarak diğerlerinden (veya farklı şekillerde) daha fazlasını uygular, işte burada:
NOT : Yukarıdakilerin bir kısmı oldukça açık gözükmektedir, ancak aslında ne kadar insanın ana dalda çalıştığına veya ilk önce üretimde değişiklik yaptıklarına inanmazsınız ve sonra da doğrudan ana dalda sürüm kontrolüne geçmek için el ile deltalar yaratırsınız. .. ve etiketleri ile. Yıkanmamış koltukaltı suyu ile karıştırılmış fermente safra gibi tatlı ... evet, böyle.
Kişisel bir kontrol listesi var. Bir girişte, karışıklık, boş başla. İkinci doğa olduğunda listeden çıkar.
Testleri yap. Geçerlerse kontrol edin. Eğer karışırsanız ve bir şey testleri geçerse, o zaman bir test yazın.
Aşağıdakileri yapıyoruz ...
Test - Çalıştığından emin olmak istiyoruz. En azından bir şeyin bozulmadığını bilmek istiyoruz.
Kod incelemesi veya en azından bir arkadaş kontrolü - Bu, bilginin yayılmasını ve insanların güncel kalmasını sağlamak için harika bir yoldur. Ayrıca olayları kontrol etmeden önce böcekleri yakalamaya yardımcı olur.
Önceden bildirim gönderme - Giriş yapmadan önce gruba bir ön bildirim gönderilir. Amaç, başkalarının yalnızca hangi dosyaların veya alanların değiştiğini bilmelerini sağlamak değil, aynı zamanda değişikliklerin onları etkilemesi beklendiğinde, onlara kafa karıştırır (dikkat etmeyi seçmeli mi).
Ön bildirim gönderildikten birkaç saat sonra check-in yapılır ve grup e-posta ile bilgilendirilir. Gruptaki herkes, bir hata veya özellik üzerinde belirli bir işin ne zaman yapıldığını bilebilir.
Teslim etme bildiriminin bir kopyası, hata veya özellik ile ilgili düzeltme kaydına yapıştırılır. Kayıtlar arasında arama yaparken, düzeltmenin / özelliğin ne gerektirdiği hakkında bir fikre sahip olmanın çok kullanışlı olduğunu görüyoruz.
Çok titizlikle üzerinde çalıştığınız birim testlerinizi çalıştırın. Yeşil iyidir.
Kodunuzun doğru biçimlendirildiğinden emin olun (örneğin, Java için: kodunuzu seçin ve Eclipse'de Ctrl-Shift-F tuşlarına basın). Fakat aynı belgenin tamamı için aynı şeyi yaparken dikkatli olun.
Her zaman, her zaman, her zaman , yaptığınız değişikliklerin yapıyı bozmadığını kontrol edin. Özellikle önemsiz görünebilecek küçük değişiklikler.
Bir keresinde hafta sonu işe gitmeden hemen önce herhangi bir soruna yol açmayacağını düşündüğüm çok küçük bir değişiklik yaptım. Yeterince, bu küçük değişiklik yapıyı bozdu ve projemiz için hiçbir gece deneme çalışması yapılmadı. Soru-Cevap şefi bu konuda çok mutlu değildi ve haklı olarak.
Bağımsız birimler olarak girebileceğiniz değişikliklerin bazı bölümlerini arayın.
Genelde, kod üzerinde bir çalışma düzeltmesi veya geliştirmesi olduğunda, birkaç değişiklik var. Bazıları benim için gittiğim davranış değişikliğine özgü; diğerleri ise bu değişikliği daha temiz hale getirmek için yaptığım refactorings.
Her yeniden düzenleme için ayrı ayrı kontrol etmeyi tercih ediyorum, bunun gibi kendi açıklama açıklaması var:
REFACTORING: X ile Y arasında bir isim verin
X daha önce anlamlıydı çünkü ... ama şimdi Y olması gerekiyor. Bu, 9 no'lu sayı için çalışmayla ilgili.
Sonra, her iyi refactoring kontrol edildikten sonra, son davranış değişikliği genellikle önemsizdir.
Ayrıca, bazı değişiklikler birçok kod satırını etkiler ancak çok ilginç değildir, diğer değişiklikler çok yerelleştirilmiştir ancak önemli bir etkiye sahiptir. Bu değişiklikler birlikte kontrol edilirse, farkları okumak zor olabilir. Bu yüzden onları ayrı tutuyorum.
Daha sonra, biri değişim tarihini okurken, olayların mevcut duruma nasıl geldiği ve neden bu şekilde oldukları açıktır. Davranış değişikliğimi geri almak da büyük önem taşıyor çünkü tonlarca başka düzenlemeyle karıştırılmadı.
Birinden ödünç aldığınız bir şeyi iade ederken ne yaparsanız yapın. Temiz ve iyi durumda olduğundan emin olun. Bir karışıklık çıkardıysanız, kodu sahibine (çoğu durumda işvereninize) geri göndermeden önce temizlediğinizden emin olun.
İşim için yerel bir depo tuttum.
Bunların en iyisi olduğunu iddia etmiyorum, ama benim için çalışıyorlar.
Eklediğiniz veya değiştirdiğiniz her şeyi iyice test edin. Denemeyi düşünebileceğiniz her olayı deneyin. Testleri KG'ye bırakmayın. Her zaman bir sandviçim olsaydı, küçük bir değişiklik yaptım ve sonra sadece güvenli tarafta olmak için bazı test davaları denedi ve hemen bir sorun gördüm, çok fazla sandviç alırdım. Genelde kendime yüksek sesle söylüyorum: "Bunu denediğim için gerçekten mutluyum ..."
Değişimin ardından kullanıcı arayüzünün garip olduğunu söylüyorsunuz. Programı sadece çalıştırıp kontrol etmeden önce UI'ye bakarsanız, sorunu fark eder miydiniz?