Conventional Commits kullanmayı bırakın

(sumnerevans.com)

4 puan yazan GN⁺ 2026-06-06 | 2 yorum | WhatsApp'ta paylaş

Conventional Commits, <type>[optional scope]: <description> biçimiyle commit mesajına anlam kazandırmaya çalışsa da, değişiklik türünü öne çıkarıp kapsamı isteğe bağlı bırakarak gerçek inceleme için gereken bilgiyi sona iter
Katkıda bulunanlar, hata ayıklayanlar ve olay müdahale ekipleri commit geçmişinde değişikliğin dokunduğu kod alanını arar; hatalar her tür değişiklikte ortaya çıkabileceği için scope (kapsam), türden daha önemlidir
fix(compiler): prevent namespaced SVG <style> elements from being stripped örneğinde olduğu gibi, yalnızca açıklamadan bunun bir hata düzeltmesi olduğu anlaşılabilir; refactor(core): Update webmcp support to use document.modelContext örneğinde ise tek bir commit düzeltme, refactor ve özellik ekleme arasında kalabilir; bu yüzden type hem tekrarlayıcıdır hem de sınırlayıcıdır
Otomatik CHANGELOG üretimi ve semantik sürüm artırımı kararı, commit geçmişi ile değişiklik günlüğünün farklı okur kitlelerine hitap etmesi nedeniyle sorunludur; revert işlemleri, kazara geriye dönük uyumluluk kırılması ve bu kırılmanın sonradan giderilmesi yüzünden sonuçlar sapabilir
Kapsam önekli commit mesajları değişikliğin öznesini önce gösterir; build ve deploy koşullarını da başlıktaki türe göre değil, git diff ile değişen dosyalara göre belirlemek daha iyidir

Yanlış öncelikler

Conventional Commits, geliştiricilerin ve son kullanıcıların değişiklikleri anlayabilmesi için commit mesajlarına anlam kazandırmayı amaçlar

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Başlık satırı fix, feat, chore, docs, refactor gibi bir <type>, isteğe bağlı bir scope ve bir description'dan oluşur
Temel kusur, değişikliğin öznesi olan scope'u değil, değişiklik türü olan type'ı önceleyen yapıdır
Scope'un isteğe bağlı olması, commit'teki en önemli bilginin eksik kalabilmesine yol açar; type'ın başlığın en başına konması da önceliği tersine çevirir

Scope neden type'dan daha önemlidir

Katkıda bulunanlar, son katkılarından bu yana nelerin değiştiğini, projenin genel akışını ve pull ya da rebase sırasında devam eden işleriyle çakışabilecek commit'leri bulmak için commit geçmişini okur
Hata ayıklayanlar, hatanın ortaya çıktığı bileşenle ilgili alanlara dokunan değişiklikleri arar; hatalar her tür değişiklikte çıkabildiği için type bilgisi yardımcı olmaz
Olay müdahale ekipleri, bir kesinti sırasında commit geçmişini tarayarak soruna yol açan alanı bulmaya çalışır; gelen API hatalarının birden arttığı noktada auth scope'lu bir commit varsa bu güçlü bir neden adayıdır
Commit geçmişini okuyanlar için önemli olan, değişikliğin ne tür olduğu değil hangi alana dokunduğudur

Type'ın tekrarlılığı ve sınırlılığı

fix(compiler): prevent namespaced SVG <style> elements from being stripped örneğinde, bunun bir hata düzeltmesi olduğu yalnızca description'dan anlaşılabildiği için fix type'ı tekrarlıdır
Commit başlık satırındaki alan sınırlıdır; description'dan zaten anlaşılabilen bir type için karakter harcamak faydalı değildir
refactor(core): Update webmcp support to use document.modelContext, core bileşenindeki webmcp özelliğini hem document.modelContext hem de navigator.modelContext destekleyecek şekilde günceller
Bu değişiklik aynı anda bir hata düzeltmesi, bir refactor ve yeni bir özellik olarak görülebilir; ama asıl önemli bilgi bunun core/webmcp bileşenine yönelik bir değişiklik olmasıdır

Otomasyon vaadinin sınırları

