بهترین تمرین های گیت

در نگاه اول اسم مقاله ممکنه خیلی واضح نباشه اما در واقع ترجمه Best Practice هست. استفاده از هر ابزاری راه و روشی داره که از طرف خود سازنده به عنوان بهترین تمرین ها ارائه شده و رعایتشون باعث افرایش کارایی است. تو این مقاله در مورد بهترین تمرین های گیت ( Git ) صحبت میکنم.

فاصله کامیت هارو کوتاه کنید

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

کامیت برای تغییرات مرتبط

درصورتی که ۲ تا باگ داریم و میخواهیم درستشون کنیم باید از ۲ تا کامیت استفاده کنیم. کامیت های کوچیک باعث میشه درک تغییرات برای سایر برنامه نویسان (سایر توسعه دهندگان پروژه) راحت تر باشه. همچنین اگه این کامیت ها باعث مشکل شده باشند راحت تر میشه undo کرد.

کارهای نیمه تموم رو کامیت نکنید

کامیت ها باید بعد از تموم شدن کد انجام بشه . معنی این جمله این نیست که باید یک پروژه رو کامل کنیم تا کامیت کنیم. بهترین روش اینه که اگه میخواهیم جزیئات جدیدی اضافه کنیم ، اونها رو به قسمت های کوچیک تری تقسیم کنیم و بعد از انجام هر قسمت کامیت انجام بدیم.

نکته دیگه هم که تو این قسمت میشه بهش اشاره کرد اینه که فرض کنید در پایان روز کاری هستید و میخواهید کارو تعطیل کنید ولی هنوز بخشی از کدتون که لازم به کامیت شدن هست کامل نشده که کامیت کنید. پس خیلی عجولانه تصمیم میگیرد که کارتون رو کامیت و حتی پوش کنید تا اگه اتفاقی افتاد حداقل آخرین ورژن از کدهاتون رو داشته باشید. این روش به ظاهر درست هست اما گیت دنیای خیلی بزرگی داره و برای هر چیزی که شما بهش فکر کنید یک راهکار مناسبی وجود داره . برای این مواقع از دستور git stash استفاده کنید.

قبل از کامیت، کد ها رو تست کنید

وقتی کدی رو کامل میکنید دوست دارید که اونو کامیت و پوش کنید اما درواقع کدی که تست براش ننوشته شده باشه هنوز کامل نیست!
پاس کردن تست ها نشون میده که کد واقعا کامل شده و مشکلی نداره .
بهتره کدهای لوکال رو بعد از اتمام کامیت کنیم و موقع پوش کردن رو remote تست هاشو انجام بدیم و بعد push کنیم.

پیام کامیت مناسبی بنویسید

پیام مناسب کامیت باعث میشه درآینده با نگاهی کوتاه به پیام کامیت به تغییرات انجام شده پی ببریم. پس این پیام باید مشخصه هایی داشته باشه. توصیه شده که طول این پیام بیشتر از ۵۰ کارکتر نباشه!
این پیام باید ۲ تا سوال رو جواب بده:
۱- انگیزه این تغییر
۲- تغییر این فایل به نسبت وضعیت قبلی

از جملات دستوری با زمان حال ساده استفاده کنید. مثلا برای تغییر یک متغیر از پیغام change استفاده کنید. استفاده از changes و یا changed اشتباه است.

ورژن کنترل ها جایگزین سیستم های بک اپ نیستند

درسته که میشه از ویژگی سیستم کنترل ها برای بایگانی و بک آپ استفاده کرد اما ورژن کنترلرها برای بک آپ فایل های شما نیستند. فلسفه فایل پشتیبان و ورژن کنترل‌ها کاملا باهم متفاوت هستند. پس از فایل های خود پشتیبان مناسب تهیه کنید.

از برنچ ها استفاده کنید

از ویژگی های منحصر به فرد ورژن کنترل ها شاخه بندی و یا همون branch هست. این ویژگی قوی به ما اجازه میده که هر ویژگی جدید رو بدون دردسر روی پروژه اصلی پیاده کنیم و خیالمون از هر جهت راحت باشه. پس برای راحتی بهتره که هر ویژگی جدی ، ایده نو و یا فیکس کردن باگی رو تو یک برنچ انجام بدیم.

بر روی یک جریان مشخص توافق کنید

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

https://virgool.io/@novonimo/مکمل-قردتمند-گیت-git-flow-ufhgxx6j6ah3

داکیومنت مناسب مطالعه کنید

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

همچنین میتونید از خود گیت هم برای آموزش استفاده کنید. به این شکل که: