آشنایی با گیت (git) – بخش دوم

نویسنده : سید ایوب کوکبی ۱۳ اردیبهشت ۱۳۹۸
آشنایی با گیت (git) - بخش دوم

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

از تنۀ اصلی شروع کنید

گیت مثل یک درخت عمل می‌کند. کدبیس اصلی پروژه trunk یا تنۀ درخت نام دارد. کامت‌های اضافه شده مثل شاخ و برگ درخت آن را گسترش داده و مرتفع می‌کنند. حتی حذف کدها نیز تغییر تلقی شده و باعث رشد درخت می‌شود. چیزی مثل undo در تکست ادیتور است که حتی backspace های شما را هم ذخیره می‌کند. گیت در حالت پیش‌فرض به trunk عنوان master داده است. شما می‌توانید از این درخت بالا بروید و پایین بیایید و این کار را طبق توضیحات بخش اول با checkout کردن شاخه‌ها انجام می‌دهید.

شاخه‌سازی

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

بخوانید  روش‌های ساخت اپلیکیشن موبایل

راه مقابله با این مشکل کامت کردن تغییرات در شاخه‌ای جدید است. مثلاً شما که می‌خواهید باگی را برطرف کنید یک شاخۀ جدید درست می‌کنید و تغییرات را به جای مستر در شاخۀ اختصاصی خودتان کامت می‌کنید. همکارتان می‌تواند شاخۀ دیگری برای اضافه کردن فیچر جدید اضافه کند؛ همینطور الی آخر. در واقع هر کسی شاخۀ خودش را گسترش می‌دهد و کاری به تنۀ اصلی یا trunk ندارند.

برای صرفه‌جویی در فضا، نمایش بصری شاخه‌ها به صورت افقی است. در تصویر پایین ترانک در سمت چپ قرار دارد (داخل پرانتز با root مشخص شده یعنی ریشۀ درخت)، همینطور که به سمت راست می‌رویم کامت‌ها را می‌بینیم که با دایره مشخص شده‌اند. از کامت دوم روی ترانک شاخۀ جدیدی به نام Branch ساخته شده است و کامت‌های ۱ و ۲ روی آن ارسال شده است. همزمان که شما روی شاخۀ جدید کار می‌کنید فرد دیگری کامت‌های ۳ و ۴ را روی ترانک یا شاخۀ مستر ارسال کرده است.

نمایش شاخه‌ها در گیت

ارسال تغییرات

اکنون شما تغییرات را در شاخۀ خود اعمال می‌کنید ولی هدف نهایی ترکیب این شاخه با شاخۀ اصلی (ترانک یا همان مستر) است. این کار بسته به نرم‌افزاری که استفاده می‌کنید (گیت‌هاب، گیت‌لب وبیت‌باکت) pull Request یا merge request نام دارد که به اختصار PR یا MR نوشته می‌شوند. در واقع شما درخواست می‌دهید که تغییرات شما را pull و merge کنند. از این به بعد برای اختصار در نوشته از PR استفاده می‌کنیم.

بعضی افراد اولین باری که درخواست PR می‌فرستند عصبی می‌شوند چون معلوم نیست چه زمانی درخواستشان با کدهای اصلی مخزن ترکیب شود ولی چاره‌ای نیست. بیشتر تیم‌ها از درخواست‌هایی که روی آن‌ها کار شده استقبال می‌کنند. PR یکی از مهم‌ترین مکانیزم‌ها در پروژه‌های متن‌باز است. در این لینک جزئیات بیشتری دربارۀ چگونگی ارسال PR و آداب ارسال آن ذکر شده است. حتی یک جامعۀ کوچک برای افرادی که اولین بار می‌خواهند در پروژه‌های متن‌باز همکاری کنند تاسیس شده که مقدمات کار را آموزش داده است. اما شاید مهم‌ترین اصل در هنگام ارسال PR این باشد که دلیل واضحی برای اعمال آن تغییرات بیان کنید.

