درود دوستان 👋 گیت یکی از ابزارهایی هست که یاد گرفتن اون خیلی راحته و کافیه دستورات پرکاربرد اون رو به خاطر بسپاریم. اما قسمت سخت اون، نحوهٔ استفاده از اون دستورات هست. کارایی دستوری مثل git commit رو شاید همه بدونیم، اما اینکه کجا و به چه صورت از اون استفاده کنیم نیازمند تجربیاتی هست که توی این قسمت می‌خوایم اونها رو براتون به اشتراک بذارم.

توی این قسمت نکات زیر رو بررسی می‌کنیم:

  1. کامیت‌های زود به زود
  2. متن کامیت خوانا
  3. استفاده از Feature Branch
  4. بروزرسانی مرتب با برنچ اصلی
  5. استفاده از هوک‌های گیت
  6. استفاده از Git Stash

 

۱. کامیت‌های زود به زود

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

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

مزیت دیگهٔ اون برای زمانی هست که می‌خوایم یک قابلیت که مرج شده رو برگشت بزنیم (Revert). وقتی می‌خوایم کامیت مد نظر رو Revert کنیم، اگه اون کامیت شامل تغییرات بی‌ربط اما مهم باشه، اون تغییرات بی‌ربط هم ناخواسته Revert میشه.

نکتهٔ مهمی که باید در نظر داشته باشیم حفظ تعادل هست. کامیت‌های ما نه باید شامل تغییرات خیلی ریز و جزئی باشن و نه شامل تغییرات گسترده و عظیم. وقتی کامیت‌های ما بیش از اندازه ریز باشن، ممکنه قابلیت (Feature) هایی که اضافه کردیم رو مجبور باشیم توی چند کامیت پیدا کنیم که برای خواننده کار سختی به حساب میاد. بنابراین خوبه که همیشه فکر کنیم آیا لازمه الان کامیت کنم یا نه.

 

۲. متن کامیت خوانا

متن یک کامیت مثل نام‌گذاری یک متغیر هست و هر دو یه یک اندازه حائز اهمیت هستن. مطمئناً استفاده از "git commit -m "fix bug مثل استفاده از x برای نام‌گذاری یک متغیر خیلی راحت و لذت‌بخش به حساب میاد. اما درس بزرگ رو زمانی می‌گیریم که می‌خوایم ببینیم این کد چه‌جوری اضافه شده و چه چیزی رو تغییر داده. نسبت دادن یک عنوان به یک کامیت دلایل و فلسفه‌هایی داره و طبیعتاً استفاده از چیزهایی fix bug اون رو زیر سوال می‌بره. برای مثال وقتی بعد از ۳ ماه توی تاریخچه کامیت‌ها نگاه می‌کنیم و می‌بینیم fix bug، از خودمون خواهیم پرسید که «چه باگی؟ کدوم قسمت؟ چرا اتفاق افتاد و چطوری برطرف شد؟» و به ناچار باید تک تک کامیت‌ها رو باز کنیم و تغییرات فایل‌ها رو نگاه کنیم تا ببینیم دقیقاً توی اون کامیت چه اتفاقی افتاده.

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

fix: user login error on retry 

or: 

fix(login): prevent crash when retrying after failed auth

 

۳. استفاده از Feature Branch

Feature Branch به برنچی گفته میشه که از برنچ اصلی ساخته میشه و تقریباً هر تغییراتی (اضافه کردن فیچر، رفع باگ و ...) توی برنچ فیچر ساخته میشه. برای مثال اگه قصد داریم یک باگ رو رفع کنیم، از برنچ اصلی (main یا master) یک برنچ می‌سازیم به اسم fix-login-crash-after-failed-auth و توسعه رو توی اون برنچ انجام می‌دیم و نهایتاً وقتی کار ما به اتمام رسید و همهٔ تست‌ها و بررسی‌ها (Code Review) انجام شد، اون رو مرج می‌کنیم روی برنچ اصلی. مهمترین مزینت این روش ایزوله کردن فعالیت‌ها و در امان موندن برنچ اصلی از Push شدن کدهای ناخواسته هست.

 

۴. بروزرسانی مرتب با برنچ اصلی

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

git checkout main
git pull
git checkout my-feature-branch
git merge main

توی ۴ دستور بالا ابتدا وارد برنچ اصلی شدیم. بعد آخرین تغییرات رو از ریپازیتوری ریموت دریافت کردیم. سپس وارد برنچ فیچر شدیم و تغییرات برنچ اصلی رو آوردیم روی برنچ خودمون. این کار کمک می‌کنه از کانفلیکت (Conflict) های بزرگ جلوگیری کنیم.

 

۵. استفاده از هوک‌های گیت

هوک‌های گیت کدهایی هستن که هنگام رخ دادن یک اتفاق خاص (مثل کامیت کردن یا Push و Pull) می‌تونن اجرا بشن. معروف‌ترین کارایی که این هوک‌ها دارن اینه که می‌تونن یک سری کارهای ما مثل تست کردن و اجرای Linter و Prettier رو خودکار انجام بدین و به قول معروف Automate کنن.

مثلاً می‌خوایم یک کامیت انجام بدیم که شامل ۱۰ تا فایل میشه. با استفاده از یک هوک می‌تونیم تست‌های این ۱۰ تا فایل رو اجرا، و یا ESLint و Prettier رو روی اونها اعمال کنیم.

معروف‌ترین ابزار برای کار با هوک‌های گیت هست.

 

۶. استفاده از Git Stash

گاهی اوقات می‌خوایم سوئیچ کنیم روی برنچ‌های دیگه، اما تغییرات ما هنوز کامیت نشدن و بنابراین گیت اجازهٔ این کار رو نمیده. شاید ساده‌ترین راه حلی که به ذهنمون برسه اینه که تغییرات رو کامیت کنیم تا بتونیم سوئیچ کنیم روی برنچ مد نظرمون. اما همونطور که گفتیم یک کامیت خوب می‌بایست شامل تغییراتی منطقی و قابل فهم باشه. وقتی بجای Stash از کامیت استفاده می‌کنیم، کامیت ما ممکنه شامل تغییراتی بی‌ربط و ناتمام باشه که مشکلاتی رو به وجود میاره که توی نکته شماره ۱ به اونها اشاره کردیم.

 

خب دوستان این پست هم به پایان رسید. نکاتی رو بررسی کردیم که شامل تجربیات من بود. آیا شما هم تجربیاتی از استفاده از گیت دارین؟ توی قسمت نظرات برای همه به اشتراک بذارین 😉👋