کامیت خوب، کامیت بد!

در دنیای بزرگ و حیرت‌آور توسعه وب، ورژن کنترل‌ها یکی از ابزار های ضروری مورد نیاز توسعه دهندگان برای همکاری باهم بر روی پروژه های مشترک هستش.
گیت (‌Git) یکی از ورژن کنترل‌های معروف و پرکاربرد هستش که به توسعه دهندگان کمک میکنه تا تغییرات رو روی پروژه اعمال بکنن یا به حالت قبل برگردوننش یا به نسخه‌های مختلف پروژه از طریق گیت دسترسی داشته باشن.
گیت تنها در صورتی موثر واقع میشه که ما کامیت خوب بنویسیم. کامیت‌ها تاریخچه کد‌های ما هستند.

کامیت (‌Commit) چیست؟

در گیت، کامیت به یک نقطه خاص از کد ما در یک زمان مشخص اشاره داره. به عنوان مثال : علی در خانه مادربزرگش امروز بازی کرد.
خانه مادبزرگ علی یک نقطه خاص. بازی کردن میشه یک رفتار از علی و امروز داره به یک زمان اشاره میکنه.
هر کامیت یک متا دیتایی از کد ما داره. که شامل (‌نویسنده،‌ مهر زمانی، پیام کامیت، و غیره … ).
از کامیت ها برای ذخیره مراحل پروژمون استفاده میشه. مثلا ما وقتی یه قسمت از پروژه رو میزنیم میایم یک کامیت در گیت میزنیم که آقا الان این قسمت انجام شده و سیوش میکنیم و درون گیت ذخیره میشه. بعدا به هر دلیلی اگه پروژمون خراب شد یا خواستیم برگردیم به اون تاریخ یا کدمون، میتونیم برگردیم به اون کامیت پروژمون و ازش استفاده لازم رو ببریم. و حتی وقتی داریم با دیگران کار میکنیم  از طریق گیت میتونیم چند نفری روی یک پروژه کار بکنیم. مثلا رضا قسمت فرانت اند پروژه رو بزنه و علی قسمت بک اند پروژه رو. رضا قسمت فرانت اند پروژه رو میزنه و یک کامیت میزنه با این پیام :‌ فرانت اند تموم شد.
علی قسمت بک اند پروژه رو تموم میکنه و مینویسه :‌ قسمت بک اند پروژه تموم شد.
حالا این دو کامیت باهم ادغام میشه و ما یک پروژه کامل رو داریم و تونستیم چند نفری روی یک پروژه کار بکنیم.

نکته :‌اینا بدیهیات بود که فقط کسایی که نمیدونن و اصلا هیچ آشنایی با گیت و کامیت ندارن متوجه بشن. جلوتر ما مسائل تخصصی تر رو داریم که به درد کسایی میخوره که گیت رو کامل بلدن.

ویژگی های یک کامیت خوب

اتمی و متمرکز :‌ یک کامیت باید اتمی باشه. یعنی ریز باشه، متعهد فقط به یک تغییر جزئی در پروژه باشه. به عنوان مثال شما میاید یک User Authentication مینویسید تو پروژتون، شما فقط باید برای همین مورد یک کامیت بنویسید نه چندتا تغییرات باهم. نه اینکه هم Ui  پروژه رو زدید هم Authentication پروژه رو بیاید کامیت بزنید که آقا من دوتاشو انجام دادم. این اشتباهه. فقط یک مورد رو انجام بدید و برای یک مورد کامیت بنویسید.

کامیت توصیفی :‌ کامیتی که مینویسید باید کاملا واضح باشه و قطعه کد شمارو توصیف بکنه که این قطعه کد دقیقا داره چیکار میکنه و چیه که بعدا وقتی خودتون خواستید سری بزنید به این قطعه کد یا کامیت، یا کسی دیگه‌ای روی این پروژه قراربود کاربکنه، یا همکاران فعلی شما نیازه که به پروژتون دسترسی داشته باشن از کامیتتون گیج نشن و کارایی کد شمارو بفهمن.
مثلا کامیت ننویسید که باگ فیکس شده، بنویسید که مشکل فلان از فلان بخش پروژه که باعث فلان شده بود حل شد.

از دستورعمل‌های کامیت استفاده کنید:
شما میتونید از دستورعمل های اجرایی خود گیت استفاده بکنید تا تاریخچه گیت تمیزتری داشته باشید، تا سازگار‌تر و تمیز‌تر باشه.
این دستورعمل ها به صورت نوع کاری که دارید انجام میدین تقسیم بندی میشن.
به این صورت :‌

1. feat
2. fix
3. chore
4. chore, refactor docs

این کلید واژه های دستوری که در درون کامیتتون استفاده میکنید خیلی به شما کمک میکنه که یک تاریخچه کامیت سازمان یافته‌ای داشته باشید.
به عنوان مثال :‌

کامیت تست شده و تایید شده :‌  مطمئن بشید قبل کامیتی که دارید میزنید اون کدتون تست شده باشه و درست کار بکنه. کد تست نشده و خراب میتونه روند پروژه شما را خراب بکنه که هم باعث اذیت کردن خودتون میشه هم باعث اذیت هم تیمیاتون.

کامیت متمرکز:‌ برای مثال وقتی روی یک فیچر خاصی دارید کار میکنید، فقط کامیتتون مرطبت به همون فیچر خاص باشه در یک کامیت باشه. از کامیتتون قرمه سبزی درست نکنید همه چیو بزنید تنگش. مثل کباب باشید، انواع خاص ولی تکه تک :))) .

ویژگی های یک کامیت بد :‌

کامیت طولانی و بدون تمرکز :‌ یک کامیت با تغییرات زیاد یک کامیت بده، بالای مقاله زیاد دربارش گفتم. کامیت وقتی طولانی میشه خب فهمیدنش سخت میشه که دقیقا داره چه اتفاقی میوفته. منظور از کامیت طولانی قطعه کدهای زیاد درون یک کامیته، همون داستان قرمه سبزی. بخش بخش هر فیچری که انجام شد به صورت اختصاصی براش کامیت بزنید.
مثال از کامیت بد :‌

کامیت گمراه کننده :‌ کامیتی که حامل پیام گمراه کننده باشه، اطلاعات خوبی از کد ما نمیرسونه، یک کامیت باید ساده اما حاوی اطلاعات به درد بخور باشه. مثلا این این کامیت گمراه کنندست :‌ چیز میزو تغییر دادم .
باید کامل و قابل فهم و توصیف کننده کد ما باشه.
مثال از کامیت بد :‌

تغییرات نامرتبط :‌ ترکیب کردن تغییرات نامرتبط پروژتون در کامیت میتونه باعث بی مصرفی و نامفهومی و ایجاد باگ در پروژتون بشه. پس یک کامیت به طور مشخص برای یک کار مشخص باشه. شما اومدین قسمت داشبورد پروژه رو نوشتین، اینجا باید یه کامیت برای داشبورد پروژتون بزنید نه اینکه قبل کامیت زدن هم داشبوردو کد بزنید هم روی دیتابیس پروژه کار بکنید بعد بیاید کامیت بزنید که :‌داشبورد پروژه و دیتابیس پروژه ساخته شد. این اشتباهه چون شما دوتا کارو تموم کردید. برای هر کدوم باید سر همون تایم کامیت مد نظرش رو میزدید.
مثال از کامیت بد :‌

کامیت بی  دلیل :‌ گاهی اوقات نباید کامیت زد. گاهی اوقات دلیلی برای کامیت زدن وجود نداره. ولی ما الکی برای اینکه کاری کرده باشیم یا به مدیرپروژمون نشون بدیم که داریم کاری انجام میدیم الکی میایم و کامیتی میزنیم. خب اینکار به ضرر پروژست و کامیت بی دلیل و الکی باعث تداخل و گمراهی  در پروژه میشه.

نتیجه گیری :‌

کامیت خوب برای تمیز نگه داشتن و قابل فهم بودن تاریخچه گیت پروژمون اجباریه.
با دنبال کردن این روش‌های ساده گفته شده مثل :‌ کامیت اتمی و متمرکز، کامیت توصیفی و مطمئن شدن از اینکه کامیت تست شدست شما میتونید همکاری بهتری با هم تیمیاتون داشته باشید و راحت تر از پروژتون نگهداری کنید.
یک تاریخچه گیت خوب و کامیت مدیریت شده، آینده خوبی رو برای پروژتون و همکارانتون که توی اون پروژه سهیم هستند رقم میزنه و هزینه‌های اضافه که ممکنه در آینده بابت همین کامیت تحمیل بشه بهتون جلوگیری میکنه.

امیدوارم کامیتای خوبی بزنید :))))
دوستدار شما، علیرضا فاضلی.

منبع :‌ https://dev.to/sheraz4194/good-commit-vs-bad-commit-best-practices-for-git-1plc