بخوانید  بهبود سرعت build در اندروید استودیو

بحث و بررسی

بعد از ارسال PR، شخص دیگری در تیم درخواست شما را بررسی و فیدبک می‌دهد. آن فرد می‌تواند با پرسیدن سوالات و گذاشتن کامنت دربارۀ درخواست ارسالی بحث کند. گاهی بحث به آنجا می‌رسد که تغییرات اعمال شده نیازمند یک سری اصلاحات است تا بتواند با شاخۀ اصلی ادغام شود. این کار گاهی توسط فرد دیگری انجام می‌شود ولی اغلب موارد از شما درخواست می‌شود که تغییرات را اعمال کنید. با توجه به گفتگوی انجام شده، یک یا چند کامت جدید به شاخۀ اضافه می‌کنید و مجدداً به شاخۀ origin پوش می‌کنید. با این کار PR به صورت خودکار بروزرسانی شده و آخرین تغییرات را نمایش می‌دهد. اگر مشکلی وجود نداشته باشد درخواست شما تأیید و تغییرات با trunk ترکیب می‌شود.

بروز بودن PR

در صورتی که زمان زیادی از پذیرش PR شما بگذرد ممکن است در حالت stale (کهنه یا بیات) قرار بگیرد. یعنی پول ریکوئست شما اکنون که ترانک تغییر کرده کار نمی‌کند. آن درخواست مثلاً برای دو هفته قبل قابل ادغام با ترانک بود. اکنون قدیمی است و ادغام آن با ترانک تضمین نمی‌شود.

برای بروزنگه‌داشتن PR دو راه وجود دارد:

  • می‌توانید از دستور git merge master استفاده کنید. این کار هر تغییر جدیدی در ترانک را بر کار شما اعمال می‌کند؛
  • می‌توانید از git rebase master استفاده کنید. این دستور کارهای شما را بر روی جدیدترین تغییرات ترانک اعمال می‌کند.

در هر دو حالت، تغییرات اعمالی شما یکسان است. شما فقط شاخۀ خود را در بالای ترانک قرار داده‌اید تا همواره با جدیدترین تغییرات ترانک هماهنگ باشد. تیم‌های مختلف معمولاً یکی از این روش‌ها را مبنا قرار داده و اغلب از دستور merge که ایمنی بیشتری دارد استفاده می‌کنند.

بخوانید  آموزش گیت - قسمت هشتم

تداخل‌ها

در هنگام merge و rebase کردن ممکن است با تداخل‌هایی مواجه شوید که اصطلاحاً conflict خوانده می‌شوند. این یعنی شما دقیقاً قسمتی از کد را تغییر داده‌اید که شخص دیگری پیش از شما آن قسمت را تغییر داده است و اکنون گیت نمی‌داند کدام یک را اعمال کند. در چنین وضعیتی گیت قسمتی که تداخل دارد را بین علامت‌های >>>>>>> ======= <<<<<<< قرار می‌دهد.

اگر چنین علامتی مشاهده کردید وحشت نکنید. با کمی تمرین به راحتی می‌توانید مشکل را حل کنید. در بخش‌های بعدی این مقاله به بحث تداخل‌ها خواهیم پرداخت ولی اگر عجله داشتید این مقاله را بخوانید.

پذیرش تغییرات

بعد از پاسخ دادن به همۀ کامنت‌های PR و حل مشکل تداخل، تغییرات شما آمادۀ ادغام با ترانک هستند. ادمین پروژه می‌تواند PR را تایید و به شاخۀ trunk وارد کند. در تصویر پایین همانطور که می‌بینید کامت‌های شاخۀ Branch در ترانک شماره ۵ ادغام شده‌اند. دقت کنید تغییرات جدید در غالب یک کامت جدید اعمال شده است.

تبریک، شما اولین Pull Request خود را اعمال کردید.

سید ایوب کوکبی

نویسنده و مترجم...

0 دیدگاه

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *