it-swarm-tr.com

Ne kadar sıklıkla taahhütte bulunmalıyım?

Yakın zamanda (dün itibariyle) kolej mezunuyum - Bilgisayar Bilimi BS. Üzerinde çalıştığım bir göreve kızgın olduğumdan beri sıfırdan başladığımdan beri versiyon kontrolünün büyük bir hayranıyım. Tüh!

O zamandan beri Bazaar ve Git'i (ve bir Yazılım Mühendisliği dersi için SVN'yi kullandığımda) kullandım, ancak çoğunlukla Git tüm projelerim üzerinde sürüm kontrolü yapmak için. Genellikle ne sıklıkta taahhütte bulunduğum konusunda oldukça sadık olurum, ancak bazen yeni bir taahhüt yazmadan önce bir süre (birkaç işlev vb.) Gideceğim.

Benim için sorum şu: Ne sıklıkta taahhütte bulunmalısınız? Eminim zor ve hızlı bir kural yoktur, ancak hangi kılavuzu izlemeye çalışıyorsunuz?

73
Wayne Werner

İşe yarayan bir şeyim olduğunda (yani, başka kimse için hiçbir şey kırmaz) Check-in yapacağım. Önce malzeme testimin çoğunu yazıyorum, yani her geçen yeni bir testim olduğunda check-in yapıyorum.

Uygulamada bu saatte birkaç kez demektir. 5 saat biraz olmak üzere, her saat en az birkaç kez.

68
Julio

Zaman esasına göre değil, özellik esasına göre işlem yapmalısınız. Taahhüt etmeye değer yeni bir özellik eklediğinizde, taahhüt edin. Bir çalışma yöntemi eklediniz mi? Teslim Et. Yazım hatası düzelttin mi? Teslim Et. Bir dosya yanlış girintiyi mi düzelttiniz? Teslim Et. Taahhüt ilgili olduğu anda küçük değişiklikleri yapmakta yanlış bir şey yoktur.

Yanlış olan, birbirleri arasında hiçbir ilişki olmadan çok sayıda değişiklik yapmaktır. Belirli bir regresyonun taahhüt kaynağını tespit etmeyi çok zorlaştırır.

Bazen, bir saat içinde yirmi taahhütte bulunurum ve bazen değiştirilen kodun miktarına bağlı olarak günde bir kez taahhüt ederim.

Küçük işler yapmak git-bisect gibi çok güçlü araçlar kullanmanızı sağlar.

Komütanın n ° 1 kuralını unutmayın: asla bagajı kırmayın. Bagajı kırabilecek birkaç taahhütte bulunmanız gerekiyorsa, bunun yerine bir şube oluşturun.

65
Thibault J

Biraz geliştirme ortamının ne olduğuna bağlı.

Bir kod tabanına katkıda bulunan tek kişi sizseniz, ertelenmiş bir taahhüt bu kadar önemli olmayacaktır. Bununla birlikte, birkaç geliştiriciden oluşan bir ekipte iseniz ve herkes "ah, biraz taahhütte bulunacağım" diye düşünürseniz, genellikle çok sayıda çatışmayı ele alıp çok zaman kaybedersiniz.

Genel kural (her iki senaryo için): Mümkün olduğunca sık taahhüt edin. "Henüz hazır değil" (yapıyı bozacağından veya henüz tamamlanmadığından) düşünüyorsanız, bir şube oluşturun ve bu dalı taahhüt edin, ancak taahhüt ettiğinizden emin olun.

10
perdian

Günde en az bir kez, genellikle üç veya dört, her zaman bir mola veriyorum. Kendi başıma çalışıyorum, bu yüzden başka birini karıştırmak için endişelenmem gerekmiyor ve yanlış yola gittiğimi düşünürsem her zaman bir dosyayı geri alabilirim.

Düzenli olarak taahhütte bulunmadığım ve sabit sürücümün çöktüğü bir kaç kez kötü bir deneyim yaşadım ve birkaç saat çalışmayı kaybettim. Depom başka bir makinede olduğu ve düzenli olarak yedeklendiği için hiçbir şeyi kaybetmemem için hiçbir neden yok.

7
vjones

Git şubeleri ve nasıl kolayca yönetildikleri sayesinde, gerçekten sık sık taahhütte bulunuyorum. Şunu söyleyebilirim ki, önemli olduğunu düşündüğünüz ve daha sonra bir şeyler inşa etmenizi gerektirebilecek bir şey eklediğinizde, taahhüt etmelisiniz.

