تصور کنید کدی را نوشته‌اید و اکنون زمان آن رسیده که دستاورد خود را با تمام اعضای تیم به اشتراک بگذارید تا پس از تایید نهایی، بخشی از نسخه اصلی نرم‌افزار شود. در محیط‌های شرکتی و پروژه‌های منبع‌باز (Open Source)، شما هرگز کدهای خود را مستقیماً به شاخه اصلی نمی‌فرستید؛ بلکه از ابزاری جادویی به نام Pull Request یا به اختصار PR استفاده می‌کنید.

اینجاست که همکاری واقعی معنا پیدا می‌کند و کدهای شما توسط متخصصان دیگر بررسی و صیقل داده می‌شود.

در این درس، شما با هنر «بررسی کد» (Code Review) آشنا می‌شوید و یاد می‌گیرید که چگونه با فورک کردن پروژه‌ها، سهمی در توسعه نرم‌افزارهای بزرگ داشته باشید.

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

مفهوم فورک (Fork)

فورک کردن به معنای ایجاد یک کپی کاملاً شخصی از مخزن (Repository) دیگران در حساب کاربری گیت‌هاب خودتان است. این قابلیت به شما اجازه می‌دهد تا بدون نگرانی از خراب شدن پروژه اصلی، کدهای آن را آزمایش کنید یا ویژگی‌های جدیدی به آن بیفزایید.

چرا به فورک نیاز داریم؟

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

تفاوت کلیدی فورک با یک کپی ساده: وقتی پروژه‌ای را فورک می‌کنید، گیت‌هاب رابطه‌ای هوشمند میان نسخه شما و نسخه اصلی برقرار نگه می‌دارد. این پیوند به شما کمک می‌کند تا نه‌تنها از آخرین تغییرات نسخه اصلی باخبر شوید، بلکه بتوانید کدهای اصلاح‌شده خود را از طریق یک درخواست رسمی (Pull Request) برای صاحبان پروژه اصلی بفرستید تا در صورت تأیید، زحمات شما بخشی از پروژه جهانی شود

کلون کردن (Clone) مخزن

کلون کردن به معنای انتقال یک نسخه کامل و زنده از پروژه از سرورهای گیت‌هاب به حافظه کامپیوتر شماست. برخلاف دانلود معمولی که فقط فایل‌های نهایی را به شما می‌دهد، با کلون کردن شما تمام تاریخچه تغییرات، شاخه‌ها و کامیت‌های قبلی را نیز به سیستم محلی خود می‌آورید. 

این کار محیطی امن و محلی (Sandbox) برای شما ایجاد می‌کند تا بدون نگرانی از آسیب زدن به نسخه اصلی، کدهای جدید را آزمایش و ویرایش کنید.

نحوه اجرای دستور کلون

برای شروع کار روی پروژه‌ای که قبلاً فورک کرده‌اید، باید آدرس URL آن را از گیت‌هاب کپی کرده و در ترمینال سیستم خود از دستور زیر استفاده کنید:

 git clone <URL-Github>

پس از اجرای این دستور، گیت یک پوشه جدید در سیستم شما می‌سازد و تمام فایل‌ها و پوشه .git (که حاوی تاریخچه پروژه است) را در آن قرار می‌دهد. از این لحظه به بعد، مخزن محلی شما آماده است تا هر تغییری را که مایلید در آن ثبت کنید.
یک یادآوری مهم: همیشه بعد از اتمام عملیات کلون، با استفاده از دستور cd وارد پوشه پروژه شوید؛ زیرا دستورات گیت تنها زمانی کار می‌کنند که شما دقیقاً داخل پوشه مخزن باشید

ثبت Pull Request (PR) اصولی

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

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

نگارش توضیحات شفاف و استاندارد

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

  • عنوان گویا: به جای عناوین مبهم مانند "Update"، از عباراتی استفاده کنید که نشان‌دهنده عملکرد کد باشد، مثل "رفع خطای ورود در نسخه موبایل".
  • تشریح تغییرات: در بخش توضیحات، به وضوح بنویسید که چه کارهایی انجام شده، چرا این روش را انتخاب کرده‌اید و چه بخش‌هایی هنوز نیاز به کار دارند.
  • پیوند به گفتگوها: اگر این کد مربوط به یک تسک خاص یا گزارش خطا (Issue) است، حتماً به آن لینک بدهید تا پیش‌زمینه کار برای بررسی‌کننده مشخص باشد.

زمان طلایی برای باز کردن درخواست

منتظر نمانید تا تمام کارهای شما ۱۰۰ درصد تمام شود و بعد PR بزنید. یکی از بهترین استراتژی‌ها در تیم‌های حرفه‌ای، باز کردن درخواست ادغام در همان ابتدای شروع کار است.

