Yalnız geliştirici için en iyi sürüm kontrol alışkanlıkları?

İşimde tek geliştiriciyim ve VCS'nin faydalarını anlarken; İyi uygulamalara sadık kalmayı zor buluyorum. Şu anda çoğunlukla web uygulamaları geliştirmek için git'i kullanıyorum (işim nedeniyle asla açık kaynaklı olmayacak).

Şu andaki iş akışım, geliştirme alanında çok fazla değişiklik yapmak, test etmek, revize etmek, test etmek, mutlu olmak ve değişiklik yapmak, ve ardından canlı siteye olan taahhüdümüzü itmek (büyük bir yeni değişiklik üzerinde çalışıyorsam; haftada bir kez taahhütte bulunmakla birlikte, IDE’nin işlenmemiş şeyler için iyi bir geri alma geçmişi var).

Temel olarak, sadece makineler arasında geçiş yaparken git (örneğin, ev bilgisayarını bilgisayarla veya canlı makineyi çalışarak) kullanıyorum, ancak gün boyunca gerçekten fayda göremiyorum. Bu beni uzun bir çamaşır yıkama değişim listesine soktu (ve her iş için iyi msj bulmakta zorlanıyorum; ve ne zaman acelem varsa - 'yönetici ve şablonlarda misc değişiklikleri' gibi berbat mesajlar bırakma eğilimindeyim).

Ne sıklıkla taahhüt etmeliyim? Her bir satırlık değişiklik bir taahhüt almalı mı? Herhangi bir testten önce taahhütte bulunmalı mıyım (örneğin, en azından sözdizimi / derleme hataları için ve sonra tamamen geri almalıyım; fikir işe yaramadıysa veya mesaj yalandıysa)?

Her sabah / öğleden sonra hala taze iken akşam yemeği için çalışmayı bırakmadan önce iş yaptığımdan emin olmalı mıyım? Kötü VCS alışkanlıklarına sahip olarak neyi özlüyorum?

Çok özlüyorsun.

Ben de yalnızım, bir şekilde. Her seferinde önemli bir değişiklik yapmayı veya önemli bir tanesine başlamadan önce, işleri berbat edersem geri dönebiliyorum ve şimdi ve sonra büyük bir şey yapmasam bile geri dönebiliyorum. Her gün değil gerçekten, ama yakın. Bazen günde birkaç kez.

Aldığım şey istediğim zaman geri dönebileceğim. Bu çok fazla. Ayrıca şubelerin siparişini vermek de yardımcı olur.

Sanırım bana çok fazla emir veriyor.

Svn kullanıyorum ve bundan bıktım. Ancak başka şeyleri öğrenmek için daha fazla zaman harcayamazsınız.

İyi şanslar.

Sık sık taahhüt etmelisin. Mantıklı bir dönüm noktasına ulaştıktan sonra kesinlikle taahhütte bulunmalısınız. Bu bir günden uzun sürerse, en azından iş gününün sonunda veya daha iyisi işinizi daha küçük parçalara bölmelisiniz.

Bunu yapmak için birçok neden var. Örneğin, bilgisayarınız çökerse? Sadece bir günlük çalışmayı kaybetmek bir hafta veya bir aydan çok daha iyidir. Diğer bir sebep de, sık taahhütlerin bir böceğin izole edilmesini kolaylaştırmasıdır. İkili arama yapabilir ve hangi küçük değişikliğin hataya neden olduğunu çözebilirsiniz.

Başka bir şey: taahhüt etmeden önce, bir fark yaratmalı ve yaptığınız tüm değişikliklere bakmalısınız. Bu, tüm değişikliklerin anlamlı olduğunu ve hiçbir şey unutmadığınızı kontrol etmenizi sağlar. Bu ayrıca daha iyi bir taahhüt mesajı ile gelmenize yardımcı olur. Ve elbette, bu sık sık iş yapmak için başka bir nedendir: bir günlük bir değişiklikten geçmek bir ayın değerinden daha kolaydır.

