چرا باید Conventional Commits رو کنار بذاری
خلاصهٔ کاملتر
نویسنده تو این مطلب یه موضع صریح میگیره: باید استفاده از Conventional Commits رو کنار بذاریم. Conventional Commits یه استاندارد محبوب برای فرمت پیام کامیته که پیام رو به شکل [scope]: description مینویسه — یعنی اول نوع تغییر (مثل fix یا feat) میاد. به گفتهٔ نویسنده این استاندارد «فعالانه بد»ه چون تمرکز رو میذاره رو چیز اشتباه و به وعدههاش هم عمل نمیکنه.
استدلال اول نویسنده اینه که در این فرمت «نوع» بر «اسکوپ» اولویت داده شده، در حالی که برعکسشه. اسکوپ یعنی اینکه تغییر به کدوم بخش کد مربوطه، و نویسنده میگه این چیزیه که آدمها واقعاً بهش اهمیت میدن: یه مشارکتکننده، یا کسی که دنبال باگه یا داره به یه قطعی سرویس رسیدگی میکنه، وقتی لاگ کامیتها رو میخونه دنبال اینه که «کدوم قسمتها دست خورده»، نه اینکه نوع تغییر چی بوده. ولی Conventional Commits اسکوپ رو اختیاری کرده و نوع رو جلو انداخته.
نویسنده میگه خود «نوع» هم اغلب اضافهست، چون توضیح کامیت معمولاً خودش نوع تغییر رو لو میده؛ وقتی مینویسی فلان باگ رو درست کردی، واضحه که یه bugfixه و نوشتن fix فقط جای باارزش خط اول رو هدر میده. بدتر از اون، گاهی محدودکننده هم هست چون یه تغییر میتونه همزمان fix و refactor و feature باشه و مجبوری یکی رو انتخاب کنی.
بعد سراغ وعدههای Conventional Commits میره و به نظرش هیچکدوم درست از آب درنمیان. مثلاً ساخت خودکار CHANGELOG رو بد میدونه، چون مخاطب چنجلاگ (کاربر نهایی) با مخاطب لاگ کامیت (توسعهدهنده) فرق داره. تعیین خودکار نسخهٔ سمنتیک هم بهخاطر revertها و تغییرات شکنندهٔ ناخواسته قابلاعتماد نیست. حتی هشدار میده که تریگرکردن بیلد بر اساس نوع کامیت خطرناکه: یه کامیت با عنوان بیخطر مثل docs: fix typos میتونه یواشکی آسیبپذیری وارد کنه و از بررسیهای خودکار رد شه.
راهحل نویسنده اینه که سراغ کامیتهای «اسکوپمحور» بریم — همون کاری که پروژههای موفقی مثل Linux، Git، Go، FreeBSD و Node.js میکنن و پیام رو به شکل subsystem: description مینویسن (مثلاً net/http/cookiejar: add godoc links). نویسنده حتی یه سایت به اسم scopedcommits.com راه انداخته تا این سبک رو تبلیغ کنه، و اشاره میکنه که چون هوش مصنوعیها هم پیشفرض از Conventional Commits استفاده میکنن، این الگوی بد داره بیشتر پخش میشه.
نکات کلیدی:
- نویسنده معتقده باید Conventional Commits رو کنار گذاشت
- ایرادش: نوع تغییر رو جلو میندازه و اسکوپ (بخش کد) رو اختیاری و کمارزش میکنه
- به نظرش نوعِ تغییر اغلب اضافه و گاهی محدودکنندهست
- وعدههایی مثل چنجلاگ و نسخهدهی خودکار بهخاطر revertها قابلاعتماد نیستن
- جایگزین پیشنهادی: کامیتهای اسکوپمحور مثل Linux و Go، معرفیشده تو scopedcommits.com