این کار به تیم دید کاملی از مسیری که طی می‌کنید می‌دهد و اجازه می‌دهد بازخوردهای اولیه را پیش از صرف زمان زیاد روی یک مسیر اشتباه دریافت کنید. هر زمان که کامیت جدیدی روی شاخه خود بزنید و آن را Push کنید، لیست تغییرات در PR به صورت خودکار به‌روزرسانی می‌شود.

فرآیند بررسی کد (Code Review)

ررسی کد یا Code Review، مرحله‌ی تضمین کیفیت و یادگیری جمعی در تیم‌های نرم‌افزاری است. پس از اینکه Pull Request خود را ثبت کردید، کدهای شما زیر ذره‌بین هم‌تیمی‌ها یا مدیر فنی پروژه قرار می‌گیرد. این مرحله صرفاً برای یافتن اشتباهات نیست؛ بلکه فرصتی است تا دانش فنی میان اعضای تیم جابه‌جا شود و همه مطمئن شوند که کدهای جدید با استانداردهای پروژه همخوانی دارند.

چرا بازبینی کد برای پروژه حیاتی است؟

این فرآیند از ورود کدهای آسیب‌پذیر یا غیراستاندارد به نسخه اصلی جلوگیری می‌کند. در یک بررسی کد اصولی، هم‌تیمی‌های شما به دنبال پاسخ این سوالات هستند:

  • آیا کد به درستی کار می‌کند و هدف اصلی تسک را برآورده کرده است؟
  • آیا کد خوانا است و دیگران هم می‌توانند آن را در آینده ویرایش کنند؟
  • آیا روش بهتری برای پیاده‌سازی این بخش وجود داشته است؟

تعامل هوشمندانه در گیت‌هاب

در محیط گیت‌هاب، بررسی‌کنندگان می‌توانند مستقیماً روی هر خط از کد شما کامنت بگذارند. شما معمولاً با سه نوع واکنش روبرو می‌شوید:

  • Comment: سؤالی پرسیده شده یا پیشنهادی برای بهبود ارائه شده که لزوماً مانع ادغام کد نمی‌شود. 
  • Request Changes: کدهای شما نیاز به اصلاحات دارد و تا زمانی که آن‌ها را انجام ندهید، اجازه ادغام داده نخواهد شد. 
  • Approve: کد شما تایید شده و آماده ترکیب با شاخه اصلی است. در این حالت معمولاً از اصطلاح LGTM (مخفف Looks Good To Me) استفاده می‌شود.

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

تعامل و اعمال بازخوردها

دریافت بازخورد در مرحله بررسی کد، به معنای نقص کار شما نیست؛ بلکه یک گفتگوی فنی برای رسیدن به بالاترین کیفیت ممکن است. وقتی هم‌تیمی‌ها یا مدیر فنی نظرات خود را روی Pull Request شما ثبت می‌کنند، نوبت به تعامل هوشمندانه و اعمال اصلاحات می‌رسد.

چگونه به نظرات پاسخ دهید؟

تعامل در گیت‌هاب تنها به تغییر کد محدود نمی‌شود. اگر با پیشنهادی موافق هستید، می‌توانید با یک ایموجی یا پیامی کوتاه آن را تأیید کنید. اما اگر دلیلی فنی برای روش خود دارید، با کمال احترام و به صورت شفاف، استدلال خود را در پاسخ به کامنت بنویسید. این گفتگوها باعث می‌شود تا تمام تیم از تصمیمات فنی پروژه آگاه شوند.

به‌روزرسانی خودکار Pull Request

بزرگ‌ترین مزیت گیت‌هاب این است که برای اعمال اصلاحات، نیازی به بستن درخواست فعلی و باز کردن یک PR جدید ندارید. کافی است مراحل زیر را دنبال کنید:

  1. در سیستم محلی خود، تغییرات درخواستی را روی همان شاخه اعمال کنید. 
  2. تغییرات را کامیت کنی. 
  3. کدها را دوباره به گیت‌هاب push کنید.

به محض انجام این کار، Pull Request شما به صورت خودکار به‌روزرسانی شده و لیست تغییرات جدید (Commits) در انتهای گفتگوها ظاهر می‌شود تا بررسی‌کننده بتواند اصلاحات را مشاهده کند.

مرحله نهایی: ادغام و پاکسازی

پس از اینکه تمام نظرات اعمال شد و علامت تایید (Approve) را دریافت کردید، زمان ادغام فرا می‌رسد. با کلیک روی دکمه Merge pull request، کدهای شما با شاخه اصلی پروژه ترکیب می‌شوند. در نهایت، برای تمیز نگه داشتن مخزن، توصیه می‌شود شاخه‌ای که روی آن کار می‌کردید را حذف کنید، زیرا کدهای آن اکنون بخشی از بدنه اصلی پروژه شده است.