استفاده از Git برای ما برنامه نویسان امری ضروری است، چه در پروژه های شخصی، چه در پروژه های منبع باز با افراد زیادی و چه در کل جامعه.
با توجه به آن، مهم است که استفاده کنیم git commit به درستی. داشتن یک زبان منسجم و استاندارد به همه افراد درگیر در پروژه کمک می کند تا تغییرات رخ داده را درک کنند.
در تصویر بالا، می بینیم که یک ارتکاب با اظهار نظر ضعیف چقدر می تواند مضر باشد، زیرا ما در درک ماهیت تغییر رخ داده و زمینه آن ناتوانیم. در درازمدت، این تأثیر حتی آسیب‌رسان‌تر است، زیرا قابلیت نگهداری نرم‌افزار به دلیل ناهماهنگی در دامنه این تغییرات و تأثیر آنها بر پروژه در گذشته آسیب می‌بیند.
با در نظر گرفتن این موضوع، اجازه دهید کمی در مورد آن صحبت کنیم الگوی تعهدات متعارف.
چیست؟
Conventional Commits یک قرارداد ساده برای پیام‌های commit است که از مجموعه‌ای از قوانین پیروی می‌کند و به پروژه‌ها کمک می‌کند تا تاریخچه تعهد صریح و ساختار یافته داشته باشند.
چگونه از آن استفاده کنیم؟
قوانین بسیار ساده هستند، همانطور که در زیر نشان داده شده است نوع از تعهد، زمینه (محدوده) از تعهد و پیام (موضوع) از ارتکاب
!type(?scope): !subject
<?body>
<?footer>
بدین ترتیب، ! نشان دهنده صفات اجباری و ? ویژگی های اختیاری را نشان می دهد.
موضوع: امری به جای زمان گذشته
به این ترتیب ما به تیم خود می گوییم که در صورت اعمال تعهد چه کاری انجام خواهد داد.
“در صورت اعمال، این تعهد خواهد شد”
“اگر اعمال شود، این commit نشانه گذاری را تغییر می دهد”، که بسیار منطقی تر از موارد زیر است: “در صورت اعمال، این commit نشانه گذاری را تغییر می دهد”
نوع: انواع commit ها کدامند
نوع مسئول این است که به ما بگوید چه تغییر یا تکراری در حال انجام است، از قوانین کنوانسیون، انواع زیر را داریم:
-
test: هر نوع ایجاد یا تغییر کدهای تست را نشان می دهد.
مثال: ایجاد آزمون های واحد. -
feat: نشان دهنده توسعه یک ویژگی جدید برای پروژه است.
مثال: افزودن یک سرویس، عملکرد، نقطه پایانی و غیره -
refactor: زمانی استفاده می شود که یک کد مجدد وجود داشته باشد که هیچ تاثیری بر منطق/قوانین سیستم نداشته باشد.
مثال: کد پس از بررسی کد تغییر می کند -
style: زمانی استفاده می شود که قالب بندی کد و تغییر سبک وجود داشته باشد که به هیچ وجه سیستم را تغییر نمی دهد.
مثال: تغییر راهنمای سبک، تغییر قرارداد پرز، رفع تورفتگی‌ها، حذف فضاهای سفید، حذف نظرات و غیره… -
fix: هنگام تصحیح خطاهایی که باعث ایجاد اشکال در سیستم می شوند استفاده می شود.
مثال: برای تابعی که مطابق انتظار عمل نمی کند و خطا را برمی گرداند، یک هندلینگ اعمال کنید. -
chore: تغییراتی را در پروژه نشان می دهد که روی سیستم یا فایل های آزمایشی تأثیری ندارد. اینها تغییرات رشدی است.
مثال: تغییر قوانین برای اسلینت، اضافه کردن زیباتر، پسوندهای فایل بیشتری را به آن اضافه کنید .gitignore -
docs: زمانی استفاده می شود که تغییراتی در اسناد پروژه ایجاد شود.
مثال: اطلاعات را در اسناد API اضافه کنید، README را تغییر دهید و غیره. -
build: برای نشان دادن تغییراتی که بر فرآیند ساخت پروژه یا وابستگی های خارجی تأثیر می گذارد استفاده می شود.
مثال: Gulp، اضافه/حذف npm وابستگی ها و غیره … -
perf: نشان دهنده تغییری است که باعث بهبود عملکرد سیستم شده است.
مثال: ForEach را به while و غیره تغییر دهید… -
ci: برای تغییرات در فایل های پیکربندی CI استفاده می شود.
مثال: دایره، تراویس، BrowserStack، و غیره… -
revert: نشان دهنده معکوس شدن یک commit قبلی است.
توجه داشته باشید:
-
فقط یکی نوع در هر تعهد؛
-
این نوع است اجباری;
-
اگر نمی دانید کدام نوع برای استفاده، احتمالاً یک تغییر بزرگ است و امکان تقسیم آن وجود دارد مرتکب شدن به دو یا چند تعهد؛
-
تفاوت میان
buildوchoreمی تواند کاملاً ظریف باشد و می تواند منجر به سردرگمی شود، بنابراین ما باید از درست آگاه باشیم نوع. برای مثال، در مورد Node.js، می‌توانیم فکر کنیم که وقتی یک اضافه/تغییر به یک وابستگی توسعه خاص وجود دارد درdevDependencies، ما استفاده می کنیمchore. برای تغییرات/افزودن وابستگی‌های رایج به پروژه، که تأثیر مستقیم و واقعی بر روی سیستم دارند، ازbuild.
دامنه: زمینه سازی commit
در این مرحله – و به دنبال کنوانسیون های گذشته – ما موفق شدیم نوع تغییری را که در commit ایجاد شده بود، درک کنیم (نوع تعهد) و به وضوح درک کنید که این تعهد در صورت اعمال چه چیزی را به همراه خواهد داشت (تعهد موضوع).
هر چند دامنه این است غیر اجباری، می توان از آن برای زمینه سازی تعهد و ایجاد مسئولیت کمتر برای موضوع استفاده کرد و آن را تا حد امکان مختصر و مختصر کرد. به یاد داشته باشید که محدوده باید در commit بین پرانتز درج شود.
توجه داشته باشید: محدوده ها باید با /
نتیجه
این مقاله را نوشتم تا یکی از آموخته هایم را ثبت کنم (آنها فقط چند یادداشت در برنامه مفهومی بودند)، اما من امیدوارم که بتواند به سایر برنامه نویسان در آنجا کمک کند.
