Peki hangisinin daha iyi ve daha sezgisel olduğunu düşünüyorsunuz?
Fixed the XXX bug in YYY
Fix the XXX bug in YYY
Fixes the XXX bug in YYY
Fixing the XXX bug in YYY
Lütfen gerekçelerinizi belirtin. Not Genel bakış açınızdan soruyorum, yani bunu tercih ettiğiniz svn / cvs araçlarıyla veya programlama dilleriyle ilişkilendirmeye çalışmamalısınız, bunun yerine herhangi bir araç ve programlama diline uygulanması gereken / uygulanabilecek bir şey olarak düşünün.
Yanıtlar:
Bu mesajları diğer geliştiricilere göründükleri gibi düşünüyorum. Henüz değişiklikler uygulanmamış ve örtük bir soru var, "Bu değişiklik setini / yamayı uygulamak ne yapacak?" "YYY'deki XXX hatasını düzeltecek"!
Diğer fiiller için onları bir komut olarak yazmak daha doğal görünür ve önceden belirli bir hedefiniz varsa daha iyi çalışır - iş tamamlanmadan önce ön testlerle birlikte tam anlamıyla commit özetini yazabilirsiniz.
Üzerine çok fazla ağırlık koymuyorum, ama benim için bu, tutarlılığı korurken en az direniş yolu.
Ben şahsen geçmiş zamanla ("sabit") gidiyorum çünkü hatayı işlediğim zaman düzeltildi (ya da taahhütte bulunmayacağım).
Commit mesajlarını şimdiki zamanda görmeyi tercih ederim. Bu şekilde mesaj, farkın ne yaptığını açıklar (çünkü bu farkı veya hatta tüm taahhüdü farklı bir dala çekebilirsiniz). Bu nedenle, commit mesajı ne "yaptığını" tanımlamaz ... Kaydın kendisinin "ne yaptığını" açıklar. Bu yüzden şimdiki zamanda olmalıdır.
Ayrı ayrı bir farka baktığınızı ve uygulayıp uygulamayacağınıza karar vermeye çalıştığınızı hayal edin. Geçmiş zamanda bir başlığa sahip olmasının bir anlamı yok.
IMHO, bağlamı göz önünde bulundurmanıza gerek kalmadan açıklayıcı olmasını istiyorsanız, o zaman "Sabit" kesinlikle tek doğru varyanttır.
Sezgisellikle ilgili olarak - eğer bir değişiklik günlüğüne bakarsam, kelimenin kullanıldığı bağlamı bildiğim için düzeltilmiş hatayı kastettiğinizi kesinlikle anlayacağım, ancak kelime bu kendi içinde yazılırsa beynim onu çok daha çabuk yakalayacaktır. yolu belirterek.
"Düzeltme" en kötü seçimdir, çünkü yalnızca yamanın ne yaptığını (ne için olduğunu) açıklamakla kalmaz, aynı zamanda üzerinde çalışıldığı ve henüz çözülmediği anlamına gelen bir hata durumu olarak da yorumlanabilir.
Fix the XXX bug in YYY
Teach the XXX to be more ZZZ
Correct typos in javadoc
Genel olarak: {zorunlu fiil} {etkilenen nesne} {isteğe bağlı niteleyiciler}
Zorunlu form, bir yama setini düşündüğümde tüm kullanım durumlarına uyar.
Seçiminiz ne olursa olsun, tutarlılığın okunabilirliğe son derece yardımcı olduğunu düşünüyorum. Birini seçin ve ona bağlı kalın.
Şimdiki zamanda şimdiki commit hakkında yazmanın iyi bir fikir olduğunu düşünüyorum, çünkü geçmiş zamanda önceki commitlere atıfta bulunduğunuzda bunu daha net hale getiriyor.
Bunun gerçekten önemli olduğunu sanmıyorum. Amaç şudur:
1) Neyin yapıldığını veya yapıldığını iletin, böylelikle hatalar daha kolay bulunabilir, problemler daha kolay geri döndürülebilir ve genellikle projeyi daha kolay sürdürebilir.
2) Varsa hangi biletlerin sabitlendiğini iletin, böylece denetçiler (şirketinizde kullanılıyorsa, hangi değişikliklerin hangi biletlere karşılık geldiğini görebilir).
Son olarak, eğer 'zaten düzeltildiyse, "Düzeltme" bir anlam ifade etmiyor ve hala üzerinde çalışıyorsanız, "Düzeltildi" doğru değildir.
" Fix bug X ", " Fixed bug X " den 2 karakter daha kısadır .
Ve " Fixing bug X " ten daha kısa 3
Kısa mesaj yazma bakış açısından, şimdiki zaman bazen / genellikle birkaç karakter kaydeder?
Aslında bunun biraz önemli olduğunu düşünüyorum, örneğin Git'in ilk commit-mesaj satırında 50'den az karakter önerisiyle.
Ayrıca, daha az metin -> daha hızlı okumayı mı tamamladı?
Bir commit mesajı, kaydedilmekte olan kodu neden yazdığınızı açıklar.
"Düzeltilmiş sorun 3124" veya "Düzeltme sorunu 3124" doğru görünüyor çünkü bu kodun düzeltildiğini söylüyor | sorunu 3124 düzeltir.
Bununla birlikte, dilbilgisi, hatanın neden düzeltildiğine de bağlı olabilir. Kaydettikten sonra hatayı düzeltildi olarak işaretleyebiliyorsanız, "Düzeltildi" tamamdır, ancak hata, kodunuzu doğruladıktan sonra başka biri tarafından düzeltildi olarak işaretlenecekse, "Düzeltmeler" daha uygun olabilir.
Bence böyle bir sorunun en önemli cevabı şudur: Herkes belirli bir proje için neyin işe yaradığını kullanmalı ve onu en azından birazcık tutarlı tutmalı.
Şimdiki zamanı kullanmanın avantajlarını görsem de (ve aslında bu yazıya tökezledim çünkü açık kaynak projelerde bazı şimdiki zaman mesajları gördüm), muhtemelen projelerim için şimdiki zamanı kullanmayacağım. Linux ve Git ve muhtemelen diğer daha büyük açık kaynaklı projeler için önerilen yol budur, ancak bu projelerin bir parçası olmadığım sürece gerçekten umrumda değil.
Ben bir bağımsız geliştiriciyim ve sürüm notları için bir commit mesajının ilk satırını kullanıyorum, aşağıdaki satırlardaki açıklama bana uygulama detayları hakkında bir fikir veriyor. Şimdiki zaman, geliştirici tabanlı yaklaşıma kıyasla kullanıcı merkezli bir iş akışıdır. Bu şekilde biraz zaman kazanabilirim. Kullanıcılarıma sürüm notlarında talimat vermek son derece doğal olmazdı. Hataları düzeltmek ve özellikler eklemek benim işim. Zamandan tasarruf etmeliyim çünkü ben bir indie'yim. Ekibimde bir “sürüm notu yazarı” yok.
Zaten oluşturulmuşsa bir projenin kurallarını kullanın, ancak pragmatik kalın ve işinizi kolaylaştıracak veya hızlandıracak her şeyi yapın.
Eğer küçük bir commit ise, present Continuous kullanıyorum:
Düzeltme hatası 304
veya
Yorum eklemek
Büyük bir taahhüt ise, daha çok değişiklik günlüğü yaparım: