← Blog · 9 Nisan 2026 · ConvertCaseHQ Ekibi · 6 dk okuma

Temiz Git commit mesajı nasıl yazılır? Tutarlı büyük/küçük harfle

Temiz bir Git commit mesajının kısa bir konu satırı vardır (hedef 50 karakter); bu satır emir kipinde yazılır (İngilizcede “Added” değil “Add”) ve sonunda nokta olmaz. Ardından bir boş satır, sonra değişikliğin neden yapıldığını açıklayan, 72 karakterde sarılmış bir gövde gelir. Büyük harf konusunda tek bir gelenek seçin ve ona bağlı kalın: feat: ya da docs: gibi bir önek varsa ardından gelen sözcük genellikle küçük harfle yazılır; önek yoksa klasik tavsiye, İngilizce mesajlarda ilk sözcüğü büyük yazmaktır.

Bunların hiçbirini Git'in kendisi zorunlu kılmaz; geçmişlerin zamanla dağılmasının nedeni de bu. Aşağıda kuralları, her birinin nereden geldiğini ve araçlarınıza kontrolü nasıl yaptıracağınızı bulacaksınız; böylece hatırlamak zorunda kalmazsınız.

İyi bir commit mesajının anatomisi

fix(editor): keep cursor position after paste

Pasting into an empty textarea moved the cursor to the start, because
the change handler replaced the value before restoring the selection.
Restore the selection after updating the value instead.

Fixes #142

Üç bölüm var: commit'in ne yaptığını söyleyen bir konu satırı, nedenini söyleyen bir gövde ve referanslar ile meta veriler için isteğe bağlı alt bilgiler (footer). Git'in kendi belgeleri, değişikliği özetleyen “a single short (no more than 50 characters) line summarizing the change, followed by a blank line and then a more thorough description” (değişikliği özetleyen tek, kısa, en fazla 50 karakterlik bir satır; ardından bir boş satır ve daha kapsamlı bir açıklama) ile başlamayı öneriyor. İlk boş satıra kadar olan her şey commit'in başlığı sayılır; git log --oneline, git shortlog ve git format-patch de bunu gösterir.

Konu satırı: kısa, emir kipinde, noktasız

Elli karakter esnek bir sınırdır. Git projesinin kendi SubmittingPatches kılavuzu ona tam olarak böyle diyor ve katkıda bulunanlardan “skip the full stop” (sondaki noktayı atlayın) diye istiyor. 50'nin altına inemiyorsanız, bu çoğu zaman commit'in iki iş yaptığının işaretidir.

Aynı kılavuz “describe your changes in imperative mood” (değişikliklerinizi emir kipinde anlatın) diyor; sanki kod tabanına emir veriyormuşsunuz gibi: “make xyzzy do frotz”, “makes xyzzy do frotz” ya da “changed xyzzy to do frotz” değil. Chris Beams'in commit mesajlarına dair yedi kuralından işe yarar bir test: iyi bir konu satırı “If applied, this commit will …” (Uygulanırsa bu commit … yapacak) cümlesini tamamlar.

• “If applied, this commit will add CSV export” cümleyi doğru tamamlar.
• “If applied, this commit will added CSV export” tamamlamaz.
• “If applied, this commit will bug fixes” de tamamlamaz ve okura hiçbir şey söylemez.

Emir kipi, Git'in sizin için yazdığı Merge branch 'main' ve Revert "…" gibi mesajlarla da uyumludur; böylece kendi commit'leriniz günlükte aynı şekilde okunur.

Konu satırında büyük harf: iki kamp

Tavsiyelerin gerçekten çeliştiği yer burası; İngilizce konu satırlarında doğru yanıt, bunların bir önekle başlayıp başlamadığına bağlı.

Git projesinin sürümünde kopyalamaya değer bir ayrıntı var. Önekten sonra yalnızca ilk sözcük büyük harfini kaybeder ve bunun tek nedeni ilk sözcük olmasıdır: her zaman büyük harfle yazılan sözcükler öyle kalır. Projenin kendi örneği refs: HEAD is also treated as a ref; çünkü HEAD her zaman büyük harfle yazılır. Aynı mantık fix: handle iOS paste ve docs: update README badges örneklerini verir.

Bizim görüşümüz: önek varsa, ad ya da kısaltma değilse ilk sözcüğü küçük harfle yazın. Önek yoksa büyük harfle yazın. Tek gerçek hata stilleri karıştırmaktır; çünkü git log --oneline konu satırlarınızı bir listeye çevirir ve birkaç satırda bir büyük/küçük harf değiştiren liste özensiz görünür. Aynı mantığın dokümantasyona uygulanışı için tutarlı dokümantasyon yazmak rehberimize bakın.

Conventional Commits spesifikasyonu aslında ne diyor?

Conventional Commits 1.0.0 spesifikasyonu şu yapıyı tanımlar:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Temel kurallar, kısaca:

