مقدمه
یک Pull Request یک سند ثابت و بی‌تغییر نیست، بلکه یک گفتگوی زنده و پویاست. به ندرت پیش
می‌آید که یک PR در همان تلاش اول و بدون هیچ بازخوردی تایید و ادغام شود. فرآیند بازبینی کد
تقریباً همیشه منجر به درخواست‌هایی برای اصلاح، بهبود یا تغییر در کد پیشنهادی می‌شود.
بنابراین، یک مهارت کلیدی برای هر توسعه‌دهنده‌ای، دانستن این است که چگونه پس از دریافت بازخورد،
Pull Request خود را به‌روزرسانی کند. خوشبختانه، گیت‌هاب این فرآیند را بسیار ساده و روان
کرده است. در این درس، به صورت عملی یاد می‌گیریم که چگونه به بازخوردها پاسخ داده و PR خود
را آپدیت کنیم.
چرا یک Pull Request نیاز به آپدیت دارد؟
دلایل متعددی می‌تواند منجر به نیاز برای اعمال تغییرات جدید در یک PR شود:
- بازخورد بازبین‌ها (Reviewer Feedback): این رایج‌ترین دلیل است. همکاران شما ممکن است
یک باگ پیدا کنند، یک روش بهتر برای پیاده‌سازی پیشنهاد دهند، یا از شما بخواهند که تست‌های
بیشتری به کد اضافه کنید.
- تغییر در برنچ اصلی (main): ممکن است در حین کار شما روی برنچ‌تان، کدهای جدیدی در برنچ
main ادغام شده باشد. برای جلوگیری از تداخل (Conflict) در آینده، بهتر است این
تغییرات جدید را با برنچ خودتان ادغام کنید تا PR شما به‌روز بماند.
- شکستن تست‌های خودکار (Failing Checks): اگر پروژه شما از GitHub Actions برای
اجرای خودکار تست‌ها استفاده می‌کند، ممکن است تغییرات شما باعث رد شدن یکی از تست‌ها شود و شما
باید آن را برطرف کنید.
فرآیند آپدیت کردن یک PR
خبر خوب این است که برای آپدیت کردن یک PR، نیازی به انجام هیچ کار خاصی در رابط کاربری
گیت‌هاب ندارید. هر کامیت جدیدی که شما به برنچ مربوط به آن PR پوش کنید، به طور خودکار به
آن Pull Request اضافه خواهد شد.
فرآیند گام به گام به این صورت است:
- بررسی بازخوردها: ابتدا کامنت‌ها و بازخوردهای داده شده در صفحه Pull Request را
با دقت مطالعه کنید.
- بازگشت به برنچ محلی: مطمئن شوید که در ترمینال خود روی همان برنچی هستید که PR
از آن ساخته شده است.
git checkout feature/user-profile
- اعمال تغییرات: تغییرات درخواستی را در فایل‌های مربوطه در محیط کدنویسی خود اعمال کنید.
برای مثال، یک باگ را رفع کرده یا یک تابع را بازنویسی می‌کنید.
- کامیت کردن تغییرات جدید: تغییرات جدید خود را مانند همیشه، کامیت کنید. بهتر است پیام
کامیت شما به بازخورد دریافت شده اشاره داشته باشد.
git add .
git commit -m "Fix: Address reviewer comments on validation logic"
- پوش کردن کامیت جدید: کامیت (یا کامیت‌های) جدید را به همان برنچ در سرور ریموت
push کنید.
git push origin feature/user-profile
به محض اینکه این push با موفقیت انجام شود، اگر به صفحه Pull Request در گیت‌هاب
برگردید و آن را رفرش کنید، خواهید دید که کامیت جدید شما به لیست کامیت‌های PR اضافه شده و
در تب Files Changed نیز قابل مشاهده است. همچنین یک رویداد جدید در تایم‌لاین گفتگو ثبت
می‌شود. حالا بازبین‌های شما می‌توانند تغییرات جدید را بررسی کنند.
یک نکته مهم: افزودن کامیت در مقابل بازنویسی تاریخچه
روش توصیه‌شده و استاندارد برای آپدیت یک PR، افزودن کامیت‌های جدید است. این کار کل تاریخچه
گفتگو و فرآیند بهبود کد را شفاف نگه می‌دارد.
با این حال، برخی توسعه‌دهندگان پیشرفته‌تر ترجیح می‌دهند به جای افزودن کامیت‌های اصلاحی (مانند
"fix typo" یا "address comments")، با استفاده از rebase تعاملی، تاریخچه برنچ خود را تمیز
کرده و تغییرات جدید را مستقیماً در کامیت‌های قبلی ادغام کنند و سپس با force push
(git push --force) برنچ ریموت را بازنویسی نمایند.
این کار می‌تواند بسیار گیج‌کننده باشد، زیرا تاریخچه‌ای که بازبین‌ها قبلاً بررسی
کرده‌اند را تغییر می‌دهد و ممکن است کامنت‌های آن‌ها را بی‌محتوا کند. به عنوان یک قانون کلی، تا
زمانی که به طور کامل با تیم خود هماهنگ نکرده‌اید، از بازنویسی تاریخچه یک Pull
Request فعال خودداری کنید و به جای آن، کامیت‌های جدید اضافه کنید.