Neden bir taahhüt mesajı yazmalıyım?

Neden bir taahhüt mesajı yazmalıyım? İstemiyorum ve her seferinde aptal olduğunu düşünüyorum.

Kullandığım bir GUI ön ucu, adlandırılmamış olarak sizi bunu yapmaya zorlar. Diğerlerini her seferinde komut satırında VCS kullanıyor olsalar da işitiyorum.

Günde birkaç kez taahhüt edip bir özelliği bitirmediysem ne hakkında yazıyorum? SADECE birçok işlemden sonra bir mesaj yazıyorum ve mini bir etiketin veya gerçek bir etiketin zamanının geldiğini hissediyorum.

Haklı mıyım yoksa bir şey mi kaçırıyorum? ayrıca dağıtılmış bir sistem kullanıyorum

"Sadece yazmak için yararlı, iyi düşünülmüş bir mesajınız olduğunda ve özelliğiniz% 100 tamamlandığında ve bunun için birim testleriniz olduğunda taahhüt edin" diyen herkese, diyorum ki: Hala SVN zihniyetindesiniz .

Git kullanıyorsanız , akıllı iş akışı dediğim şey budur:

1. Teslim olarak istediğiniz sıklıkta . Buraya eski kısa mesajları yazın. Kimse yine de görmeyecek.
2. 10 taahhütte bulunduktan sonra üzerinde çalıştığınız özelliği bitirdiniz. Şimdi testler yazın ve bu testleri yapın. Ya da başka ne istersen. TDD'yi beğendiyseniz, önce testleri yazın, umrumda değil, git de.
3. git rebase -iİlk 'dağınık' taahhüdünüzden, yakın geçmişinizi güzel mesajlarla mantıksal, temiz taahhütlerde ezerek, düzenleyerek, atlayarak ve başka şekilde temizleyerek yerel geçmişinizi eklediniz ve düzelttiniz .
4. Temizlikten sonra, birisinden sizden çekmesini isteyin.
5. Durulayın ve tekrarlayın.

3. adımın, takip ettiğiniz güzel taahhütlerle sonuçlandığınıza ve ilk iki adımı tamamlayana kadar SVN'yi kullanmaktan kaçınmanız gerektiğine dikkat edin, bu da diğer cevapların çoğunun önerdiği şeydir. IOW, yarı yazılı, test edilmemiş kodunuzu başkalarına vermek istemezsiniz, bu nedenle özelliğiniz bitene kadar bir hafta boyunca taahhütte bulunmazsınız. Sürüm kontrolünü tam potansiyeline kullanmıyorsunuz.

Ayrıca, 1. ve 3. adımlar arasında herhangi bir yerde git push, dizüstü bilgisayarınızın HDD'si ölürse ücretsiz yedeklemeler almak için sunucudaki kendi özel repo aynanızdaki değişikliklerinizi yapabileceğinizi unutmayın.

Çünkü zavallı bir bakıcı bir böcek avlarken ve rev'de eklendiğini fark ettiğinde. xyz, hangi rev'i bilmek isteyecek. xyz yapmalıydı.

Kaynak kodunuzu yorumluyorsunuz değil mi?

En iyi yorumları yazıyorsunuz, kod olarak neden söyleyenler sadece nasıl söylüyor ?

Taahhüt mesajı böyle bir yorumdur ve bu nedenle çok önemlidir ve doğru yapmak için ne kadar düşünürseniz, yazılımın gelecekteki bir bakıcısı için o kadar yararlı olur.

Herhangi bir aktif yazılım parçası için, bu özel yorum aşağıdaki gibi bir şeyle gösterilecektir.

( http://longair.net/blog/2009/04/25/a-few-git-tips/ adresinde bulunur ). Bu, kuşların yazılımda kimin ne zaman çalıştığını ve ne yaptığını görmelerini sağlar.

O Not bu "diyerek yani böyle bir listede gösterilmesini yorumunu taahhüt için nihai hedef olduğuna neyi gelecekteki kendisine ya da iş arkadaşınıza ve BU için" Eğer iyi yazılı özen mesajları işlemek gerekir nedeni budur.

Taahhüt mesajı size aptalca geliyorsa, yanlış kullandığınız anlaşılıyor.

Taahhütler iyi bir nedenle yapılmalıdır - bunlar üzerinde çalıştığınız özellik için ayırdığınız görevlerle ilgili olmalıdır. Bu görevler resmi olsun ya da sadece aklınızda olsun, taahhüt ettiğiniz her değişiklik az çok bir görevi tamamlamalı ve bu nedenle bir şekilde işlevsel olmalıdır.

Sonra taahhüt mesajlarınız çok daha iyi bir amaca hizmet eder. Tamamladığınız görevi ve başka bir yerde izlenmediyse, o görevin neden gerekli olduğunu veya hangi amaca hizmet ettiğini açıklayın:

• Daha iyi kapsülleme için kullanıcı sınıfını yeniden düzenledi
• Arayüzlerin denetleyici sınıfında kullanılabilmesi için API saplamaları oluşturuldu
• Veritabanı sınıfını soyut bir sınıfa dönüştürdü, böylece sahte veritabanları test durumlarında kullanılabilir

Daha sonra siz veya diğer geliştiriciler depoya veya dosya geçmişine göz atabilir ve belirli evrimlerin nerede ve neden olduğunu kolayca görebilirsiniz. Ya da, belirli bir revizyonun bir hatadan suçlu olduğu tespit edilirse, taahhüt mesajı, bu hattın neden yerleştirildiğine dair bir ipucu verecektir, böylece sadece onu sökmek ve olduğu düşünülen bir şeyi yeniden reddetmek zorunda kalmazsınız. sabit ve bunun yerine doğru şekilde düzeltebilirsiniz.

Taahhüt yorumları her şeyi çözmez. Her zaman yardım ettikleri kadar yanıltıcı olma şansları vardır - özellikle geliştiriciler bunlara girmek zorunda kaldıklarında. Bunu deneyin: ormanda bir ekmek kırıntısı izi veya bir dağcılık ara noktası veya iz mermisi gibi düşünün. Doğru yapıldığında, başka türlü kafa karıştırıcı bir yol çizebilirler.

Onlardan çok şey yapma. Dürüst ol:

• "X özelliğini işlemek için uzaysal dizin öğeleri, Daos ve UI'ler düzenlendi"
• "Özellik isteği # 1234 ve hata # 5678 için artımlı check-in"
• "Son derlemeyi kırdım. Bunlar özlediğim dosyalar."

Kısa tutun ve "büyük resim". Mümkünse, özellik / hata sisteminizdeki bir sorun numarasına bakın. Bazı sürüm kontrol arayüzleri bu tür şeyler için bir alan içerir.

WTF / dakika sayısını azaltır;)

ki bu daha mutlu bir ekibe (sizden nefret etmeyen) dönüşür ve potansiyel olarak daha düşük maliyetle daha iyi ekip çıkışı

Ekibinizin geri kalanı WTF'yi proje ağacında değişiklikleri kontrol etmekte olduğunuzu bilir.

çünkü uygun taahhütlü mesajlar girmeyi denemezseniz, kolejim gibi mesajlar giren

no changes

veya

testing

yüzden fazla değiştirilmiş dosya ile taahhüt (şaka yapmıyorum !!).

Böyle bir geliştirici olursanız, sadece bir mesaj girmenin ne kadar aptal olduğunu düşünürseniz düşünün, dünyanın geri kalanının gözünde aptal görüneceksiniz.

Değişiklikler anlamlı değilse neden taahhüt ediyorsunuz?

Sadece anlamı olan değişiklikler yapın. Örneğin, yaklaşık 3 gün sürdü geçen hafta oldukça büyük bir yeniden düzenleme yaptım. Bu süre zarfında tonlarca taahhüt ederdim. Bazıları oldukça küçük değişikliklerdi ('yeni sorumluluğu yansıtacak şekilde X sınıfı Y olarak değiştirildi' veya 'Z yöntemini (Q sınıfına taşıdı') ve diğerleri gerçekten büyüktü. Bir özellik / yeniden düzenleme ile işim bittiğinde bazı taahhütlerin ezilebileceğini kontrol ediyorum (en azından git bunu destekliyor, diğer araçlar hakkında bilmiyorum), ancak genellikle onları daha sonra yardımcı olduğu için olduğu gibi bırakıyorum.

Sanırım bir satırı düzenlemenin ortasında işlemezdin, bu yüzden bir anlamı olmalı. Son işlemden bu yana ne yaptığınızı açıklayın.

biraz değişiklik yaparak sisteminizi kırdığınızda bir durum düşünün ve bunu ekip tarafından yapılan birkaç işlemden sonra gerçekleştirin. Değişikliğin ne olduğunu hatırlamıyorsunuz, ancak X özelliğini geliştirirken veya bir modülü Y modülünden kaldırırken bir şeyin yanlış olabileceğini hatırlıyorsunuz.

Ancak ne yazık ki revizyon numarası X veya Y'yi değiştirdiğinizde size söylemiyor. Yani seçiminiz ya son N gün boyunca işlenmiş tüm kodları okuyor ya da yazdığınız ayrıntılı taahhüt mesajlarını okuyor (koddan çok daha okunabilir).

