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

خب بیایین راجع به بهترین شیوه‌ها یا best practiceهایِ commit صحبت کنیم.

اول از همه commitهاتون نباید خیلی بزرگ یا خیلی کوچک باشن. نمی‌خوام هر بار که یه تغییر کوچک در file انجام می‌دیم commit کنیم چون در پایان commitهایی مثلِ update file1، یا update file2 و… رو خواهیم داشت که اشتباه و ناکارآمده.

از طرفِ دیگه نمی‌خوایم که commitهامون خیلی بزرگ باشن. نمی‌خوایم که منتظرِ پیاده‌سازیِ یک ویژگیِ کامل قبل از کامیت کردن باشیم. (مثلِ کامیتِ Build the forum) نمی‌خوایم که سه روز کد بزنیم و بعد یه کامیت انجام بدیم.

هدفِ کامیت کردن یه ضبطِ یه سری نقطه‌ها‌ی برگشت (Check Point) برا خودمون هستش. که اگر یه جایی خراب‌کاری کردیم بتونیم برگردیم به قبل و کد قبلی‌مون رو داشته باشیم.

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

وقتی دارین کد می‌زنین وقتی به یه نقطه‌ای رسیدین که می‌خواین ذخیره بشه یه کامیت بسازین.

همچنین هر کامیت باید یک جداکننده‌ی منطقی داشته باشه. پس مسائل رو قاطی نکنین. برای مثال، اگر دارین یک باگ رو رفع می‌کنین و بعدش تصادفاً یه اشتباه تصادفی در برنامه‌تون پیدا کردین نباید هر دوی این‌ها رو در یک commit انجام بدین. باید دو کامیت جدا داشته باشین. یکی برای اشتباه تایپی یا غلط املایی (Typo) و یکی دیگه برای رفعِ باگ (Bug Fix).

حال اگر شما، هر دویِ این‌ها رو تصادفاً یه جا Stage کردین می‌تونیم خیلی راحت unstageشون کنیم. بعداً در این بخش نشونتون می‌دم که چطور این‌کار رو بکنیم.

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

اگر خیلی کار در یک کامیت انجام بدین قادر نخواهید بود که یک پیغامِ خوب بنویسین.

اوکی؛ حالا در مورد جمله‌بندی. اکثرِ مردم از زمانِ حال در کامیت‌هاشون استفاده می‌کنن. پس بجایِ نوشتنِ fixed a bug باید بگین fix a bug. اگر این قاعده رو دوست ندارین کاملاً اوکیه. اما از هر قاعده‌ای که استفاده می‌کنین مطمئن باشین که خودتون و بقیه‌ی اعضایِ تیم از همون استفاده کنین.

PRESENT: Fix the bug.
PAST: Fixed the bug.

پس هر وقت کامیت کردین همیشه این نکات رو در نظر داشته باشین.