Ayrıca, sık sık kendimi yeni koddan önce bazı yeniden düzenleme ve yeni testler yaparken buluyorum, bu nedenle testi her çalıştırdığımda, başarısız olduğunu, tekrar geçmesini ve yeniden düzenlediğim için taahhüt ediyorum.

Ayrıca, herhangi bir hatadan sonra ne kadar küçük veya önemsiz göründüğü önemli değil.

Bazen "derler derlemez" yoluna da iniyorum.

6
Edgar Gonzalez

DVCS'de temelde, geri alamazsam gerçekten sinir bozucu olacak bir değişikliğe başladığımda, başkalarıyla paylaşmam gerektiğinde veya o zamandan beri ne değiştirdiğimi görmek gerçekten yararlı olur. Bu, günde birkaç kez ila günde birkaç kez arasında değişir. Ayrıca, derlemem en azından derhal segfaults olmadan derlenmediğinde ve çalıştırılmadığında çok nadiren taahhüt ediyorum, ancak bu hata için sadece düzeltmeyi izole etmek ve paylaşmak istiyorsanız da yararlı olabilir.

İşinizde kullanmanız çok muhtemel olan merkezi sürüm kontrolü ile, genellikle bunu yapmak için kızgın bir e-posta fırtınası almayacağınızdan emin olana kadar taahhütte bulunmazsınız. Yaptığınız değişikliklerin ne kadar bağımsız olduğuna ve şirketinizin sürekli entegrasyon dogmasına ne kadar abone olduğuna bağlı olarak, bu daha büyük bir yeni özellikte günde bir kez olmak üzere ayda bir kez olabilir.

Bu frekans farkı, şirketimin resmi merkezi VCS'sinin üstünde git kullanmamın temel nedenlerinden biri.

5
Karl Bielefeldt

Bir yapı sunucusuyla bir ekip ortamında çalışıyorsanız, yalnızca bir şey oluşturduğunuzda işlemek istersiniz. Aksi takdirde ekibin geri kalanı için çok can sıkıcı :)

3
John Shaft

Bunu son zamanlarda izledim Joel On Software - FogBugz/Fırın sunum ve yakın zamanda sorunuzun iyi olduğunu düşünüyorum.

Bazı sürümlerde kontrol 'taahhüt' dağıtılmış VCS'de 'yayınla' (veya 'başkalarına acı ver') ile eşanlamlı iken, genellikle ayrılırlar.

Dolayısıyla ne zaman taahhütte bulunacağınız, kullandığınız VCS'ye bağlı olabilir.

1
Greg Domjan

Her başarılı derlemeden sonra otomatik olarak çalışın.

Önceki bir sürüme geri dönmek istiyorsanız ve geri dönmek istediğiniz noktanın yaklaşık duvar saati süresini hatırlayabiliyorsanız, bu düzeltmeye bakabilirsiniz.

Tabii ki TDD kullanıyorsanız daha iyi entegre çözümler var.

0
rwong

Her gece eve gittiğimde otomatik olarak tüm şubelerimin üzerinden geçip bir taahhütte bulunacak bir senaryom var (tüm geliştiricilerin bu değişiklikleri alamadığını unutmayın. Bu sadece benim kişisel şubem). Bu şekilde düşünmek zorunda değilim.

Ayrıca sabahları otomatik olarak bir güncelleme çalıştıracak bir senaryom var. Bunu dizüstü bilgisayarımdan gece çalışırsam değişiklikleri otomatik olarak sabah orada olacak şekilde kullanıyorum.

Gün içinde yaptığım değişikliklerin geri alınmasına gelince, editörüm tüm değişikliklerin bir geçmişine sahiptir ve her kaydetme/derleme taahhüdünden çok daha hızlıdır.

0
barrem23

Yalnız çalışıyorum. Geliştirme ortamım dizüstü bilgisayarım. Taahhüt ortamı web'deki bir sunucudur.

İstemci ilerlemeyi izlemek için web sunucusunu kullanıyorsa. Neredeyse her gün yeni bir şey söyleyen bir e-posta ile birlikte bir yükleme yapıyorum.

Taahhüt ortamı bir üretim ortamı ise, herhangi bir taahhütten önce test edilen her değişiklik için daha dikkatli olmalıyım. Ancak yine de, kimsenin yeni özelliğin önceden planlanmış veya planlanmış olup olmadığından şüphesi olmadığından, genellikle daha iyi görünüyor; ASAP için istediklerini alırlar.

0
Andy Canfield