دریافت بازبینی یک درخواست کشش¶
درخواست pull شما ارسال شده و CI را با موفقیت پشت سر گذاشته است. اکنون آمادهٔ بررسی است.
خلاصه - فرآیند بازبینی¶
نسخهٔ کوتاه فرایند بازبینی:
- منتظر بررسی باشید.
- به بازخورد پاسخ دهید.
- در صورت درخواست تغییرات:
- روی تکمیل تغییرات درخواستی کار کنید.
- تمام تغییرات درخواستی را ارسال کنید.
- پس از ارسال تمام تغییرات درخواستی، مجدداً درخواست بازبینی دهید.
- بخش سوم را تکرار کنید تا دیگر نیازی به تغییر نباشد.
- منتظر بمانید تا درخواست ادغام شما تأیید و ادغام شود.
تبریک! شما همیناکنون به BeeWare کمک کردید!
من درخواست تغییراتم را ارسال کردم، قدم بعدی چیست؟¶
پس از ارسال درخواست برداشت خود، باید منتظر بررسی مشارکتتان باشید. فرآیند بررسی دو جنبه دارد: ارائه بازبینی و دریافت بازبینی.
بازبینی انتظارات
شما باید انتظار داشته باشید که هر کسی که ارسالهای شما را بازبینی میکند، از این دستورالعملها پیروی کند، از جمله بازبینیهای اعضای تیم اصلی. همچنین شما نیز باید هنگام بازبینی ارسالهای دیگران از این دستورالعملها پیروی کنید.
اگر احساس میکنید بازبین شما از این انتظارات منحرف میشود و در مطرح کردن موضوع بهصورت مستقیم در درخواست برداشت (pull request) احساس راحتی میکنید، میتوانید این کار را انجام دهید. اگر احساس راحتی نمیکنید، لطفاً با تیم پاسخگویی به آییننامه رفتار BeeWare تماس بگیرید. ما گزارش شما را بررسی کرده و با بازبین شما پیگیری خواهیم کرد. پیگیری انجامشده منعکسکننده اقدام گزارششده خواهد بود؛ یک تخلف جزئی ممکن است به یک بحث منجر شود، در حالی که یک تخلف عمده ممکن است به اقدامی جدیتر بینجامد.
ارائه بازخورد¶
همه میتوانند برای هر درخواست تغییر بازخورد ارائه دهند. این دستورالعملها انتظارات ما از یک بازخورد را توصیف میکنند، صرفنظر از اینکه آن بازخورد توسط یکی از اعضای تیم اصلی ارائه شود یا توسط یکی از اعضای جامعه.
یک عضو اصلی تیم همیشه باید بازبینی نهایی را انجام دهد؛ اما بازبینیهای اعضای جامعه میتوانند راهی مفید برای سادهسازی فرایند باشند – در حالت ایدهآل، بازبینی تیم اصلی پس از آنکه بازبینیهای جامعه همه مشکلات عمده را شناسایی کردند، صرفاً یک تشریفات خواهد بود.
دریافت بازبینی¶
دریافت بازبینی شامل سه مرحلهٔ اساسی است:
- بازخورد و پرسشهای اولیه
- درخواستهای تغییر
- تأیید و ادغام.
هر مرحله در زیر به تفصیل توضیح داده شده است. اگر در هر مرحله از این فرایند سؤالی داشتید، در پرسیدن تردید نکنید! ما خوشحال میشویم به شما کمک کنیم.
جدول زمانی و بازخورد اولیه¶
تیم اصلی تلاش میکند تا هر درخواست یکپارچهسازی ظرف ده روز کاری بازبینی شود. با این حال، در صورت ارسال موارد پیچیدهتر یا زمانی که بخشهایی از تیم در مرخصی هستند، ممکن است این بازه زمانی افزایش یابد.
ما معمولاً در هر درخواست ادغام، پیوستگی را با بازبینها حفظ میکنیم؛ یعنی احتمالاً در تمام فرآیند بازبینی با همان بازبین کار خواهید کرد. این بدان معناست که بازبین شما در طول فرآیند در جریان موضوع قرار خواهد داشت و شما میتوانید یاد بگیرید که از نظر زمانبندی پاسخها و سبک بازبینی چه انتظاری داشته باشید. اگر بازبین اولیه شما تشخیص دهد که تخصص لازم برای بررسی درخواستهای pull شما را ندارد، یا بداند که به دلیلی در دسترس نخواهد بود، ممکن است مسئولیت درخواست pull شما را به یکی دیگر از اعضای تیم واگذار کند.
میتوانید انتظار داشته باشید که ما به هر تبادل در یک بازهٔ زمانی متغیر ده روز کاری پاسخ دهیم. پاسخگویی به بازخوردها و پرسشها بخش ضروری فرایند بازبینی است. ما پیش از حرکت به مرحلهٔ بعدی فرایند، منتظر پاسخ شما خواهیم بود.
درخواستهای تغییر¶
در بیشتر مواقع، بازبین شما از شما میخواهد تغییراتی در درخواست ادغامتان اعمال کنید. این لزوماً نشاندهنده کیفیت کار شما نیست؛ این صرفاً بخشی از فرایند است.
اگر بازبینی اولیه نشان دهد که تعداد قابلتوجهی مشکل وجود دارد، بازبینی اول ممکن است جامع نباشد. در عوض، این بازبینی بر ارائه راهنماییهای کلی درباره کاری که لازم است انجام شود تا درخواست ادغام (pull request) به وضعیتی قابل ادغام برسد، متمرکز خواهد بود. فرایند بازبینی ممکن است شامل پرسشهایی برای روشنسازی هدف و دامنه کاری باشد که انجام شده است.
تغییرات درخواستی را اعمال کنید¶
بازبین شما نظراتش را روی درخواست برداشتن (pull request) شما ارسال میکند. این نظرات میتوانند کلی باشند، مربوط به یک فایل خاص یا مربوط به یک یا چند خط کد مشخص. گاهی شامل تغییرات پیشنهادی مستقیم هستند که میتوانید از طریق رابط کاربری گیتهاب آنها را روی درخواست برداشتن خود اعمال کنید. معمولاً این نظرات سؤالاتی هستند، درخواست توضیح بیشتر یا راهنمایی در مورد بهروزرسانیها.
علامتگذاری گفتگو بهعنوان حلشده
در بخش بحث فرایند بازخورد، هرگز نباید گفتگوی آغازشده توسط بازبین خود را بهعنوان «حلشده» علامتگذاری کنید. علامتگذاری گفتگو بهعنوان حلشده بر عهدهٔ بازبین است. آنها باید تعیین کنند که آیا مشکل شناساییشده حل شده است یا خیر.
اگر بازبینی یک مشکل سیستماتیک را نشان دهد (مثلاً ناسازگاری در نامگذاری در کد)، بازبین ممکن است همه نمونههای آن مشکل را برجسته نکند. در عوض، ممکن است چند نمونه از آن مشکل را انتخاب کرده و اشاره کند که سایر موارد نیز باید اصلاح شوند. اگر بازبینی در یک نقطه مشکلی را نشان دهد و شما فکر کنید ممکن است در جای دیگری نیز وجود داشته باشد، باید آن مشکل را در هر جایی که رخ داده اصلاح کنید. اگر مطمئن نیستید، از بازبین خود توضیح بخواهید.
تمام تغییرات درخواستی را ارسال کنید¶
پس از اینکه تمام تغییرات درخواستی را اعمال کردید، میتوانید یک بهروزرسانی را به درخواست برداشت خود ارسال کنید. این کار اجرای جدید CI را آغاز میکند؛ پس از اینکه تأیید کردید CI همچنان با موفقیت اجرا میشود، یک نظر بگذارید و درخواست بازبینی بهروزشده را مطرح کنید تا تیم اصلی بار دیگر درخواست برداشت شما را بررسی کند.
پش کنید، فورس یا ریبیس نکنید
وقتی در حین بازبینی، درخواست کش خود را بهروزرسانی میکنید، مهم است که تاریخچهٔ کامیتها را دستنخورده نگه دارید. فرقی نمیکند که فهرست کامیتها چقدر بزرگ باشد؛ وقتی درخواست کش را ادغام میکنیم، همهٔ آنها فشرده میشوند. اگر در میانهٔ بازبینی، درخواست کش خود را با force push یا rebase کنید، ممکن است زمینههای مهمی را که بازبین شما به آنها نیاز دارد، حذف کنید.
درخواست بازبینی مجدد¶
زمانی که تمام تغییرات درخواستی را در یک بازبینی مشخص برطرف کردید و CI دوباره با موفقیت اجرا شد، میتوانید از بازبین خود درخواست بازبینی مجدد کنید. اگر یک مشکل بهویژه پیچیده باشد و رفع آن بر بخش دیگری تأثیر بگذارد، میتوانید برای بخش خاصی که بهروزرسانی کردهاید، درخواست بازبینی بدهید. فرض بر این است که هر درخواست بازبینی، درخواستی برای یک بازبینی کامل است. اگر برای یک بازبینی کامل آماده نیستید، حتماً مشخص کنید که دقیقاً به دنبال چه چیزی هستید.
تأیید و ادغام درخواست کشش¶
وقتی به همه درخواستهای تغییر پاسخ دادید و آنها تکمیل شدند، درخواست کش (pull request) تأیید خواهد شد. در بیشتر موارد، پس از تأیید درخواست کش، فوراً آن را ادغام میکنیم. در برخی موارد ممکن است شرایط خاصی وجود داشته باشد، مانند وابستگی به یک درخواست کش دیگر که هنوز ادغام نشده است، که منجر به تأخیر میشود. ما این موضوع را در بخش نظرات اعلام خواهیم کرد تا از وضعیت مطلع شوید.