• feat (yeni bir özellik) ve fix (bir hata düzeltmesi) spesifikasyonun tanımladığı iki türdür; Semantic Versioning'de MINOR ve PATCH sürümlerine karşılık gelir, geriye dönük uyumsuz değişiklikler ise MAJOR'a denk düşer. Başka türlere izin verilir; spesifikasyon build, chore, ci, docs, style, refactor, perf ve test türlerini anar. Bunlar, Angular'ın geleneğine dayanan commitlint conventional yapılandırmasının önerdiği türlerdir.
• Geriye dönük uyumsuz bir değişiklik, iki noktadan önce ! ile (feat!: drop Node 16 support) ya da BREAKING CHANGE: alt bilgisiyle işaretlenir ve bu alt bilgi büyük harfle yazılmak zorundadır.
• Biçimi okuyan araçlar, BREAKING CHANGE dışında, onu büyük/küçük harfe duyarlı saymamalıdır. Türlerin küçük mü büyük harfle mi yazılacağı konusunda spesifikasyonun SSS bölümü, herhangi bir yazımın kullanılabileceğini söyler, “but it's best to be consistent” (ama tutarlı olmak en iyisi).

Spesifikasyon bir konu satırı uzunluğu belirlemez ve emir kipini şart koşmaz. Bunlar Git geleneğinden gelir.

commitlint'in spesifikasyondan daha katı olduğu yerler

commitlint'in @commitlint/config-conventional yapılandırması biçimi zorunlu kılmanın olağan yoludur ve varsayılanları spesifikasyondan daha ileri gider. Örnek konu satırlarını 21. sürümden geçirdik:

Dikkat edilmesi gereken satır README olanı. Bir kısaltma ya da sınıf adıyla başlayan konu satırı, örneğin fix: README typo veya feat: URLSearchParams support, Git projesi eşdeğerini kabul edecek olsa bile reddedilir. Kısaltma başta olmayacak şekilde yeniden yazın ya da yapılandırmanızdaki subject-case kuralını gevşetin. Varsayılan başlık sınırı 100 karakterdir; yani commitlint sizi 50'ye de bağlamaz.

Gövde: 72'de sarın ve nedenini açıklayın

Git mesajınızı asla yeniden sarmaz. Tim Pope'un 2008'deki açıklaması hâlâ geçerli: git log mesajları dört boşlukla içeri alır; 80 sütunluk bir terminalde simetri için sağda da dört boşluk bırakınca 72 sütun kalır ve sarılmış metin, commit'ler git format-patch ile e-postayla gönderildiğinde de okunaklı kalır. Editörünüz yapmıyorsa Metni N karakterde sar aracımız bir paragrafı sözcük sınırlarından 72 karakterde sarar.

Gövdeyi diff'in gösteremeyeceği şeyler için kullanın: sorunu, neden bu çözümü seçtiğinizi ve denediğiniz ama işe yaramayan her şeyi. Komut satırında her -m kendi paragrafı olur; bu yüzden git commit -m "fix: keep cursor after paste" -m "Pasting into…" bir konu satırı, bir boş satır ve bir gövde üretir.

Kontrolü araçlarınıza bırakın

• VS Code: "git.inputValidation": true ayarını yapın. Commit kutusu, konu satırı 50 karakteri (git.inputValidationSubjectLength) ya da başka bir satır 72 karakteri (git.inputValidationLength) geçtiğinde uyarır.
• Vim: Vim'in commit mesajları için hazır ayarları gövdeyi 72'de sarar (textwidth=72) ve 50 karakterden sonra konu satırını vurgulamayı bırakır.
• Bir commit şablonu: git config commit.template ~/.gitmessage her commit'i editörde kendi hatırlatmalarınızla başlatır.
• Bağımlılıksız kontroller için bir commit-msg hook'u. Bunu .git/hooks/commit-msg olarak kaydedin ve çalıştırılabilir yapın:

#!/bin/sh
# Checks the subject line of every commit message.
subject=$(head -n 1 "$1")
length=${#subject}   # counts bytes in some shells; fine for ASCII subjects

if [ "$length" -gt 72 ]; then
  echo "commit-msg: subject is $length characters (limit 72, aim for 50)" >&2
  exit 1
fi
if [ "$length" -gt 50 ]; then
  echo "commit-msg: note, subject is $length characters (aim for 50)" >&2
fi
case "$subject" in
  *.) echo "commit-msg: drop the full stop at the end of the subject" >&2
      exit 1 ;;
esac
if [ -n "$(sed -n 2p "$1")" ]; then
  echo "commit-msg: leave line 2 blank, between subject and body" >&2
  exit 1
fi

50 karakteri aşınca uyarır; 72'yi aşan konu satırlarını, sondaki noktayı ya da eksik boş satırı reddeder. Gerçekten gerektiğinde git commit --no-verify onu atlar. Commit'ten önce hızlıca saymak için konu satırını karakter sayacımıza yapıştırın.

Kontrol listesi şöyle: emir kipinde, 50 karakter civarında, noktasız bir konu satırı; bütün depo için tek bir büyük harf kuralı; bir boş satır; nedenini açıklayan, 72'de sarılmış bir gövde; ve kurallar yoğun bir haftadan sağ çıksın diye bir hook ya da linter.