تایید کردن / اپروو کردن: اپرووال و بررسی کد در Git چیست

اپروو پول ریکویست چیست

اپروو (approval) — یک بررسی مثبت بر روی پول ریکویست است به معنی اینکه بازبین کد را بررسی کرده، مشکل بحرانی پیدا نکرده و تغییرات را آماده ادغام می‌داند. در رابط GitHub این دکمه سبز «Approve» در صفحه PR است. پس از اپروو، نویسنده (یا هر شرکت‌کننده دارای دسترسی نوشتن) می‌تواند merge را انجام دهد.

فرآیند اپروو بخشی از Branch Protection Rules است. صاحبان رپوزیتوری شرایط الزامی را تنظیم می‌کنند: حداقل تعداد اپروو (مثلاً 1 یا 2)، کسانی که می‌توانند اپروو کنند (صاحبان کد، اعضای تیم) و اینکه PR باید پس از تغییرات مجدداً اپروو شود یا خیر (Dismiss stale reviews). بدون تنظیم قوانین، اپروو یک مرحله اختیاری است، اما در تیم‌های حرفه‌ای الزامی است.

GitLab از مکانیسم مشابهی به نام Approval Rules استفاده می‌کند. در GitLab می‌توان تنظیم کرد که چقدر اپروو از گروه‌های مختلف (مثلاً 2 از توسعه‌دهندگان بکاند و 1 از DevOps) مورد نیاز است. پس از دریافت تمامی اپرووهای الزامی، PR به‌طور خودکار برای merge با شرط سبز بودن CI/CD pipeline باز می‌شود.

انواع بررسی: Approve، Request Changes، Comment

در GitHub و GitLab سه نوع بررسی وجود دارد که بازبین می‌تواند بر روی پول ریکویست بگذارد. هر نوع وضعیت و پیامد مختلفی برای فرآیند ادغام دارد. Approve — سبز، Request Changes — قرمز، Comment — خاکستری خنثی. انتخاب نوع بستگی به کیفیت کد و آمادگی تغییرات برای پذیرش دارد.

Approve — بازبین تایید می‌کند: کد به‌درستی نوشته شده، مطابق استانداردهاست، حاوی خطاهای آشکار نیست و قابل ادغام است. Approve به معنی ایدئال بودن کد نیست — فقط اینکه به قدر کافی برای تولید خوب است. اگر نظرات کوچکی وجود دارد (سبک، نام‌گذاری)، می‌توان آنها را بدون بلوک کردن PR به عنوان نظر بگذاشت.

Request Changes — بازبین مشکلاتی را پیدا می‌کند که باید قبل از merge برطرف شوند: خطاهای منطقی، آسیب‌پذیری، نقض معماری، نبود تست‌ها. پس از Request Changes، PR بلوک می‌شود و برای بازکرایی به اپروو مجدد از همان بازبین نیاز است (اگر گزینه Dismiss stale reviews برای commit‌های جدید فعال شده باشد).

• Approve — کد آماده ادغام است، پس از گذراندن CI قابل merge است.
• Request Changes — اصلاحات الزامی، PR تا بررسی مجدد بلوک شده است.
• Comment — نظر یا پیشنهاد کلی بدون بلوک کردن PR.

تنظیم قوانین اپروو در رپوزیتوری

