وبلاگ / راهنمای مسیر یادگیری و فناوری
راهنمای مسیر یادگیری و فناوری

آموزش GitHub Copilot Code Review؛ بازبینی امن Pull Request و مدیریت پیشنهادها

GitHub Copilot Code Review را برای Pull Request راه‌اندازی کنید، سطح بررسی و دستورهای Repository را تنظیم کنید و پیشنهادهای AI را پیش از Merge با تست و تصمیم انسانی اعتبارسنجی کنید.

· ۲۴ بازدید

بازبینی کد با می‌تواند خطاهای واضح، ریسک‌های امنیتی و ناسازگاری‌های سبک را پیش از Merge پیدا کند؛ اما ارزش واقعی آن زمانی ظاهر می‌شود که Review هوش مصنوعی داخل فرایند مهندسی تیم قرار بگیرد، نه اینکه جای تصمیم Reviewer انسانی را بگیرد.

در این راهنما یک گردش‌کار عملی می‌سازیم: Copilot را برای درخواست می‌کنیم، شدت یافته‌ها را می‌خوانیم، دستورهای Repository را به آن می‌دهیم، پیشنهادها را جداگانه بررسی می‌کنیم و تنها بعد از اجرای تست و تأیید انسان Merge را انجام می‌دهیم.

چیست؟

Copilot تغییرات کد را در .com، CLI، VS Code، Visual Studio، JetBrains، Xcode و Mobile بررسی می‌کند. خروجی آن معمولاً مجموعه‌ای از Commentهای متصل به خطوط کد است و هر Comment می‌تواند توضیح، شدت و در صورت امکان Suggested Change داشته باشد.

این قابلیت Reviewer مستقل و مسئولیت‌پذیر نیست. Copilot زمینه کسب‌وکار، تصمیم معماری و پیامد عملیاتی را فقط در حد اطلاعاتی که Repository و دستورها در اختیارش می‌گذارند می‌بیند. بنابراین خروجی آن باید مثل یک ورودی فنی بررسی شود.

وظیفهCopilot Reviewer انسانی
یافتن الگوهای خطاسریع و تکرارپذیرتأیید ارتباط با سناریوی واقعی
بررسی امنیتهشدار و پیشنهاد اولیهتحلیل تهدید و سطح دسترسی
معماریوابسته به Context موجودتطبیق با تصمیم‌های سیستم
Mergeارزیابی آمادگی یا Approval پیکربندی‌شدهمالک تصمیم نهایی

پیش‌نیازها و دسترسی‌ها

برای استفاده روی .com باید قابلیت در Policy سازمان یا Repository فعال باشد. این ویژگی در طرح‌های پولی Copilot ارائه می‌شود و سازمان‌های Business یا Enterprise می‌توانند در شرایط مشخص آن را برای اعضای بدون مجوز فردی نیز فعال کنند. قبل از فعال‌سازی، مصرف اعتبار و Policyهای سازمان را بررسی کنید.

  • Repository باید روی میزبانی شود و قابل بازبینی داشته باشد.
  • برای CLI، ابزار gh باید نصب و احراز هویت شده باشد.
  • برای Review محلی، نسخه و افزونه IDE باید از قابلیت پشتیبانی کنند.
  • Branch protection، Required checks و Reviewerهای انسانی را مستقل نگه دارید.
  • Secretها، فایل‌های تولیدی و مسیرهای خارج از Scope را با Policy مناسب محافظت کنید.

درخواست Review روی

در .com وارد شوید و در بخش Reviewers کنار Copilot گزینه Request را بزنید. Copilot تغییرات را تحلیل و Commentهای خود را روی Diff ثبت می‌کند. در CLI نیز هنگام ساخت می‌توانید از فرمان gh pr create --reviewer @copilot استفاده کنید.

برای موجود، فرمان gh pr edit PR-NUMBER --add-reviewer @copilot Reviewer را اضافه می‌کند. عدد را دقیق وارد کنید و پیش از اجرا Repository و Branch جاری را با gh repo view و git status کنترل کنید.

Review خودکار یا دستی؟

Review دستی برای شروع امن‌تر است، چون تیم می‌تواند Scope و هزینه را روی چند آزمایشی بسنجد. بعد از تثبیت دستورها، می‌توان Review خودکار و گزینه بررسی Pushهای جدید را در Ruleset فعال کرد. فعال‌سازی خودکار نباید Required checks موجود را حذف کند.

Lite یا Balanced را چطور انتخاب کنیم؟