Dolayısıyla, tamamlama mesajında ​​aynı, sıkıcı, işe yaramaz, alakasız bir metin yazarsanız, yapmanız gereken, taahhüt mesajına sahip olmaktan daha zararlıdır. Çünkü hata kökü bulmak yerine yanlış mesaj sizi yanlış yönlendirir.

Bu yüzden her taahhütte bulunduğunuzda size ve bakımcınıza yardımcı olabilecek anlamlı taahhüt mesajları yazmaya çalışın.

Başkalarıyla çalışıyorsanız, diğerlerinin ne yaptığını görmek için taahhüt mesajları çok önemlidir: her biri için farklara bakmak çok daha fazla iştir ve birinin neden yaptığını anlayamayabilirsiniz. Başkalarıyla birlikte çalışıyorsanız ve (belki siz değil) birisinin gerçekte geriye bakması gerekiyorsa, örneğin, davranışın önceki sürümden bu yana beklenmedik şekillerde nasıl değiştiğini izlemek için ... İleti.

Yalnız çalışıyorsanız ... çoğunlukla 'olduğu gibi' kodlanmış bir projede (örneğin tek bir basit web sitesi veya komut dosyası) nereden geldiğinizi az çok görebiliyorum. Eğer böyle bir şey üzerinde çalışırsam, sadece bir şey üzerinde çalışmaya devam ederken tarih / saat veya en son değişiklikleri önemsiyorum (geri yükleme noktanız var, ancak bunu uyguladıktan sonra değil, geliştirme sırasında sadece önemli). Sürüm kontrolü, sadece birkaç artı ile yedekleme yapmanın bir yoludur - Sistemin tam olarak kullanılmadığına tamamen katılıyorum - ancak bazı küçük ölçekli projelerde gerekli olmayabilir.

Bu, Sürüm Kontrolünün biri projedeki değişiklikleri belgelemek ve diğeri yerinde geliştiricilere yardımcı olmak için iki ayrı şekilde kullanılmadan önce aklıma geldi ... ve bu ikisi birbirinden tamamen farklı. Taahhüt mesajları bir şekilde çok önemlidir ve diğerinde çoğunlukla işe yaramaz olabilir.

Bir şey eksik. Orada gerekir bunu yaparken olmaz bir başka şekilde taahhüt gerçekleştirmek için bir neden.

Yorumda yapmanız gereken tek şey sebebi kelimelere dökmek. wip: adding new state objects

Diğerleri gibi, boş zamanlarımda biraz kodlama yapıyorum ve hem gelişimimi hem de değişiklikleri izlemek için bir revizyon kontrol sistemi kullanıyorum. Boş zamanımın miktarı haftadan haftaya ve aydan aya büyük ölçüde değişiyor. Birçoğu, bir projeye haftalar hatta aylar boyunca kod yazmak için hiç zamanım olmayacak ve tipik olarak 10 dakika (tipik gün) ila 40 dakika (iyi gün) arasında değişecek zamanlar oldu. Bunlar kesinlikle harika koşullar değil - özellikle hata ayıklama sorunları için.

Hem kaybolmayacak hem de kolayca geri alınabilecek notları tutmak şarttı. Her oturumun sonunda, oturumun çalışması ayrıntılı bir mesajla işlenir. Daha sonra taahhüt geçmişinden geçerek ilerlememi ve düşünce sürecimi takip edebilirim. Bu, geçen hafta veya geçen ay nerede olduğumu almamı sağladı.

Göstermeye çalıştığım nokta, iyi taahhüt mesajlarının size (ve sizden sonra gelen herkese) neler olup bittiğini, neler olup bittiğini, nereye gittiğini ve her şeyden önce neden olduğunu anlamanıza yardımcı olmasıdır.

Bir dakikalığına mantıklı düşünün. Taahhüt ettiğinizde bu bir şeylerin yapıldığı anlamına gelir. Mesaj bırakmazsanız diğer insanlar ne yapıldığını nasıl bilecek?

Taahhütlerinize yorum yapmazsanız, kaynaktaki değişikliği yorumlamak isteyebilirsiniz. Zamanla bu, kaynağı karıştırabilir.

Taahhüt iletileri, bu check- in'e neler olduğunu bilmenin hızlı bir yoludur ve kodun hangi revizyonlarda (nedenlerden dolayı) hangi yönün değiştiğini bilmek istediklerinde ekibinizdeki diğer geliştiricilere yardımcı olacaktır.

İlgili bir notta, taahhüt mesajında hata izleyici vaka numarasını belirtmeyi öneririm (umarım birini kullanıyorsunuz), böylece ileride kolayca bir şeyler izlemeniz yararlı olacaktır.

Böylece bu kodun koruyucusu 1 yıl sonra o iğrenç kod için kimin avlanacağını bilir. :)