Branch Protection Rules — مکانیسمی در GitHub برای کنترل کیفیت ادغام‌هاست. در Settings → Branches برای هر شاخه محافیظت‌شده (main، develop، release/*) تنظیم می‌شود. پارامترهای اصلی: تعداد اپرووهای الزامی، صاحبان کد (CODEOWNERS)، بررسی الزامی CI/CD و ممنوعیت push بدون PR.

پارامتر Dismiss stale pull request approvals — در صورت اضافه شدن commit جدید به PR، اپرووها را به‌طور خودکار لغو می‌کند. این تضمین می‌کند که بازبین‌ها دقیقاً همان نسخه کدی را که ادغام می‌شود، اپروو می‌کنند. بدون این تنظیم، نویسنده می‌تواند پس از اپروو کد جدیدی اضافه کند و بدون بررسی مجدد وارد main شود.

CODEOWNERS — فایلی در ریشه رپوزیتوری است که افراد مسئول دیرکتوری‌های مختلف را تعیین می‌کند. اگر PR به فایل‌هایی متعلق به صاحب کد دست زد، اپروو آ الزامی می‌شود. CODEOWNERS مناطق مسئولیت را تقسیم می‌کند: توسعه‌دهنده iOS مسئول فایل‌های Swift، DevOps مسئول پیکربندی‌های Docker، آزمایشگران مسئول سناریوهای آزمایش.

# فایل CODEOWNERS نمونه در ریشه رپوزیتوری

# توسعه‌دهندگان iOS صاحب کد Swift هستند
*.swift @team/ios-developers

# DevOps صاحب پیکربندی CI/CD است
.github/workflows/* @devops-team

# مهندسان QA تست‌ها را بررسی می‌کنند
**/tests/* @qa-engineers

# صاحبان پیش‌فرض برای سایر موارد
* @tech-leads

بررسی کد قبل از اپروو: چه چیزی را بررسی کنیم

Code review قبل از اپروو — بررسی سیستماتیک کد است، نه نگاهی سطحی به diff. یک بررسی کیفی شامل بررسی معماری، منطق، سبک، تست‌ها و امنیت است. بدون این بررسی، اپروو به یک شکلیات تبدیل می‌شود و نه ابزاری برای کنترل کیفیت.

آنچه در اولین مرحله بررسی می‌شود: منطق تغییرات — آیا کد مسئله را حل می‌کند، عوارض جانبی ندارد، موارد حدودی به‌درستی مدیریت شده اند. تست‌ها — آیا تست‌های جدید همه سناریوها را پوشش می‌دهند، آیا تست‌های موجود پس از تغییرات پاس می‌شوند. امنیت — آیا SQL-انجکشن، XSS، نشت داده‌های حساس وجود ندارد.

آنچه نباید مورد بررسی قرار گیرد: سبک فرمت‌بندی (برای این کار linter و formatter وجود دارد)، تصمیمات معماری که از قبل گرفته شده اند (آنها قبل از نوشتن کد بحث می‌شوند). اگر بررسی بیش از 400 خط باشد یا بیش از یک ساعت طول بکشد — این نشانه آن است که وظیفه بسیار بزرگ است و نیاز به تجزیه دارد. بهترین روش برای بررسی — بردار (پارچه) های 200–400 خطی در طول 24 ساعت پس از ایجاد PR.

• منطق — صحت حل مسئله، مدیریت خطا، موارد حدودی.
• تست‌ها — پوشش سناریوهای جدید، گذراندن تست‌های موجود، نبود flaky-تست.
• امنیت — نبود انجکشن، اسکیپ خروجی، دسترسی به داده‌ها.
• عملکرد — کارایی الگوریتم‌ها، درخواست‌های اضافی، نشت حافظه.
• مستندات — آیا مستندات به‌روز شده، آیا در بخش‌های پیچیده توضیحات قابل فهم است.

جریان کار با اپروو در تیم

جریان کار معمولی با اپروو در یک تیم 5–10 نفره به این شکل است: توسعه‌دهنده PR ایجاد می‌کند، بازبین‌ها را تعیین می‌کند (معمولاً 1–2 نفر از تیم یا صاحبان کد)، CI/CD بررسی‌های خودکار را آغاز می‌کند. پس از دریافت همه اپرووهای الزامی و سبز بودن CI، نویسنده merge را انجام می‌دهد. زمان از ایجاد PR تا merge به طور متوسط بستگی به پیچیدگی از 2 ساعت تا 2 روز است.

GitHub Actions امکان اتوماتیک merge پس از اپروو را فراهم می‌کند. اگر قوانین شاخه تنظیم شده باشند، GitHub خود merge را تا برآورده شدن تمامی شرایط بلوک می‌کند. برخی تیم‌ها از bors-ng یا Mergify — ربات‌هایی که پس از دریافت همه اپرووها و پاس شدن CI به‌طور خودکار PR را ادغام می‌کنند استفاده می‌کنند. این فرآیند را سریع می‌کند و عامل انسانی را در زمان merge حذف می‌کند.

رویکرد مدرن — trunk-based development با شاخه‌های کوتاه عمر. در این جریان کار، اپروو باید طی چند ساعت دریافت شود، در غیر این صورت وظیفه منسوخی حساب می‌شود و نیاز به همگام‌سازی مجدد با main دارد. تیم‌هایی با فرهنگ بالای بررسی به زمان اپروو نه بیش از 4 ساعت کاری تلاش می‌کنند.

اشتباهات در اپروو و چگونگی جلوگیری از آنها

رایج‌ترین خطا — اپروو شکلی بدون بررسی واقعی کد. وقتی PR بزرگ است یا مهل نزدیک است، بازبین می‌تواند Approve را بدون ورود به تغییرات بزند. این کل فرآیند بررسی کد را بی‌ارزش می‌کند. راه حل: تعیین حد حجم PR (حداکثر 400 خط) و استفاده از ابزارهای تحلیل کد (SonarQube، CodeClimate) برای بررسی خودکار.

خطای دوم — اپروو شدیدالحد سختگیرانه. انتظار کد ایدئال توسعه را بلوک می‌کند. بازبین‌ها گاهی تصحیح نظرات سبکی را که بر کیفیت تاثیر ندارند طلب می‌کنند. راه حل: جداسازی واضح نظرات الزامی (بلوکانه) و اختیاری (نظرات). GitHub امکان تشخیص واضح بلوکانه بودن یا نبودن نظر را فراهم می‌کند.

خطای سوم — اپروو بدون بررسی CI/CD. حتی اگر کد درست به نظر برسد، ممکن است کامپایل نشود یا در تست‌ها مشکل داشته باشد. Branch Protection پیکربندی شده به‌طور خودکار merge را در صورت قرمز بودن CI بلوک می‌کند، اما برخی تیم‌ها این محافظت را برای سرعت خاموش می‌کنند. راه حل: همیشه وضعیت CI را قبل از اپروو بررسی کنید و PR را با pipeline قرمز هرگز تایید نکنید.

• اپروو شکلی — نبود بررسی واقعی کد. راه حل: حد حجم 400 خط برای PR.
• سختگیری افراطی — بلوک به دلیل نظرات سبکی. راه حل: تقسیم به blocking و optional.
• نادیده گرفتن CI — اپروو در وضعیت pipeline قرمز. راه حل: همیشه وضعیت بررسی‌ها را چک کنید.
• تعیین نویسنده — اپروو از نویسنده PR. راه حل: تنظیم Branch Protection علیه نویسنده.