CVS'den en iyi şekilde yararlanmak için bir seferde bir özellik / hata düzeltme üzerinde çalışmalı ve bu özellik / hata düzeltme işleminin tamamlandığını taahhüt etmelisiniz. Bunu yaparak kazanacaksınız:

• taahhüt etmek mesajları oluşturmak daha kolay olacak ve daha mantıklı olacak;
• gelecekteki böceklerin daha kolay takip edilmesi onları meydana getiren değişikliklere geri döndü;
• önceki bir duruma daha kolay geri dönme (bu, başarısız bir özelliği kaybetmek, ancak daha sonra oluşan hataları düzeltmek anlamına gelse bile).

Ayrıca, bilgisayarlar arasında geçiş yaptığınızdan, en az iki dalınız olmalıdır:

• Her zaman işe yarayan bir "Gitmeye hazır" şubesi (tabii ki geliştirme branşında çalıştığınız hataları hariç)
• zaman zaman geri alınamayan bir durumda olabilen bir gelişim kolu (işten eve seyahat ederken olduğu gibi);

Her bir satırlık değişiklik bir taahhüt almalı mı?

Eğer bir hatayı düzelttiyseniz, elbette

Kötü VCS alışkanlıklarına sahip olarak neyi özlüyorum?

"Kötü VCS alışkanlıkları" olan bir adamla çalıştım. Tek başına çalışmayı sevdi ve yılda 1.000.000 dolar gibi bir şey getiren bir ürün hattından sorumluydu. Yalnızca patron onu dırttığında taahhüt ederdi. Sonra bir gün sabit diski düştü. Onun için yeni bir yedek ayarladıktan sonra, son girişinin 6 ay önce olduğunu keşfettik. VCS Source Safe olduğundan, başka neyin yanlış gittiğini tahmin edebilirsiniz - son sözler bozuldu. Ürün hattının bozulmamış bir versiyonunu elde etmek için bir yıldan fazla geriye gitmek zorunda kaldık. Olması gerekmesine rağmen kovulmadı.

Başka bir fıkra kendimi içerir. Çıkarılabilir sabit disklerdeki hobi ve araştırma projeleri için kod depolardım. Bir gün dairem kırıldı. Dizüstü bilgisayar (kırılmış olan) ve tüm çıkarılabilir sabit sürücüler çalındı. Her DVD (Red Dawn hariç) çalındı. Masaüstü bilgisayarların hiçbiri çalınmadı. Şirket dışından kaynak kontrolüm olsaydı, özellikle bazıları akademik projelere dayandığı için 15 yıldan fazla projeyi kaybetmezdim - profesörlerin birçoğu özel sektöre gitmek için akademiden ayrıldı, bu yüzden bu projeler kurumsal IP kara deliği haline geldi. kayıp kodu kurtarmak imkansız.

Ne sıklıkla taahhüt etmeliyim?

Bunu birkaç ölçüme bölüyorum:

• Bilgisayarınız ölürse ne kadar iş kaybedersiniz? veya çalındı ​​mı?

• Bu Bug_1234'ü düzeltirse, kodu "Bug_1234 düzeltir" şeklinde kontrol edin.

• Bu mantıksal bir dağıtım / dönüm noktasıysa, "Bug_1234, form_xyz" (veya uygun olduğu şekilde Task_1234) gibi bir yorumla kontrol edin.

• Eve gitmeden önce her zaman Cuma akşamı kodu kontrol edin. Ayrıca tatile çıkmadan önce her şey için bir check-in yapın (veya ödemeleri geri alın).

• Şirket politikası ne zaman zorunlu olursa.

Satır değişikliği sayısı açısından düşünmeyin. İşlevsellik parçalarını düşünün. VCS, her bir işlevsellik öbeği için merkezi bir yerde bir başlık vermenize olanak tanır; böylece "burada ne olduğunu" örneğin git günlüğü ile kolayca görebilirsiniz.