Lite برای بازخورد هدفمند و کم‌هزینه درباره اشکال‌های واضح مناسب است. Balanced تحلیل عمیق‌تری برای منطق پیچیده، امنیت و تغییرات میان سرویس‌ها انجام می‌دهد. سطح بررسی را با ریسک هماهنگ کنید؛ تغییر احراز هویت و پرداخت به بررسی عمیق‌تر از اصلاح متن نیاز دارد.

شدت Commentها را درست تفسیر کنید

Copilot یافته‌ها را با شدت High، Medium یا Low اولویت‌بندی می‌کند. شدت یک راهنمای صف‌بندی است، نه حقیقت قطعی. یک Comment با شدت Low ممکن است در مسیر پرترافیک مهم باشد و یک هشدار High نیز ممکن است به‌دلیل Context ناقص، مثبت کاذب باشد.

  1. ابتدا Comment را به کد و سناریوی پذیرش مرتبط کنید.
  2. مسیر اجرا و ورودی‌ای را که خطا را فعال می‌کند پیدا کنید.
  3. در صورت امکان یک Test شکست‌خورده بسازید.
  4. پیشنهاد Copilot را به‌صورت Diff مستقل بخوانید.
  5. پس از تغییر، Test هدفمند و مجموعه Regression را اجرا کنید.
  6. دلیل پذیرش یا رد را برای Reviewer بعدی ثبت کنید.

Suggested Change را کورکورانه Apply نکنید

Copilot می‌تواند تغییر پیشنهادی را با چند کلیک اعمال کند و برای پیشنهاد پذیرفته‌شده پیام Commit هوشمند بسازد. سرعت Apply نباید مرحله فهم تغییر را حذف کند. پیش از Commit، ورودی نامعتبر، خطای شبکه، مقدار Null، هم‌زمانی و مسیر Rollback را بررسی کنید.

وقتی گزینه Fix with Copilot در دسترس است، Cloud Agent می‌تواند اصلاح را روی همان یا جداگانه پیاده کند. برای تغییر پرریسک، شاخه یا PR جداگانه امکان مقایسه، بازگشت و Approval روشن‌تری می‌دهد.

نوع پیشنهادآزمون لازمتصمیم Merge
رفع Null یا ExceptionTest ورودی مرزیپس از تأیید رفتار خطا
بهینه‌سازی QueryPlan و Benchmarkپس از کنترل نتیجه و بار
تغییر امنیتیTest مجوز و Threat reviewReviewer امنیتی
RefactorRegression و Diff APIبدون تغییر قرارداد عمومی
Dependency جدیدمنبع، مجوز و آسیب‌پذیریپس از تأیید زنجیره تأمین

دستورهای Repository کیفیت Review را بهتر می‌کنند

فایل .github/copilot-instructions.md برای قواعد سراسری Repository مناسب است. در آن معیارهایی بنویسید که قابل بررسی باشند: قراردادهای API، روش مدیریت خطا، نیاز به تست، ممنوعیت ثبت Secret و قواعد سازگاری با نسخه‌های قبلی.

برای Context عمومی Agent می‌توانید از AGENTS.md در ریشه استفاده کنید و برای مسیرهای خاص از فایل‌های .github/instructions/**/*.instructions.md بهره ببرید. دستورها باید کوتاه، بدون تناقض و نزدیک به معیار پذیرش باشند.

هنگام Review، تغییر قرارداد عمومی API، دسترسی بدون Authorization، Log شدن داده حساس، Query بدون Cancellation و تغییر Schema بدون Migration را گزارش کن. برای هر یافته مسیر فایل، سناریوی شکست و Test پیشنهادی ارائه بده. هیچ تغییر را خودکار Merge نکن.

دستورهای Copilot از Head branch خوانده می‌شوند. این نکته مهم است: نویسنده می‌تواند همان دستورهایی را تغییر دهد که Review بر اساس آن‌ها انجام می‌شود. تغییر فایل‌های Instruction را جداگانه در Diff بررسی و برای آن‌ها Code Owner تعیین کنید.

Re-review و بسته‌شدن خودکار Commentها

پس از Push جدید، اگر Review خودکار برای Pushها فعال نباشد باید Re-review را دستی درخواست کنید. در به‌روزرسانی‌های جدید، Copilot می‌تواند Commentهایی را که تغییر بعدی واقعاً برطرف کرده است Resolve کند؛ موارد حل‌نشده باز می‌مانند.

