İyi Bir Commit/Check-In Mesajı Nasıl Olmalı?

Herkese merhaba,

Versiyon kontrol sistemleri kalabalık ekiplerin, büyük projelerin hatta tek başına yazılım geliştiren yazılımcıların bile olmazsa olmaz bir araç çantası. Versiyonlar arasındaki farkları üstünden ne kadar zaman geçerse geçsin, kodlardaki değişen kısımlara bakmadan bir bakışta anlayabilmenin yolu ise iyi yazılmış commit/check-in mesajlarından geçiyor. Kalabalık ekiplerin çalıştığı büyük projelerde commit veya Visual Studio ile TFS’i entegre olarak kullanan ekipler için  diğer adıyla check-in mesajları oldukça büyük önem arz ediyor. Geliştirme yapacağınız ekranın geçmişine göz atarken yalnızca mesaj içeriğinden bir şeyleri anlamak inanılmaz zaman kazandırıyor ve verimi artırıyor. Bunun dışında standartlara bağlı kalarak ilerlenen her şeyde olduğu gibi daha derli toplu bir proje ilerleyişini de beraberinde getiriyor.

Credit: https://hikaruzone.wordpress.com/2015/10/06/in-case-of-fire-1-git-commit-2-git-push-3-leave-building/

Oldukça ufak ve az sayıdaki bazı kurallara uyarak, çok daha temiz, anlaşılabilir commit/check-in mesajları yazmak mümkün. Sözü fazla uzatmadan, yazılım camiasında kabul görmüş genel geçer kurallara geçelim.

Konu satırı 50 karakter ile özet bir bilgi içermeli

Konu satırı commit/check-in’inizin dergi kapağı görevini gören kısımdır. Okunabilirlik açısından 50 karakter ile sınırlandırmak kabul görmüş bir konu.

Not: Özetleme konusunda sıkıntı yaşıyorsanız muhtemelen tek seferde çok fazla değişiklik yaptığınız anlamını taşıyor. Bu da versiyon kontrolü için bazı problemli durumlar oluşturması oldukça muhtemel. Bu konuya daha sonra değinmek adına, şimdilik bu kısım için şunu söyleyebiliriz “Yaptığınız değişiklikleri kısa bir özet ile açıklayamıyorsanız, muhtemelen commitiniz/check-ininiz gereğinden fazla yük ile yüklenmiş durumda”

Konu satırı büyük harfle başlamalı

Oldukça basit bir kural daha. Yazacağınız mesajın ilk harfi büyük harfle başlamalı.

Konu satırı nokta ile bitmemeli

Türkçe hocalarımız görse eminim içleri kan ağlardı ama üzgünüm, bu konuda fikir birliğine varılmış bir kural olarak karşımıza çıkıyor. Mesajınızın sonuna alışması biraz zor ve tuhaf gelse dahi nokta koymamalısınız.

Yazacağınız mesajda emir ifadeleri veya daha genel bir ifadeyle formal bir dil kullanın

Bu kural için örnekleri incelememiz yeterince açıklayıcı olacaktır.

Git‘in kullandığı örnek birkaç commit mesajını inceleyelim

• Remove contrib/examples/*
• Add sample commands for git-shell
• Merge branch ‘jc/bs-t-is-not-a-tab-for-sed’

Bu şekilde yazmak, eğer böyle yazmıyorsanız ilk başlarda biraz tuhaf gelecektir. Pek çok yazılım geliştirici yaptıklarını geçmiş zaman kipiyle açıklamayı tercih eder. Bu nedenle commit/check-in mesajları genellikle aşağıdakine benzer bir yapıda oluyor

• Xyz bug fixed
• Login form created

Bunun haricinde bazı mesajlar da açıklama yapıyor-muş gibi göründüğü halde aslında üstünden zaman geçtikten sonra neyi düzelttiği/geliştirdiği hakkında en ufak bilgi vermeyen mesajlar olarak görünür

• Some bugs fixed
• Add new class
• Added new object for

Commit mesajlarının yapısı için oldukça basit bir formül var. Düzgün bir şekilde oluşturulmuş bir mesaj aşağıdaki cümlede altı çizili olan yeri tamamlayabilmelidir.

• If applied, this commit will your subject line here

Örneğin;

• If applied, this commit will remove deprecated methods
• If applied, this commit will release version 1.0.0

Bu yapı için geçmiş zaman ifadesi içeren mesajların uymadığını görmek çok kolay. “Eğer uygulanırsa bu commit 1.0.0 versiyonunu yayınlar” gibi yazdığımız commit/check-in mesajlarıyla aslında bir taahhütte bulunuyoruz. Bu yüzden formal bir dil kullanmamız çok daha anlamlı ve kabul görmüş bir kural olarak karşımıza çıkıyor.

İyi bir commit/check-in mesajının nasıl olacağına dair basit birkaç kuralı ele aldığımız bir yazının daha sonuna geldik. Umarım faydalı olmuştur. Herkese keyifli kodlamalar dilerim :)!

KAYNAKLAR

1. https://chris.beams.io/posts/git-commit/#limit-50
2. https://www.freshconsulting.com/atomic-commits/