Ayrıca, IDE'nin Eclipse gibi, belirli bir çizgiye işaret etmenizi ve onu gördüğünüz şekle getirme taahhüdüne gitmenizi sağlar. Başka bir deyişle, doğrudan bir kaynak satırından taahhüte geçebilirsiniz. Eğer taahhüt küçükse ve iyi bir mesaja sahipse, "sabit tonluk hata" dan çok daha yararlıdır.

Değişiklikleri birlikte gruplayarak kaçırdığınız en büyük şeyin böceklerin ne zaman ve nerede ortaya çıktığını tespit edebilmek olduğunu söyleyebilirim.

Tecrübelerime göre, bir hatanın tanıtılmasından iki-üç hafta sonra farkedildiği birkaç hafta oldu ve bir hafta boyunca işlem görmeye değer bir zorunluluktan kaçmak zordu. Bu gibi durumlarda, hangi bireysel değişimin soruna yol açtığını tespit etmek için taahhütler arasında basitçe ikili arama yapılması yararlı olmuştur. Bu hatalar çoğunlukla C ++ kodunda bellek kullanım hatalarıydı, bu nedenle projeniz için çok sık gerçekleşmeyebilir.

Bir takımda geliştirilirken başka yararlar da ortaya çıkar - basit yorum yapma, daha kolay birleştirme, hata düzeltmeyle ilgili taahhütler vb.

İş akışınızla günlük veya yarı günlük olarak çalışmaya başlarsanız, canlı sitede hangi kod sürümünün kullanıldığını takip etmek için etiketler veya yer imleri kullanmanız gerekeceğini tahmin ediyorum. Bunun takip edilmesi gereken en önemli şey olduğunu söyleyebilirim.

Ben de bir solo geliştiriciyim, SVN kullanıyorum ve çok seviyorum. Veri tabanımın yapısını ve içindeki test verilerini xml'ye çevirecek bir araç bile yazdım, böylece bunu kaynak kontrolüne dahil edebiliyorum.

Genelde, ne zaman özerk bir çalışma birimini tamamladığımı taahhüt ederim. Bazen, burada bir sürü önemsiz ve ilgisiz tek hat düzeltmesi yaparsam ve o zaman hepsini bir arada işlerim, ancak ilgisiz iki büyük özerk çalışma birimi arasında bir tek hat düzeltmesi olursa, kendi başına bir sonuç alır. taahhüt, bunda yanlış bir şey yok.

Ayrıca, her zaman derleyen kodu ve neredeyse her zaman tüm temel testleri geçen kodu da taahhüt ediyorum. Değilse, işlem iletisine "İŞ YAPMAYIN" yazdığından emin olun. Bu gerçekleştiği tek durum, henüz çalışmamasına rağmen kaybetmek istemediğim önemli değişiklikleri yaptığım zamandır ve bunun üzerine, büyük bir yeniden ateşleme macerasına katılmak isteyip istemediğimden emin değilim. başarılı olacak. Öyleyse, havuzu, şimdiye kadar karıştırıp riske atmadan önce attığım işin bir yedeği olarak kullanıyorum.

Bu, kaynak kodumun taahhüt edilmesi gerektiğinde her zaman taahhütte bulunduğum anlamına gelir; sabah veya akşam taahhüt kurallarına sahip olmak kesinlikle bir anlam ifade etmiyor. Kodun, içinde bulunma zamanının gelip gelmediğini belirlediği durumdur.

Depoya koyduğunuz mesajlar pek önemli değil. Kesinlikle anlamlı bir şey bulamıyorsanız, boş bir mesajla iş yapmak, ne zaman yapmamalısınız yapmaktan daha iyidir.

İyi bir taahhüt mesajı düşünemiyorsanız, geldiğiniz her şey aptalca geliyor, bunun doğru olduğunu unutmayın; taahhüt mesajlarının bariz olduğunu belirtmesi beklenir, bu yüzden yazarken size aptalca ses çıkarması gerekir. Fakat güven bana, eğer eski revizyonları bir ay sonra incelemeye ihtiyaç duyarsan, mesajsız aptal mesajlar için bile minnettar olacaksın.

Her zaman bir "mantıksal" değişiklik yaptığınızı kabul edin. Örneğin, yeni bir özellik uyguluyorsanız, bunu adım adım yapıyorsunuz. Bu adımların her biri genellikle birbirine bağlıdır. Böylece, bu adımları ayrı ayrı uygulayabilir ve her adımın neden gerekli olduğunu taahhüt mesajında ​​açıklayabilirsiniz.

Taahhüt mesajı gerçekten önemlidir. Ne yaptığını söylemekten kaçınmalısın , neden yaptığını anlat . Kod değişiklikleri zaten belgeliyor, ancak 6 ay içinde neden yaptığınızı görmekten mutlu olacaksınız.

Bu aynı zamanda eğer birisi içeri atlarsa ve artık yalnız değilseniz faydalıdır. Sadece sizin için bile, temiz bir tarih git blame, bir böcek olan bu çizginin ne zaman ve neden değiştirildiğini bilmek kullanımını kolaylaştırır .

Büyük çamur değişiklikleri yerine küçük miktarlarda taahhütlerde bulunmak , ara durumu test etmenizi sağlar. Acil bir şey bırakmanız gerekiyorsa değişiklikleri saklayabilirsiniz. Daha önce çalışırken bir hatayı tanıtırsanız, saklamak ve hatayı tanıtan kabul edilmemiş değişiklikleriniz olup olmadığını veya bunun daha eski bir işlem olup olmadığını kontrol edebilirsiniz.

Bunun gücünü açığa çıkarabilirsin, git bissectbu iğrenç böceğin böyle olduğunu taahhüt edersin. Eğer taahhüt 2.000 satır uzunluğundaysa, yine de yardımı olur ama o kadar değil ...

Diğer bir şey de, sürekli entegrasyon (CI) ve ardından sürekli dağıtım (CD) için ilk adım. CI ve testleriniz yeni bir taahhütle tetiklenebilir; bu nedenle, bir şeyi kırarlarsa ya da bozmazsa değişikliklerinizi her bastığınızda size söyleriz. Bu sayede konuşlandırmanın güvenli olup olmadığını anlayabilirsiniz ve bir sorun olduğunda sadece yayınlanmadan önce değil, sorunun ortaya çıktığı anda haberdar olun.

Diğer sorularınız hakkında:

• (derleme) geçmişinizi yeniden yazmak istemediğiniz sürece, derlemediğiniz şeyler yapmayın git rebase --interactive.
• bir satır değişikliği, ayrı bir amacı varsa (bir hatayı düzeltir veya şu andaki tamamlanmamış değişikliklerinizle ilgisi yoksa) bir taahhüdü hak eder. Bunları git add --patchsahneye çıkarmak için kullanın .
• Akşam yemeğinden önce kendinizi zorlamak için kendinizi zorlamaya gerek yok, kaybedeceğiniz önemli şeyleriniz yoksa. Bu durumda, çalışmalarınızı devam eden ayrı bir dalda yapmak isteyebilirsiniz.
• Uzak bir depoya taahhüt ve itmek bir yedeklemedir. Sadece haftada bir kez taahhüt ve itme yaparsanız, en kötü durumda senaryoda bir haftalık işinizi kaybedebilirsiniz.

Ne sıklıkla taahhüt etmeliyim?

Yalnız bir geliştirici olarak, temel testlerden sonra ve gecenin sonunda bir projeden ayrıldığımda, önemli bir değişiklik yaptığımı düşündüğümde genellikle taahhüt ederim.

Her bir satırlık değişiklik bir taahhüt almalı mı?

Hayır, bu tek satırlık değişiklik bir özelliği veya hatayı önemli ölçüde değiştirmeyecekse.

Herhangi bir testten önce taahhütte bulunmalı mıyım (örneğin, en azından sözdizimi / derleme hataları için ve sonra tamamen geri almalıyım; fikir işe yaramadıysa veya mesaj yalandıysa)?

Muhtemelen değil. En azından benim için test ve kodlamanın çoğunu 'çalışan bir kopyaya' yapıyorum ve değişikliklerden memnun kaldıktan sonra taahhüt ediyorum. Birçok IDE’de, bana taahhütte bulunmadan önce neyin değiştiğini gösterecek ve bana taahhütte not ekleme fırsatı vereceğim.

Her sabah / öğleden sonra hala taze iken akşam yemeği için çalışmayı bırakmadan önce iş yaptığımdan emin olmalı mıyım? Kötü VCS alışkanlıklarına sahip olarak neyi özlüyorum?

VCS'ye veya bunun hangi kötü alışkanlıklara neden olduğunu çok iyi bilmiyorum. Sanırım ilk soruya cevap olarak çoğunlukla bu konudaki fikrimi paylaştığımı düşünüyorum.

Öngörülen genel soruya cevaben, çoğunlukla komisyonları başka bir yanıt veren makamında ele alınan şubeler olarak kullanıyor gibi görünüyorsunuz. Kullanmakta olduğunuz hangi IDE'nin iyi bir geri alma geçmişi vb. Olduğundan emin değilim, ancak IDE'nin yeniden başlatılmasının ve makineler arasında hareket etmenin ötesinde iyi olduğunu düşündüğüm birini bulamadım.

Alışılmış bir yorumcuyum ve bana uygun olduğunu öğrendim, ama kuşkusuz benim taahhüt mesajlarım neredeyse her zamanki gibi.

Age:  9 mins [*] Working on implementing and testing PaintSystem.
Age: 17 mins [*] Working on implementing and testing PaintSystem.
Age: 37 mins [*] Working on implementing and testing PaintSystem.
Age: 52 mins [*] Working on implementing and testing PaintSystem.

Bu nedenle, şubeme (mercurial) bu kadar sık ​​ve alışkanlık etmenin kesin olarak en ayrıntılı işlem kayıtlarını teşvik ettiğini söyleyemem. Bazen, eşim benden akşam yemeği için dışarı çıkmamı isterse, acele bir şekilde önceki "Çalışıyor [...]" taahhüt mesajını kopyalayıp kullanacağımı söylerse, kodun yarısını bile yapacağım.

Taahhüt log kalıplarım tipik olarak, "Working on [...] Working on [...] Working [...] Completed [...] Started working on [...] Working on [...] Completed [...] Started working on [...]"

Kapak tarafında olsa da, benim popo kurtardı. Bazen, tahmin edemediğim ve test edemediğim bir davaya giriyorum, bu noktada sık yapılan komisyonlar, hatayı tam olarak nerede ortaya koyduğumu anlamama yardımcı oluyor.

Bu yüzden, en iyi alışkanlıklar hakkında hiçbir şey bilmiyorum ve kesinlikle ideal kayıt işlemleri yapma alışkanlıkları kadar dinleyeceğim bir kişi değilim, ancak daha sık karar vermenin kesinlikle bir gerileme yapmanız gerektiğinde size yardımcı olabileceğini söyleyebilirim.

Her bir satırlık değişiklik bir taahhüt almalı mı?

Daha önce tek satırlık değişiklikler yaptım ama genellikle zor olanları yaptım ve belki de zamanım kısaydı. Taahhütlerim her zaman mükemmel ve eksiksiz iş veya değişim birimlerine benzemez. Dediğim gibi, bazen sadece karımın beklenmedik bir şekilde akşam yemeğine çıkmamı istediğinin bir sonucu.

Bu "Working on [...]"günlük modelini izleyen taahhütlerimin çoğu TBH, tutarlı değişim birimlerini modellemiyor (neden genellikle daha iyi bir mesajla gelemiyorum "Working on [...]") ama kendimi bir fincan kahve yapmak gibi bir nefes almamın sonucu. "Completed [...]"Mesajı çalışmalarının bu birimin sonunu ve ben genellikle ilk birlikte çok daha detaylı mesaj var yazmak "Started working on [...]"Sadece bir şey üzerinde çalışmaya başladığınızda tip mesajlar. Ortalama olarak her 15 dakikada bir kez taahhüt ederseniz, o zaman "Çalışıyor [...]" mesajları bir kişinin daha hantal bir şekilde daha ayrıntılı bir mesajla taahhüt ettiği şeylerin arasındakiler arasındadır.

Herhangi bir testten önce taahhütte bulunmalı mıyım (örneğin, en azından sözdizimi / derleme hataları için ve sonra tamamen geri almalıyım; fikir işe yaramadıysa veya mesaj yalandıysa)?

Sadece devam ettim ve bazen testler yapmadan önce bunu yapıyorum (beklenmedik bir olay olsaydı yine). Ayrıca solo olsam da, CI yapan bir sunucuya (sadece burada bir LAN üzerinde çalışan bir sunucuya) itiyorum. Bu fazla kilolu gibi görünebilir ama bilmiyorum, eski iş yerimde buna eğilmeye çok alıştım. Artı, tüm ünitemi ve entegrasyon testlerini her seferinde elle yapmak zorunda kalmaktan da rahatsız olmak istemiyorum. Bunların hepsinin sadece itmeye bağlı olmasını seviyorum. Eğer bir test başarısız olursa, regresyon yaptığım ileri hareketli bir şekilde çalışmak, hatayı en son revirde düzeltmek ve devam etmem yeterli. Ben en azından yapmak, söz konusu yapı işlemediğim önce bir hata ayıklama derlemesi karşı kodunu.

Her sabah / öğleden sonra hala taze iken akşam yemeği için çalışmayı bırakmadan önce iş yaptığımdan emin olmalı mıyım?

Dışarı çıkmadan ve programlama arasında ara vermeden önce söz vermeyi seviyorum. Tam olarak neden bu soruya cevap verene kadar fazla düşünmedim. Sanırım, ayrılabileceğim ve bırakabileceğim yerlerin yerine, kesin bir kütük olmadan bıraktığım yerden ayrılmamı engelliyorum. Hmm, bu konuda size geri dönmem gerekiyor, çünkü ne kadar sıklıkta işlem yaptığım teorik olarak gerekli olmayabilir. Her ne sebeple olursa olsun bilgisayardan ayrılmadan önce kendimi daha kararlı ve zorlu hissediyorum. Bazıları, eski psikolojik korkunun, örneğin Ben ayrıldıktan sonra ateş yakan ve proje yöneticileriyle birlikte SVN kullandığımız günlerde, bazen haftalarca devam eden, boyunlarımızı solmayacağımızı taahhüt eden ve bu arada sık sık kodu kontrol etmemizi hatırlatırken bize hatırlatırken kodumuz şirketin malıdır. Ayrıca, özellikle itme işleminde biraz daha verimlidir, böylece CI işlemim uzaktayken tüm testleri çalıştırmaya başlayabilir, böylece geri dönüp sonuçları görebilirim.

Oh ve bazen ayrıldıktan sonra biraz sarhoş oluyorum ve genellikle sarhoşken karmaşık kod yazmayı denemek kötü bir fikir (her zaman olmasa da; bir keresinde sarhoşken bir eureka anı yaşadıktan sonra gerçekten güzel bir bağlam menü sistemi ile geldim, ama sadece 6 bira içtim ve kodlaması o kadar da karmaşık değildi). Bunu denerseniz yerine nokta gibi okuyabilir günlüğünü işlemeye Gözat hangi ayık kodla sarhoş kodu, karıştırma doğru geri dönmek gitmeden önce, en azından ben soberly yazılmış kod işlediği, "Reverting back to code written before Jagermeister shots."ben bunu yapma çok sık, sarhoş bir kod ilham almadığım sürece, ancak bu ender durumlarda, dışarı çıkıp sarhoş olmadan önce bir şey yapmamda gerçekten yardımcı oldu.