این رفتار صف Review را تمیزتر می‌کند، اما Resolve شدن Comment اثبات صحت نیست. Diff میان Commit قبلی و جدید، Test مرتبط و علت رفع خطا را بررسی کنید. اگر اصلاح فقط نشانه را پوشانده و ریشه مشکل باقی مانده باشد، Conversation را دوباره باز کنید.

Approval هوش مصنوعی را با احتیاط فعال کنید

در حالت پیش‌فرض، Review به‌شکل Comment ثبت می‌شود و Required approval را برآورده نمی‌کند. امکان Approval از سوی Copilot را به‌صورت Preview و با تنظیم مدیریتی ارائه می‌کند. اگر آن را فعال می‌کنید، مسیرهای حساس را مستثنا و حداقل یک Approval انسانی را حفظ کنید.

برای فایل‌های احراز هویت، پرداخت، Infrastructure، Migration و تنظیمات امنیتی، Code Owner انسانی تعریف کنید. Required checks باید Build، Unit Test، Integration Test، SAST و Secret scanning متناسب با پروژه را پوشش دهند.

MCP، Skill و محیط اجرای Review

Copilot می‌تواند از Agent Skillها و MCP Serverهای پیکربندی‌شده استفاده کند. این اتصال Context مفیدتری مانند Issue یا مستندات داخلی می‌دهد، اما سطح دسترسی را هم گسترش می‌دهد. فقط Serverهای ضروری را فعال و Scope هر Token را محدود کنید.

Review agent در محیط موقت اجرا می‌شود و می‌توان آن را با Workflow اختصاصی .github/workflows/copilot-code-review.yml آماده کرد. نصب ابزارها باید نسخه ثابت، منبع معتبر و حداقل مجوز داشته باشد. دسترسی شبکه را با Firewall به دامنه‌های لازم محدود کنید.

گردش‌کار پیشنهادی از PR تا Merge

  1. کوچک با توضیح مسئله، Scope و معیار پذیرش بسازید.
  2. Build و Testهای مستقل را پیش از Review اجرا کنید.
  3. Copilot را با سطح متناسب با ریسک درخواست کنید.
  4. Commentها را بر اساس شدت و مسیر اجرایی دسته‌بندی کنید.
  5. برای یافته معتبر ابتدا Test بازتولیدکننده بنویسید.
  6. Suggested Change را پس از خواندن Diff اعمال یا دستی بازنویسی کنید.
  7. Re-review بگیرید و Commentهای Resolve‌شده را با Test تطبیق دهید.
  8. Reviewer انسانی، Checkها و Code Ownerها را کامل کنید.
  9. تنها پس از سبز بودن معیارها Merge کنید و امکان Rollback را نگه دارید.

اگر تیم شما تازه فرایند PR را استاندارد می‌کند، مقاله بازبینی Pull Request با گیت‌های انسانی چارچوب تصمیم‌گیری را توضیح می‌دهد. برای کنترل ابزارهای متصل نیز راهنمای MCP Server امن را ببینید.

اشتباه‌های رایج

  • Merge بر اساس Approval ربات: مسئولیت تصمیم و Context کسب‌وکار مبهم می‌شود.
  • Apply همه پیشنهادها با هم: پیدا کردن علت Regression دشوار می‌شود.
  • دستورهای کلی مثل «کد خوب باشد»: معیار قابل آزمون تولید نمی‌کند.
  • اعتماد به Severity بدون بازتولید: اولویت واقعی پروژه نادیده می‌ماند.
  • فعال‌کردن MCP پرقدرت: Review به داده یا ابزار بیش از نیاز دسترسی می‌گیرد.
  • نادیده گرفتن Head branch: تغییر Instruction در همان PR می‌تواند جهت Review را عوض کند.

جمع‌بندی

وقتی مفید است که به‌عنوان Reviewer کمکی در کنار تست، Ruleset و انسان قرار بگیرد. Commentهای شدت‌دار، Suggested Change، Re-review و Resolve خودکار سرعت حلقه بازخورد را بالا می‌برند، اما هیچ‌کدام جای مالکیت فنی را نمی‌گیرند.

با Review دستی روی چند کوچک شروع کنید، Instructionهای قابل آزمون بنویسید و برای هر پیشنهاد معتبر Test بسازید. سپس Review خودکار را فقط در Repositoryهایی فعال کنید که Branch protection و مسیر تصمیم انسانی آن‌ها روشن است.

امروز یک کم‌ریسک انتخاب کنید، Copilot را Reviewer بگذارید و هر Comment را با سه سؤال بسنجید: سناریوی شکست چیست، چه Testی آن را ثابت می‌کند و چه کسی مسئول تصمیم Merge است؟

منابع رسمی