Semantic Commit Mesajları, commitleri yapılandırmanın en akılcı yoludur, böyle yazıyor cheat sheet’inde. Özellikle büyük projelerde kimin ne yaptığını ve neden yaptığını anlayamadığınız commit mesajları ile uğraşmamak, commitlerin neler içerdiği ve amacının anlaşılması gibi konularda kolaylık sağlaması bakımından, versiyonlamayı kolaylaştırması gibi bir çok avantaja da sahiptir. Ancak en büyük kolaylığı ise işimizi otomatize etmemize imkan vermesi olacaktır.
Alışık olduğumuz düzeni değiştirmek zor, bu gerçeği unutmamak gerekiyor ama semantic commit mesajlarına geçmek çok basit bir değişiklik bu ve çok basit bir formülü var;
feat: add hat wobble
^--^ ^------------^
| |
| +-> Summary in present tense.
|
+-------> Type: chore, docs, feat, fix, refactor, style, or test.Yukarıda ki gösterim en basit kullanımı gösteriyor, şimdi işin biraz daha derinine girelim;
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
Yukarıdaki hem basit hem de gelişmiş kullanımını gördüğünüz semantic commit mesajlarında yer alan type’ları görmüşsünüzdür, bu type’lar nedir, hangi koşullarda hangisi kullanılmalıdır? Bunlara bir bakalım.
Semantic Commit yaparken kullanılması gereken tipler
fix: Bu tipteki bir commit mesajı code içerisinde yer alan bir hatanın düzeltildiğini gösterir
feat: Bu tip ise code içerisine yeni bir özellik eklendiğini belli eder
docs: Dökümantasyon üzerinde değişiklik yapıldığını gösterir
style: Code formatlama işlemi, noktalı virgül düzeltme gibi işlemler için kullanılmalıdır. Ürünün kodu üzerinde bir değişiklik olmamalıdır.
refactor: Code üzerinde refactor yapıldığında kullanılmalıdır. Örn; bir değişkenin yeniden isimlendirilmesi
test: Eksik test ya da testler yeniden düzenlendiğinde kullanılmalıdır. Ürünün kodu üzerinde bir değişiklik olmamalıdır.
chore: Grunt taskların güncellenmesinde kullanılmalıdır. Ürünün kodu üzerinde bir değişiklik olmamalıdır.
BREAKING CHANGE: Bir commit’in footer mesajı içerisinde ‘BREAKING CHANGE: description’ şeklinde ya da diğer tiplerin sonuna ‘!’ işareti kullanılarak gösterilmelidir. Major değişiklik diyebileceğimiz değişiklikler için kullanılmalıdır.
Peki ya revert’ler ne olacak? Semantic commit yaklaşımı revert işlemini tanımlamak için bir çaba sarfetmese de bir kullanım göstermiştir. Tıpkı yukarıda yer alan tiplerin kullanıldığı gibi ‘revert: aciklama’ şeklinde bir kullanılmalıdır, ancak geri alınan commitlerin id’lerini (SHA değerleri) commit body mesajının içinde gönderilmelidir. Örnek bir kullanım olarak;
revert: let us never again speak of the noodle incident
Refs: 676104e, a215868Yukarıda bir de gördüğünüz gibi scope var parantez içerisinde yazılan, bu ne işe yarayacak? Aslında burada da işlem yaptığınız modülün ismini ya da Jira Ticket Number’ı parantez içerisinde kullanabilirsiniz. Örnek bir kullanım olarak;
feat(lang): add Turkish languagerefactor(FOW-1461): refactor authentication class
add new class name `userRepo` and extract out api call to `/api/v1/users/me` from authentication to separate class and use the new class to contain all of external api call related to the user dataUmarım yararlı olmuştur.
Kaynaklar
https://kapeli.com/cheat_sheets/Semantic_Commits.docset/Contents/Resources/Documents/index https://medium.com/@c1982/cto-olarak-%C3%BC%C3%A7-y%C4%B1lda-%C3%B6%C4%9Frendiklerim-18012275289c https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716 https://www.conventionalcommits.org/en/v1.0.0/