git-cliff veya conventional-changelog gibi araçlarla commit'lerden otomatik CHANGELOG üretme fikrinin temel sorunu, commit geçmişi ile değişiklik günlüğünün farklı okurlara hitap etmesidir
CHANGELOG son kullanıcıya yöneliktir ve sürümler arasındaki işlevsel ve iş açısından farkları anlamaya odaklanır
Commit geçmişi geliştiricilere yöneliktir; kod tabanının zaman içinde nasıl değiştiğini ve scope perspektifinden akışı okumaya odaklanır
Orta ve üzeri karmaşıklıktaki projelerde anlamlı tek bir özellik birden fazla commit ile gelebilir; geliştirici için uygulama süreci faydalıdır ama son kullanıcı için önemli olan yalnızca ortaya çıkan yeni özelliktir
Revert commit'leri geliştiriciler için commit geçmişinin akışı açısından önemlidir; ama son kullanıcı için geri alınmış bir değişiklik, hiç yapılmamış bir değişiklikle aynıdır
Commit type'ına dayalı semantik sürüm artırımı; geriye dönük uyumluluğu bozan bir değişiklik geri alınmış olsa bile major sürüm yükseltmek, kırılmanın ancak sonradan fark edilmesi nedeniyle minor/patch yanlış artırımı yapmak ya da sonraki commit'lerle birleşince kırılma ortadan kalksa bile hâlâ kırılma var sanmak gibi sorunlar doğurabilir
Bu durumlarda rebase ile geçmiş düzeltilebilir; ancak workflow buna izin vermeyebilir veya bunu bozabilir ve commit geçmişinin anlattığı akışa olan güveni azaltır
Build veya deploy süreçlerini commit başlığındaki type ile tetiklemek, docs: fix typos başlıklı bir commit'in kimlik doğrulama alt sistemine bir zafiyet sokması gibi yollarla otomatik araçların atlatılmasına neden olabilir
Build ve deploy koşullarını commit başlığından değil, git diff ile değişen dosyaları belirleyerek tanımlamak daha iyidir

Uygulama sorunları ve alternatif

Conventional Commits, proje bazında bir type kümesi tanımlamayı önerir; ancak birçok proje commitlint'in varsayılan type'larını olduğu gibi alır ve bu her projenin özelliklerine iyi uymayabilir
Conventional Commits spesifikasyonu teknik olarak yalnızca fix ve feat tanımlar; ek type'ları projeye bırakır
Kurumsal ortamlarda değişiklik yönetimi ve denetim gereklilikleri nedeniyle her commit mesajına bir bilet numarası eklenmesi gerekebilir; <scope> alanı bilet numarası için kullanılırsa yararlı metadata kaybolur
Linux, FreeBSD, Git, Go, NixOS ve Node.js projeye uygun scope önekli commit mesajları kullanır

Proje	Biçim	Örnek
Linux	`subsystem: description`	`i2c: virtio: mark device ready before registering the adapter`
FreeBSD	`prefix: Description`	`linuxulator: Return EINVAL for invalid inotify flags`
Git	`area: description`	`gitlab-ci: update macOS image`
Go	`package: description`	`net/http/cookiejar: add godoc links`
nixpkgs	`pkg-name: description`	`xwayland: 24.1.11 -> 24.1.12`
Node.js	`subsystem: description`	`stream: fast-path stateless transform flush results`

Linux çekirdeğinde subsystem, Go projelerinde package path, mikroservis mimarisinde ise mikroservis adı doğal bir scope olur
scopedcommits.com, commit mesajlarında scope merkezli biçime geri dönmeyi ve CHANGELOG üretimi ile commit geçmişi yönetimini birbirinden ayırmayı savunur
Conventional Commits'in avantajları pratikte gerçek faydaya dönüşmedi; açık kaynak projelerdeki popülerliği ve yapay zekanın bunu varsayılan tercih olarak seçme eğilimi, anti-pattern içeren commit mesajlarının yayılmasına yol açtı

2 yorum

GN⁺ 29 일 전

Hacker News görüşleri

Programcılar sanki her zaman tab mı space mi gibi önemsiz şeylere kadar en iyi ayarın ne olduğu konusunda didişip şikâyet edecek bir şey buluyor
Conventional Commits’in commit mesajlarını düzenlemenin ilahi vahiy gibi en iyi yolu olduğunu söylemiyorum ama belirlenmiş bir yapı olmasının ve commit mesajlarından ne bekleneceğini hizalamanın çok daha etkili ve önemli olduğunu düşünüyorum
Yazar kapsamın türden daha önemli olduğunu güçlü biçimde vurguluyor ama fix(compiler) ile compiler fix arasındaki farkın uğruna ölünecek bir mesele olduğunu sanmıyorum
Teknoloji sektöründe en iyi olmasa da standart haline gelmiş pek çok şey var; örneğin JSON bugün sıfırdan tasarlansa birçok kişi yorumları, daha açık sayı biçimlerini vb. desteklemesi gerektiğini söylerdi
Yine de kendisinden öncekilerden çeşitli bağlamlarda daha iyi olduğu için standart oldu ve Conventional Commits’ten biraz farklı, daha iyi bir biçim olabilir ama commit mesajı yapısı için bir rakip yaklaşım daha çıkaracak kadar iyi görünmüyor
- Tanımlı bir yapı tek başına kalite demek değildir
  Commit mesajları gevşek bir yapıda olsa bile değişikliğin niteliğini iyi aktarıyorsa harika olabilir; tersine çok yapısal olup yine de kafa karıştırıcı ya da bilgisiz olabilir
  Genel olarak yazara katılıyorum; Conventional Commits kötü commit mesajları gibi temel sorunu çözmüyor
