در این مقاله راهنمای گام به گام توسعه یک فیچر (Feature) جدید، به‌روزرسانی کد محلی با آخرین تغییرات مخزن اصلی و در نهایت، نحوه ثبت و مدیریت یک درخواست ادغام (Pull Request) حاوی تضادهای ادغام (Merge Conflicts) در گیت‌هاب را پوشش می‌دهیم.
راهنمای گام به گام توسعه فیچر جدید و مدیریت پول ریکوئست در گیت‌هاب
در دنیای توسعه نرم‌افزار تیمی، توسعه یک قابلیت جدید تنها نیمی از مسیر است؛ نیمه دیگر، ادغام ایمن و مؤثر آن تغییرات با کد اصلی و پایدار پروژه (معمولاً شاخه master یا main) است. این فرآیند از طریق درخواست ادغام (Pull Request - PR) انجام می‌شود.
در این مقاله، ما روند توسعه یک منوی کنسول برای برنامه ماشین حساب و نحوه برخورد با چالش اجتناب‌ناپذیر تضاد ادغام (Merge Conflict) در گیت‌هاب را بررسی خواهیم کرد.
۱. به‌روزرسانی و ایجاد شاخه توسعه (Branching)
پیش از شروع کار بر روی هر فیچر جدید، اولین و مهم‌ترین گام، اطمینان از همگام‌سازی شاخه محلی master شما با آخرین تغییرات موجود در مخزن ریموت است.
۱.۱. Fetch و Pull برای همگام‌سازی
اگرچه ممکن است یک همکار دیگر فیچری را توسعه داده باشد، اما تا زمانی که آن تغییرات در شاخه اصلی ادغام (Merge) نشده باشند، شما فقط باید خود را با آخرین نسخه مرج‌شده در master به‌روز کنید.
Fetch (واکشی): ابتدا، با زدن دکمه Fetch (واکشی) در ابزار مدیریت Git، تمامی تغییرات جدید از مخزن ریموت (از جمله کامیت‌ها و شاخه‌های جدید) را به صورت محلی دریافت می‌کنید، اما این تغییرات هنوز با کد محلی شما ادغام نمی‌شوند. این کار به شما اجازه می‌دهد وضعیت فعلی مخزن ریموت، از جمله شاخه‌هایی که هنوز در master ادغام نشده‌اند را مشاهده کنید.
Pull (کشیدن): اگر تغییرات جدیدی در شاخه master ریموت وجود داشته باشد، با زدن دکمه Pull (کشیدن)، تغییرات ریموت با شاخه محلی master شما ادغام شده و کد شما به‌روزرسانی می‌شود.
۱.۲. ایجاد شاخه جدید
پس از به‌روزرسانی master محلی، یک شاخه جدید (New Branch) برای توسعه فیچر خود ایجاد می‌کنیم. نامی مناسب و توصیفی مانند operation-menu انتخاب کنید و با چک‌اوت (Checkout) کردن بر روی آن، کار توسعه را آغاز نمایید.
۲. توسعه فیچر و ارسال تغییرات (Push)
در این مرحله، منطق برنامه (کد) برای نمایش منوی عملیات (جمع، تقسیم، ...) و دریافت ورودی کاربر در کلاس Program اضافه می‌شود. این تغییرات، قابلیت تعاملی جدیدی را به برنامه ماشین حساب ما اضافه می‌کند.
پس از اتمام توسعه و تست فیچر:
Commit (ثبت): تمام تغییرات اعمال شده را با یک پیام کامیت (Commit Message) مناسب و واضح ثبت کنید.
Push (ارسال): شاخه جدید خود (operation-menu) را به مخزن ریموت Push (ارسال) کنید تا تغییرات شما برای دیگران قابل مشاهده و بررسی باشد.
۳. ثبت درخواست ادغام (Pull Request)
یکی از اصول کلیدی در توسعه تیمی، جلوگیری از ادغام مستقیم تغییرات به شاخه‌های حیاتی (مانند master) است. به‌جای آن، از پول ریکوئست استفاده می‌شود که فرآیند بازبینی کد و دریافت تأیید پیش از ادغام نهایی را تضمین می‌کند.
۳.۱. ایجاد PR در گیت‌هاب
به وب‌سایت گیت‌هاب بروید و یک New Pull Request ایجاد کنید.
مقایسه شاخه‌ها: اطمینان حاصل کنید که شاخه مبدأ (operation-menu) به شاخه مقصد (master) ارسال می‌شود.
عنوان و توضیحات:
عنوان (Title): یک عنوان اجباری و گویا برای PR خود وارد کنید.
توضیحات (Description): توضیحات کامل و ساختارمند (با استفاده از Markdown) در مورد فیچر و تغییرات انجام شده بنویسید. این توضیحات برای بازبینان کد بسیار مهم است.
۴. رویارویی و رفع تضادهای ادغام (Merge Conflicts)
در این سناریو، ممکن است فیچر قبلی (مثلاً عملیات تفریق) در شاخه master ادغام شده باشد، اما شما در شاخه خود (operation-menu) به‌طور مستقل تغییراتی در همان خطوط از فایل Program.cs ایجاد کرده باشید. در این حالت، گیت‌هاب به شما هشدار می‌دهد که نمی‌تواند به‌طور خودکار ادغام را انجام دهد و با تضاد (Conflict) مواجه هستید.
۴.۱. رفع تضاد در گیت‌هاب
برای رفع تضاد به‌صورت مستقیم در محیط وب گیت‌هاب:
روی دکمه Resolve Conflicts در صفحه PR کلیک کنید.
گیت‌هاب فایل‌هایی که در آن‌ها تضاد وجود دارد را نمایش می‌دهد (مانند Program.cs).
تشخیص و انتخاب کد: در داخل فایل، گیت بخش‌های دارای تضاد را با نشانه‌های خاصی از یکدیگر جدا می‌کند:
کد بین <<<<<<< و ======= مربوط به شاخه شما (فیچر جدید) است.
کد بین ======= و >>>>>>> مربوط به شاخه مقصد (master) است.
ویرایش دستی: شما باید تصمیم بگیرید که کدام بخش از کد باید حفظ شود. در این مورد، چون کد منوی جدید جایگزین کدهای قدیمی می‌شود:
بخش‌های مربوط به کد شاخه مقصد (master) را حذف کنید.
نشانه‌های <<<<<<<, =======, و >>>>>>> را نیز حذف کنید.
تنها کد نهایی و مطلوب (شامل منوی عملیات) را باقی بگذارید.
Commit: پس از رفع تمام تضادها، دکمه Mark as Resolved و سپس Commit Merge را بزنید تا تغییرات حل‌شده ثبت شوند.
نکته: برخلاف محیط‌های توسعه مانند ویژوال استودیو که ممکن است پنجره‌های گرافیکی برای انتخاب تضادها داشته باشند، در گیت‌هاب اغلب لازم است تضادها را به صورت دستی و با دقت در کد شناسایی و رفع کنید.
۵. نهایی‌سازی و ادغام (Final Merge)
پس از رفع موفقیت‌آمیز تضادها، تیک سبز رنگی ظاهر می‌شود که نشان می‌دهد شاخه شما اکنون آماده ادغام است.
بررسی نهایی: اگر محدودیت‌هایی در مخزن وجود داشته باشد (مانند نیاز به تأییدیه بازبینان کد (Code Review))، باید منتظر بمانید تا شخص دیگری تغییرات شما را تأیید کند. در غیر این صورت، می‌توانید خودتان ادامه دهید.
Merge Pull Request: با کلیک بر روی دکمه Merge Pull Request و تأیید آن، تمام تغییرات شما به شاخه master منتقل شده و فیچر جدید به صورت رسمی بخشی از پروژه اصلی می‌گردد.
حذف شاخه: پس از ادغام موفقیت‌آمیز، بهتر است شاخه فیچر (operation-menu) را حذف کنید تا مخزن تمیز بماند.
۶. به‌روزرسانی نهایی شاخه محلی master
در نهایت، برای اینکه کامپیوتر محلی شما آخرین نسخه کد را داشته باشد:
به شاخه master محلی خود برگردید (چک‌اوت کنید).
دوباره فرآیند Fetch و Pull را تکرار کنید. اکنون master محلی شما شامل تمامی کامیت‌های ادغام‌شده (از جمله منوی عملیات) است.
گام بعدی: محافظت از شاخه (Branch Protection)
همانطور که دیدید، با استفاده از Pull Request می‌توانیم فرآیند ادغام را تحت کنترل قرار دهیم. در بخش بعدی، یاد خواهیم گرفت که چگونه با استفاده از قوانین محافظت از شاخه (Branch Protection Rules) در گیت‌هاب، محدودیت‌هایی اعمال کنیم تا ادغام مستقیم به شاخه‌هایی مانند master به‌طور کامل ممنوع شده و تنها از طریق فرآیند تأییدشده Pull Request امکان‌پذیر باشد.
برای افزودن دیدگاه خود، نیاز است ابتدا وارد حساب کاربری‌تان شوید