- Standardizasyona katılıyorum ama bu mantıkla her türlü ikinci sınıf statükoyu da sonsuza kadar meşrulaştırabilirsiniz
  XML yeterince iyi ve bir standart, SOAP da yeterince iyi ve bir standart
  Denen şey, Conventional Commits’in yeterince iyi ve yeterince standartlaştığı, bu yüzden başka yapılara bakmaya değmeyeceği; ama bu “değer” öznel
  Her gün commit atıyor ve PR okuyorsanız Conventional Commits biçiminin yarattığı küçük sürtünmeler birikebilir; bunu doğa yasası gibi görmeyip seçenek bırakmak, tercih eden ekipler için faydalıdır
  Zaten ekiplerin çoğu changelog da üretmiyor
- Bu tartışmada özel bir çıkarım yok ama asıl yazıya verilen karşı argüman boş geliyor
  Kapsamın önemli olduğu doğru ama bunun commit içeriğinden çıkarılamayacağını sanmıyorum
  Diff incelerken dokunulan yolları görmek önemli bir sanity check’tir ve bir “test” diff’inin production kimlik doğrulama kodunu değiştirmemesi gerekir
  Yine de bunu --oneline içinde görmek istiyorsanız feat(auth): bana feat:’ten daha iyi geliyor
  Hedef okurun haksız olduğu iddiasına katılmıyorum
  feat commit’i gerçekten ürün açısından değişikliği açıklamalı ve anlamsız refactor değişikliklerini önce düzgünce yığıp ardından üstüne küçük yeni özellik değişikliğini koyacak şekilde düzenlenmeli
  Diff açıklamasına koymak için en faydalı bilgi de bu; “neden X algoritması seçildi” gibi teknik bağlam ise kaybolmaması için yorumlara ya da DECISIONS.md içine yazılmalı
  Hızlı hareket eden şirketlerde commit geçmişinde böyle sıkıcı işlerle ilgilenenler ancak takıntılı insanlar olabilir ama açık kaynak projelerde bağlamı commit mesajlarında saklamak çok daha önemli bence
- Asıl nokta kapsamın türden daha önemli olması değil; doğal dilin, önemli gördüğünüz şeyi vurgulayacak şekilde ifade edebilmesi, ama her şeyi belirli bir kalıba sıkıştırdığınızda bu bilginin kaybolmasıdır
  Sadece JSON değil de Markdown ve düz metin gibi biçimlerin var olmasının bir nedeni var
- Conventional Commits’i iyi bir fikir yapan şeyin, araçlar sayesinde insanları commit mesajlarına en azından çok az da olsa düşünce katmaya zorlayabilmesi olduğunu düşünüyorum
  Başlığı small fix olup gerçekte hiç de küçük olmayan çok fazla commit inceledim
Asıl sonuç, her projenin gereksinimlerinin farklı olduğudur
30 yılı aşkın süredir kaynak yönetimi kullanıyorum; açıklamaya bileşeni (yazıda scope deniyor) standart bir biçimde eklemenin faydalı olduğu bir durumla bir kez bile karşılaşmadım
Etkilenen dosyaların kaynak ağacında nerede olduğuna bakmak bile hangi bileşenin değiştiğini açıkça gösterir; bug, fix, feature gibi etiketler de anlamlı bir değer katmaz
Önemli olmasaydı zaten check-in yapılmazdı
Bana gerçekten faydalı gelen tek şey, yazıda hiç ele alınmayan ilgili değişiklik talebi bağlantısı veya kimliği
Commit zaten neyin değiştiğine dair bilgiyi içeriyor; eksik olan şey neden değiştiğine dair bağlam
Kişisel projelerde bile açıklamanın başındaki köşeli parantez içine JIRA referansı koyuyorum; geliştirme sırasında tesadüfen düzeltmeye karar verdiğim bir şey olsa bile kısa, tek satırlık bir JIRA açıp bir kimlik alıyor ve gerekçeyi oraya yazıyorum
- “Neden”, tam da git commit mesajında yer alması gereken şeydir
  O mesajın bütün amacı “neden”i yakalamaktır; bir gün ortadan kalkabilecek harici bir kaynağa tek bir bağlantı eklemek bunun iyi bir alternatifi değildir
- JIRA kullandığımız dönemde biz de bunu yapıyorduk
  GitHub issue kullanılıyorsa, commit’ten PR tartışmasına geri dönebilirsiniz; o PR’da da bağlantılı issue ve başka işaretçiler bulunmalıdır
  Elbette GitHub issue’ya geçince JIRA’yı neredeyse tamamen bıraktık ve birkaç yıl sonra instance kapatılıp silindi
  Artık o JIRA etiketlerinin hepsi işe yaramaz durumda
  Bu yüzden aslında issue takip sistemi ile git deposu arasında güçlü bir bağ gerektiğini düşünüyorum
  Asıl istenen şey taşınabilirlik ama güçlü bağ olmadan bunun nasıl elde edileceğini bilmiyorum
  İdeal olarak açık bir standart biçim olmalıydı; fakat pratikte biçimi tanımlayan dev goril GitHub ve GitLab gibi klonlar GitHub proje metadatasını ya da en azından PR’ları içe aktarabiliyorsa fiilen buna yaklaşılmış olur
  Her hâlükârda, 5 yıl sonra belki de kullanılmayacak bir Atlassian ürününe değişmez işaretçiler bırakmayı zorunlu kılan bir politika iyi değil
  Bunun yerine, git commit’inin tamamen kendi başına ayakta durması ve değişikliğin “neden”ine dair tüm bilginin commit mesajına ya da kaynak kod yorumlarına yedirilmesi politikasını kabul etmeyi tercih ederim
  Yine de bunun da başarısız olduğunu düşünüyorum; insanlar git commit’lerinde fazla kısa yazıyor, issue’ları özetlerken bilgi kaybediyor ve PR tartışmalarındaki gidip gelmeli konuşmalar tek bir kişinin ağzından yapılmış neden özetinden daha fazlasını içerdiği için faydalı oluyor
- Sürüm notlarını otomatik oluşturmak için faydalıdır
  Yeni özellikleri önce gruplayıp hata düzeltmelerini sonra koymak, teknik olmayan kullanıcılar için biraz daha okunabilir olur
- Evet
  Commit mesajları changelog üretmek için değil, gelecekteki geliştiriciler içindir
  O geliştiricinin commit mesajını okuduğu temel an, o commit’in neden var olduğunu anlayamadığı andır
  Merak ettiği şey neyin değiştiği değil, belirli bir satırın amacının ne olduğudur
  Bu yüzden blame çalıştırıp commit’e bakar; orijinal geliştirici çoktan şirketten ayrılmış olabilir, eski JIRA da ortadan kalkmış olabilir ve elde kalan tek ipucu commit mesajıdır
  https://dev.to/splix/the-why-behind-the-code-2bb1
- Ayrı bir kaynak kullanmanın avantajı, resim gibi şeyler ekleyebilmek mi, yoksa benim kaçırdığım başka bir şey mi var diye düşünüyorum
  Bağlamı commit gövdesine yazmak yetmez mi?
Conventional Commits kullanan birçok kişinin chore kelimesi hep gözüme batmıştır
Şahsen burada da neyse ki anılmış olan Linux kernel tarzı commit başlıklarını tercih ediyorum
[0] https://www.kernel.org/doc/html/v7.0/process/submitting-patc...
- Kesinlikle katılıyorum
  chore kelimesinin ima ettiği tutum bana çok itici geliyor
  Sanki geri kalan her şey fun ya da indifferent diye etiketlenmeliymiş gibi hissettiriyor; böyle duygusal yargılar commit mesajına ait değil
- Bir alternatif buldum: upkeep
  Anlamı aynı ama küçümseyici bir tonu yok
- Rich’in şu yazısı da hoşunuza gidebilir: https://richvdh.org/conventional-commits-considered-harmful....
- Terminolojinin kötü olduğu doğru
  Ayrıca commit’in toplam etkisini önceden biliyormuşsun gibi davranıyor; oysa bilmiyorsun
  Conventional Commits ortaya çıkınca hem ekip arkadaşları hem de LLM’ler bu aptal adlandırmayı üretmek için zaman ve token harcamak zorunda kalıyor
Conventional Commits hakkındaki temel şikâyetim, commit başlığında issue numarasının yer almamasıydı
Standart belgede bundan isteğe bağlı bir unsur olarak bile söz edilmiyor
Benim için commit mesajındaki neredeyse en önemli bilgi bu
Son 15 yılda, eski bir commit’in referans verdiği issue açıklamasını karşılaştırarak değişikliğin tüm bağlamını çıkardığım kaç kez oldu sayamam
Bunun bir tür standart alışkanlık olduğunu sanıyordum; Conventional Commits’i öğrenince öyle olmadığını fark ettim
Neden bu kadar popüler olduğunu hiç anlayamadım
- Ben şahsen issue bilgisini git trailer olarak eklemeyi tercih ediyorum
  fix thing in foo
  
  Issue: ABC-123

Git’te bu tür trailer’ları ayrıştırmak ve biçimlendirmek için birçok yerleşik özellik var; bu yüzden satır içinde görüntülemek ya da CI’da kullanmak üzere ayrıştıran özel git log takma adları oluşturmak kolay.

Zaten karakter sayısı kısıtlı bir değişiklik günlüğünü tarıyorsam, ana commit mesajında XYZ-999999 olmasına pek önem vermem.
Trailer olarak etiketlemek iyi, ama Jira issue numarasından çok commit’in ne yaptığını görmeyi tercih ederim.
Bunu ancak issue anahtarının başlığın en başında zorunlu tutulduğu durumda sorun olarak görürüm.
Bunun da okunabilirlik açısından kötü olduğunu düşünüyorum.
Conventional Commits’in türlü türlü biçiminden sonra bir yere iliştirilince neden olmasın, anlamıyorum.
Issue anahtarı, alfasayısal bir önekten sonra gelen sayı gibi bir regex ile çıkarılabilmeli; dolayısıyla böyle bir “standart”ın ayrı bir alan açmasına neredeyse gerek yok.
Ben şahsen Conventional Commits kullanmadan, ilgili issue ile bağlantılı bir commit ise sonuna parantez içinde ekliyorum.
İlişki daha güçlüyse, mesela issue’yu düzeltiyorsa, mesaja ayrıca Fixes trailer’ını da koyuyorum.
İlginç.
Biz şimdiye kadar fix(ABC-123): some message here gibi yazıyorduk; hem linkleme düzgün çalışıyor hem de otomatik sürüm notlarında çok iyi render ediliyor.
Bu bir standart değil, gelenek.
Ekip içinde bilet ID’sinin commit mesajına dahil edilmesi için bir standart belirlemek yeterli.
Makine tarafından okunabilir olmasını istiyorsanız footer/trailer kullanabilirsiniz.
Conventional Commits hakkında iyi söyleyebileceğim hiçbir şey yok.
Biçim, mesajın en çok okunan kısmında yer kaplıyor ve kategori ya da tiplerin bilgi değeri düşük.
Başlığa dürüst bir İngilizce fiili cümle gibi koymak bunun yerini alabilir; :, (), ! gibi üç tür noktalama işaretindense düz bir cümle çok daha iyi okunur.
Başlıktaki “alan”a bir yere kadar katlanabilirim; üstelik bu da bu gelenekten daha eski.
İş yerinde teknik olmayan kullanıcılar için bir web uygulaması yapıyoruz ve bu kullanıcılar için değişiklik günlüğü Norveççe gayet iyi yazılabiliyor.
Commit mesajları kullanıcıları ilgilendirmiyor ve her commit’in son kullanıcıya dönük değişiklik günlüğüne girecek kadar iyi olması gerektiği gibi bir beklenti bizde yakın zamanda olacak bir şey değil.
Onun yerine footer/trailer kullanabilirsiniz.
Conventional Commits’in gerçekten yardımcı olduğu yer sürekli dağıtım.
main’e her merge yapıldığında otomatik olarak SemVer etiketi basıp dağıtım yapabilirsiniz; çünkü etiketleme ve sürüm yönetimi için gereken kararlar, geliştirici commit mesajını yazarken zaten verilmiş olur.
Linux kernel gibi devasa projelere uymadığını tamamen kabul ediyorum.
Ama projelerin %99’unda Conventional Commits ile SemVer’i birleştirmek, mevcut sürüm sürecine göre büyük bir iyileştirme sağlar ve otomasyonu kolaylaştırır.
- Sürekli dağıtım bağlamında bile git tags’e dayanan yaklaşımı seviyorum.
  git describe çoğu zaman sürekli dağıtım sürümlemesi için yeterli oluyor ve v1.2.3-4-gabcdef, commit’i git’in tatmin olacağı kadar doğru tarif ederken SemVer’e de benzer bir beklenti oluşturuyor.
  Özellikle yeni git tags sadece bir insanın kararıyla ekleniyorsa, örneğin bunun kırıcı bir değişiklik olduğu ve şimdi yeni bir major etiketlenmesi gerektiği gibi durumlarda.
  git describe biçimindeki sürüm numaralarında asıl tartışma, SemVer beklentilerine daha iyi uyması için ilk tireyi artıya çevirip çevirmemek düzeyinde; paket yöneticisinde sürümlerin doğru sıralanması gibi SemVer beklentilerini zorlamanın bir değeri varsa, bu basit bir regex ile dönüştürülebilir.
  git describe, CD otomasyonunu kolaylaştırır; ama commit geçmişindeki sihirli anahtar kelimelerden tahmin yürütmek yerine sürüm numarasına karar verme işini git tag seçimi ya da GitHub Releases üzerinden insana bırakabilirsiniz.
- Açık kaynak projelerimde SemVer artışlarını otomatikleştirmek için bu yöntemi kullanıyorum ve gerçekten çok iyi.
  İş yerinde ise değişimle ilgilenen hedef kitleye göre “etiketler”i de zorunlu tutuyoruz.
  Buradaki etiket git etiketi değil, PR başlığındaki bir string; bu “etiket”e göre de her ekip için değişiklik günlükleri üretiyoruz.
- Yazı bunun neden düzgün çalışmadığını açıklıyor.
- Ama neden bunu başlığa koymak zorundasınız?
  Eğer sürümü böyle tuhaf bir şekilde vermek istiyorsanız, commit gövdesine sihirli bir ifade koyabilirsiniz.
  Böylece tek bir kelimeyle de sınırlı kalmazsınız.
Bu başlık tarzından epey nefret ediyorum.
“Stop something” gibi ifadeler çok popüler görünüyor ama buyurgan ve “kesinlikle ben haklıyım” havası veriyor.
Neden “In favour of something” ya da “A case against something” gibi bir şey kullanılmıyor, anlamıyorum.
- Neden tercih edilen görüşü doğrudan ve açıkça savunmamak gerektiğini anlamıyorum.
  O görüşe katılmak zorunda değilsiniz ama ifadenin yumuşatılmasını istemek zayıf bir tepki.
- considered harmful kadar kötü değil ama yine de biraz toksik.
  Esas mesele, A ile B’nin sırasını değiştirmek istemek gibi keyfi bir kişisel tercihi, olduğundan daha büyük bir mesele gibi göstermeye çalışıyor olması gibi duruyor.
- Bir ifade dünya görüşümüze meydan okuduğunda daha çok ilgi çekiyor.
  Birçok kişiye kaba gelse de dikkat ekonomisi bu tür şeyleri ödüllendiriyor.
  Düzenleme: Görünüşe göre başlığı daha az kışkırtıcı olacak şekilde değiştirmişler.
  İyi yapmışlar.
- Ben de benzer bir şey söylemek için gelmiştim.
  Conventional Commits’i pek sevmiyorum ama insanların istediklerini kullanmasına izin vermek lazım.
- https://knowyourmeme.com/memes/stop-doing-math
  Bu tür başlıkların bir kısmını etkilemiş bir meme var.
Garip
Bu tarz commit mesajlarını kullanmanın başlıca nedeni CI/CD otomasyonudur
Düzeltme: İlk okuyuşumda yazıda bu kısmı görmemişim, ele alınmış
Kusura bakmayın
Commit türleri, otomatik iş akışlarına bir commit’in nasıl işleneceğini söylediği için en başta yer alır
Örneğin CD yapıyorsanız, yalnızca birkaç fix: commit’i olduğunda semantik sürümlemede sadece yama numarası artar
feat: commit’i yaparsanız minör sürüm yükselir, feat! ise majör sürüm artışı demektir
Sürümler için CD kullanmıyor olsanız bile, semantik commit mesajları bazen değişiklik günlüğü üretimini otomatikleştirmek için de kullanılır
Elbette değişiklik günlüğüne genelde Git commit mesajlarının kendisini koymamalısınız
O mesajlar kullanıcılar için değil, geliştiriciler içindir
- Yazı bu iki konuyu da oldukça açık ele alıyor
  semantik sürümleme geri alma işlemlerinde bozuluyor ve otomatik değişiklik günlüğünde hedef kitle yanlış
- Bu stili sürüm artışı için kullandım ve iyi sonuç aldım; bu yüzden yazının çalışan bir alternatif önermesini isterdim
  Bugünlerde SemVer yerine CalVer kullandığım için benim için sorun olmuyor ama akıllı otomatik sürüm artışı fikri hoşuma gidiyor
- O hâlde git trailer’larında hangi kuralı kullanmak gerekir
  Commit başlığında fix ya da feat olması, log’u tarayan birine faydalı bilgi vermiyor
- Hayır hayır
  Mesele, yapay zekanın commit üretmesini kolaylaştırmak için Conventional Commits’i kaldırmamız gerektiği ya
Sıralamayı tersine çevirirseniz asıl can sıkıntım gerçekten çözülmüş olur
Sonuçta özellik tam olarak nedir?
refactor(core): Update webmcp support to use document.modelContext

Yazarın dediği gibi düzeltme, iyileştirme ve genel temizlik arasındaki sınırlar bulanıktır; ayrıca her anlamlı değişikliği ayrı commit’lere bölmek, zaten sonradan squash edilebileceği için kimseye fayda sağlamayan ek iş çıkarır
Conventional Commits’in, başka sorunları doğrudan çözmekten çok SemVer otomasyonu denemesinin bir yan ürünü olduğunu düşünüyorum
Değişiklik günlüklerinin zaten otomatikleştirilmemesi gerektiğini düşünüyorum
Bir liste gerekiyorsa git loga bakılır
Değişiklik günlüğü, daha geniş bir kitleye içeride gerçekte neler olduğunu aktarmak için bir fırsattır
“Değişiklik günlüğünün okuru ile commit günlüğünün okuru tamamen farklıdır”
“Değişiklik günlüğü kullanıcıya yöneliktir”

Sanırım o gemi çoktan kalktı
Çoğu şirket “Bug Fixes & Performance Improvements” ile yetiniyor
En azından emek harcanmayacaksa, üretilmiş bir değişiklik günlüğü hiç olmamasından iyidir
- Her hafta güncellenen, otomatik güncellemeli yazılımda denediğim en iyi yöntem, kullanıcıya görünen commit’lerin başına uv: koymaktı
  Sonra her hafta bunları arayıp metni aynen kullanıyor ya da biraz düzenliyordum
  Bunları ürünün kendi Help/Release-notes menüsüne de koyuyordum
  Benim yapmadığım, hatta adını bile duymadığım bir şeyi yapmayı bırakmamın söylenmesi biraz komik
  Normalde yalnızca veritabanı şeması migration’ları ya da başka önemli şeyler için özel önekler kullanırım
- O, değişiklik günlüğü ile sürüm notlarını karıştırıyor
  Galiba commit’lere de iyi ad veremiyor; muhtemelen sembol adlarını da iyi veremiyordur
  Bu bir yetkinlik meselesi ve bunu kamuya açık şekilde dert ettiği için geçip gidebilirsiniz

GN⁺ 2026-06-06

Lobste.rs görüşleri

conventional commits hakkında içgüdüsel bir iticilikten ziyade mantıklı bir karşı argüman sunan bir yazı görmek güzel
Neden sevmediğimi çok derin düşünmemiştim; belki de bunu LLM’in ürettiği kodla ilişkilendirmeye başlamışımdır. Özellikle chore: en sevmediğim şey; keşke Macar gösterimini yeniden icat etmeye kalkmasak. Zaten en başta hiç var olmamalıydı
- Özellikle chore:, artık Angular commit stil kılavuzunda da yok; sanırım fazla muğlak olduğunu fark edip build: içine çektiler
  Angular stilinde olduğu dönemde bile chore: açıklaması oldukça belirli kullanım alanları tarif ediyordu, ama bazı açık kaynak projelerde kelimenin tam anlamıyla yapması can sıkıcı işler gibi hissedilen değişikliklere havadan ekleniyor gibi duruyor
conventional commits’i sevmiyorum ama önerilen alternatif de scope’un neden isteğe bağlı olduğunu kaçırıyor gibi
Belirgin modülleri çok olmayan küçük projelerde “scope” kavramı pek kullanışlı değil. İkisinin de atladığı faydalı bir pratik olarak, commit başlığına issue ya da bilet numarası koymak değişikliğin ek bağlamını anlamayı kolaylaştırıyor ve özellikle code review sırasında yardımcı oluyor. Ama bilet numarasını zorunlu yapmak da hoşuma gitmiyor; çünkü ufak değişiklikler için işe yaramaz biletler üretiliyor. Yine de belirli bir bug ya da işi ele alan bir değişiklik, ilgili bug’a ya da işe bağlanmalı
- scope gerekmiyorsa doğrudan atlanabilir
  Sadece başlık satırına bakınca bile görülebilen, gereksiz yere tekrar eden commit “type”ından yine de daha iyi
- İdeal olarak herhangi bir katı commit stili olmamalı; o commit’e uygun ifade neyse o kullanılmalı diye düşünüyorum
  Değişiklik bir biletle net biçimde eşleşiyorsa “bilet numaralı” commit kullanılabilir, değilse başka bir yol seçilebilir. Bazı değişiklikler type’a daha iyi uyar ama scope’a daha az uyar, bazılarında da tersi geçerlidir; bu yüzden scoped commits ile conventional commits karıştırılarak da kullanılabilir
“Paragraf metninde sabit genişlikli yazı tipi kullanmayın” demek istiyorum
Yine de yazının temel önermesine büyük ölçüde katılıyorum
Commit mesajları pek iyi olmasa bile değişiklik kapsamını anlamak için sık sık git log --name-only ya da git log --stat kullanmayı öneririm
Dosya adlarına bakmak, her commit’i tek tek açmadan neyin değiştiğini anlamada epey yardımcı oluyor
Gerçekten hoşuma giden yöntem, PR başlıklarında conventional commit stilini zorunlu kılmak
PR başlıkları merge sonrasında da maintainer tarafından düzenlenebilir, commit geçmişini yeniden yazmayı gerektirmez ve release-drafter gibi araçlarla birlikte kullanıldığında GitHub release’lerinde anlamlı değişiklik günlüklerini otomatikleştirebilir. Yazarın sözünü ettiği paydaşlara uygun doğru ayrıntı düzeyini sağlar; yani özellikleri, düzeltmeleri ve breaking change’leri ayırarak gösterir ve bir sonraki GitHub release taslağı için makul bir semver artışını da otomatik işler
Yazıda, parse-lib gibi bir bileşenin isteğe bağlı olmaması gerektiği yönündeki eleştiri doğru; ayrıca conventional commits’i zorunlu kılmanın yeni katkıları caydırabileceğine de katılıyorum. Ama alternatifler de pek daha iyi görünmüyor
Yine de breaking change belirteci olan fix!(parse-lib): Don't leave sparse holes when parsing JSON arrays oldukça fazla bilgi veriyor. Belirli bir bileşendeki bir bug düzeltmesi olduğunu, bu düzeltmenin kaçınılmaz olarak bir breaking change getirdiğini ve minor semver artışı gibi bir anlam taşıdığını anlatıyor. Bu tür şeyler PR başlığında kullanılabilir
Commit disiplini teşvik etmenin yolu olarak conventional commits’e fazla kapıldığımı ve sonunda bunun alışkanlığa dönüştüğünü kabul ediyorum
Şimdi ise zaman zaman kısıtlayıcı ve keyfi geliyor. Bazı projelerde bunun gerçekten yerleşik pratik olup olmadığını bile bilmiyordum ve daha çok Linux/Go/Node stiline yaklaştım; çeşitli yapılandırmaları olan monorepo’larda da type’ı zorlamaktansa [service]: [what changed] yazmak daha doğal geliyordu. Bundan sonra katı kurallara uymaya çalışmaktansa neyin faydalı göründüğüne göre kişisel commit stilimde daha fazla deneme yapmayı düşünüyorum; scoped commits de iyi bir başlangıç noktası gibi duruyor
chore(lobsters): add my 2 cents on conventionals commits [JIRA-69420]
Neredeyse her şeye katılıyorum ama “commit log’un anlattığı hikâyenin güvenilirliğini düşüren revizyonist bir kayıt anlayışını katkıda bulunanlara göstermek” kısmında bir noktada ayrılıyorum. Yazar galiba daha çok public branch’lerden bahsediyor; öyleyse bu makul bir tavsiye. Ama private branch’ler için geçerli olmamalı. Son değişiklikleri inceleyecek kişi, yani maintainer ya da 10 yıl sonraki ben, ne olduğunu rahat anlayabilsin yeter; tutarsız düşünce akışını ya da daha kötüsü address review commit yığınlarını bırakmaya gerek yok
“Neden scope isteğe bağlı?” sorusunun cevabı, küçük projelerde aslında tüm projenin scope olması
Commit’in “type”ının çok faydalı olmadığına katılıyorum ama scoped commits ile conventional commits arasında da büyük bir fark olup olmadığından emin değilim. Scoped, sadece “type” kısmı çıkarılmış bir conventional gibi; yine de fix, feat, refactor, chore ayrımı yapılmasında bir sorun görmüyorum
Herkes commitlint’in varsayılanlarını aynen alıyorsa, belki de mesele insanların onu daha iyi kullanmasını sağlamak değil midir?