GitHub Copilot app چیست؟ آموزش نصب و اجرای امن Agentهای موازی روی پروژه

مدیریت چند Agent کدنویسی فقط به ارسال چند Prompt خلاصه نمی‌شود. هر کار باید Context، شاخه، فایل‌های درحال تغییر و مسیر Review مشخصی داشته باشد؛ وگرنه دو Agent می‌توانند روی یک Working Tree تداخل ایجاد کنند یا تغییری بدون آزمون وارد شاخه اصلی شود. GitHub Copilot app برای مدیریت همین Workflow در یک برنامه دسکتاپ طراحی شده است.

این برنامه روی GitHub Copilot CLI ساخته شده، اما به‌جای محدودکردن کاربر به ترمینال، نشست‌های Agent، Repositoryها، Issueها، Pull Requestها، Diff و وضعیت CI را در یک رابط جمع می‌کند. در این راهنما برنامه را نصب می‌کنیم، یک Repository را با Worktree ایزوله باز می‌کنیم و اولین Task را با Plan و Review کنترل‌شده تا مرحله PR پیش می‌بریم.

GitHub Copilot app چیست؟

GitHub Copilot app یک برنامه دسکتاپ برای توسعه Agentمحور است. هر Session می‌تواند روی Workspace جدا اجرا شود و مدل، Reasoning effort و میزان استقلال متفاوتی داشته باشد. طبق مستندات رسمی، برنامه روی Windows، macOS و Linux در دسترس است و کاربران پلن‌های Copilot می‌توانند از آن استفاده کنند؛ سیاست سازمانی ممکن است دسترسی را محدود کند.

تفاوت اصلی با پنجره Chat داخل IDE، تمرکز بر مدیریت چرخه کامل کار است: انتخاب Issue، ایجاد Workspace، اجرای Agent، مشاهده تغییرات، ارائه Feedback، ساخت Pull Request و دیدن نتیجه CI. هدف این نیست که Review انسانی حذف شود؛ رابط فقط نقاط کنترل را در یک مکان نزدیک‌تر می‌کند.

تفاوت Copilot app، Copilot CLI و GitHub Desktop

نام‌های نزدیک می‌توانند گیج‌کننده باشند. GitHub Copilot app محصول Agentمحور جدید است، درحالی‌که GitHub Desktop در اصل Client گرافیکی Git است و قابلیت‌های Copilot جداگانه‌ای دارد. اگر کار شما کاملاً در Terminal انجام می‌شود، راهنمای نصب و استفاده امن GitHub Copilot CLI مسیر مستقیم‌تری است.

پیش‌نیازها و انتخاب پلن

برای شروع به حساب GitHub و Git نصب‌شده نیاز دارید. می‌توانید از پلن Copilot موجود استفاده کنید؛ مستندات Quickstart همچنین مسیر اتصال Provider شخصی را برای کاربرانی که Provider خودشان را ترجیح می‌دهند توضیح می‌دهند. در حساب سازمانی یا Enterprise باید Policy مخصوص GitHub Copilot app فعال باشد؛ این Policy از Copilot CLI جداست.

• Git را نصب و نام و Email Commit را تنظیم کنید.
• Repository آزمایشی با Test قابل اجرا انتخاب کنید.
• از Clean بودن Working Tree اصلی مطمئن شوید.
• Policy سازمان، Content exclusion و محدودیت داده را بررسی کنید.
• برای اولین Task از Secret یا داده Production استفاده نکنید.

اگر از BYOK استفاده می‌کنید، Prompt و Context Repository به Provider انتخابی شما ارسال می‌شود. سیاست نگه‌داری داده، منطقه پردازش، هزینه و روش حذف Credential را پیش از اتصال بررسی کنید.

نصب GitHub Copilot app در ویندوز

از صفحه رسمی Download که در Quickstart GitHub Docs لینک شده است استفاده کنید. فایل Installer را از سایت ثالث دریافت نکنید. پس از دانلود، امضای Publisher و نام محصول را بررسی، برنامه را نصب و سپس Sign in to GitHub را انتخاب کنید. برای GitHub Enterprise Server باید گزینه مخصوص Enterprise و نشانی Server را وارد کنید.

1. صفحه رسمی Getting started with the GitHub Copilot app را باز کنید.
2. Download GitHub Copilot app را انتخاب کنید.
3. نسخه Windows را از مقصد رسمی دریافت کنید.
4. Installer را اجرا و Publisher را کنترل کنید.
5. برنامه را باز و Sign in to GitHub را انتخاب کنید.
6. مجوزهای درخواست‌شده را بخوانید و حساب درست را تأیید کنید.
7. Theme را انتخاب و Onboarding را تمام کنید.

اگر حساب سازمانی دارید اما برنامه Repositoryها را نشان نمی‌دهد، پیش از نصب مجدد Policy سازمان و دسترسی خود به Repository را بررسی کنید. Policy برنامه با Policy مربوط به CLI یکسان نیست.

اتصال Repository یا پوشه محلی

برنامه می‌تواند پوشه موجود روی سیستم، Repository موجود در GitHub یا URL یک Git remote دیگر را اضافه کند. برای اولین آزمایش، Repository کوچک و غیرحساس انتخاب کنید. افزودن Project به برنامه به معنی اجازه نامحدود نیست؛ Scope واقعی Session، ابزارها و حالت اجرا را جداگانه کنترل کنید.

سه روش افزودن Project

• Local folder or repository: پوشه‌ای که از قبل روی سیستم است.
• GitHub repository: مرور و Clone مستقیم Repositoryهای حساب.
• Repository URL: Clone از Git URL، از جمله Hostهای دیگری مانند Azure DevOps.

قبل از شروع Session، فایل‌های Instruction پروژه را بخوانید. متن Repository می‌تواند قدیمی یا مخرب باشد و نباید به‌تنهایی مجوز اجرای فرمان، Upload یا افشای Secret محسوب شود.

Local repository، Worktree یا Cloud sandbox؟

هنگام ساخت Session می‌توانید محل اجرا را انتخاب کنید. برای Taskهای موازی، Worktree معمولاً گزینه متعادل است: هر Session Working Directory و Branch جدا دارد، اما همچنان روی ماشین شما اجرا می‌شود. Local repository روی Checkout فعلی کار می‌کند و برای تغییر ساده‌ای که خودتان نزدیک آن هستید مناسب‌تر است. Cloud sandbox محیط میزبانی‌شده و ایزوله فراهم می‌کند، اما انتقال Context به محیط Cloud باید با سیاست پروژه سازگار باشد.

Worktree از تداخل فایل جلوگیری می‌کند، اما Conflict منطقی را حذف نمی‌کند. دو Agent ممکن است تغییرهای ناسازگار روی دو Branch بسازند. ترتیب Merge، Test یکپارچه و Review نهایی همچنان ضروری است.

انتخاب Interactive، Plan یا Autopilot

Session mode تعیین می‌کند Agent چقدر مستقل عمل کند. Interactive برای همکاری نزدیک است و Agent در مسیر از شما ورودی می‌گیرد. Plan ابتدا طرح می‌سازد تا قبل از اجرا Scope و روش را ببینید. Autopilot اجازه می‌دهد Agent با استقلال بیشتری کد بنویسد، Test اجرا کند و تکرار کند.

• برای Repository ناشناس یا Task مبهم از Plan شروع کنید.
• برای Debug نیازمند گفت‌وگو، Interactive مناسب است.
• Autopilot را فقط برای Task روشن، قابل بازگشت و دارای Test انتخاب کنید.
• برای هر Session مدل و Reasoning متناسب با پیچیدگی انتخاب کنید.
• حالت Session را می‌توان در طول کار تغییر داد.

Autopilot جای Acceptance criteria نیست. اگر هدف مبهم باشد، Agent ممکن است با کیفیت فنی خوب مسئله اشتباهی را حل کند. ابتدا در Chat یا Plan، نیاز را کوچک و قابل‌آزمون کنید.

اجرای اولین Session امن

یک Task کم‌ریسک مانند افزودن Validation کوچک یا بهبود Test انتخاب کنید. ابتدا Worktree و Plan mode را برگزینید. Prompt باید نتیجه، محدودیت و فرمان Verification را روشن کند. نمونه زیر را متناسب با Stack پروژه تغییر دهید:

در فرم ثبت‌نام، فاصله ابتدا و انتهای نام نمایشی را حذف کن.ابتدا Plan شامل فایل‌های درگیر، edge caseها و تست پیشنهادی ارائه بده.به Migration، Secret و تنظیمات Production دست نزن.پس از تأیید Plan، ابتدا تست شکست‌خورده و سپس کمترین تغییر لازم را بساز.در پایان Diff و خروجی دقیق فرمان تست را گزارش کن.

Plan را قبل از اجرا بخوانید: آیا مسیر فایل درست است؟ آیا Test رفتار واقعی را می‌سنجد؟ آیا تغییر خارج از Scope وجود دارد؟ بعد از تأیید، حین اجرا به درخواست‌های Permission پاسخ آگاهانه بدهید و فرمان ناشناخته را فقط به‌خاطر ادامه کار تأیید نکنید.

مدیریت چند Session موازی

مزیت مهم برنامه، اجرای چند Session ایزوله است. هر Session باید یک مسئولیت مستقل داشته باشد. اجرای سه Agent روی یک Feature واحد بدون مرزبندی، هزینه Merge و Review را بالا می‌برد. Taskها را براساس مرز فایل یا خروجی جدا کنید؛ مثلاً یکی Test coverage را تحلیل کند، دیگری Documentation را اصلاح کند و سومی یک Bug مستقل را رفع کند.

قواعد تقسیم کار

• هر Session یک هدف و معیار تکمیل مستقل داشته باشد.
• دو Session روی فایل‌های یکسان کار نکنند مگر از قبل هماهنگ شده باشد.
• Branch و عنوان Session هدف را روشن نشان دهد.
• Dependency میان Taskها ثبت شود.
• پیش از Merge دوم، Branch آن با Base جدید Sync و Test شود.

Parallelism زمان انتظار را کم می‌کند، اما ظرفیت Review تیم محدود است. تعداد Session فعال را با توان بازبینی هماهنگ کنید؛ خروجی زیاد و بررسی‌نشده پیشرفت واقعی نیست.

Review تغییرات و ساخت Pull Request

پس از پایان Agent، بخش Changes را باز کنید و Diff را خط‌به‌خط ببینید. فایل جدید، Dependency، تنظیمات CI و تغییر Permission اهمیت بیشتری دارند. خروجی Test را به‌صورت تازه اجرا کنید و فقط به خلاصه Agent اتکا نکنید.

1. فهرست فایل‌های تغییرکرده را با Plan مقایسه کنید.
2. کد Production و Test را جدا مرور کنید.
3. به تغییرهای Secret، Network و Dependency حساس باشید.
4. فرمان Test و Lint را دوباره اجرا کنید.
5. در صورت نیاز Feedback مشخص به همان Session بدهید.
6. پس از رضایت، Create PR را انتخاب کنید.
7. وضعیت CI و Review همکار را پیش از Merge کنترل کنید.

مستندات GitHub تأکید می‌کنند خروجی Copilot باید مانند هر Contribution دیگری Review شود. قوانین Branch protection و Reviewer مستقل را برای PRهای Agent نیز نگه دارید.

Chats چه زمانی بهتر از Session است؟

Chats برای پرسش، Brainstorming و محدودکردن Scope مناسب‌اند و Branch یا Worktree اختصاصی نمی‌سازند. اگر هنوز نمی‌دانید چه تغییری لازم است، ابتدا در Chat مسئله را روشن کنید و بعد Session بسازید. این کار مصرف اعتبار و ایجاد Workspace بی‌استفاده را کاهش می‌دهد.

برای توضیح Architecture، مقایسه دو رویکرد یا تهیه Acceptance criteria از Chat استفاده کنید. وقتی خروجی باید فایل، Commit یا PR باشد، Session انتخاب درست‌تری است.

سفارشی‌سازی با Instructions، Skills، MCP و Plugins

بخش Customize امکان مدیریت Instructions، Skills، MCP serverها، Pluginها و Canvasها را فراهم می‌کند. Instruction سراسری روی همه پروژه‌ها اثر دارد و باید فقط Preference عمومی را نگه دارد. قراردادهای اختصاصی Repository را در Scope همان Project تنظیم کنید.

• Skill را فقط از منبع بازبینی‌شده نصب کنید.
• MCP server را با کمترین ابزار و Credential لازم فعال کنید.
• Plugin ممکن است Skill، Hook، Agent و MCP را یکجا اضافه کند؛ Manifest آن را بخوانید.
• Canvas سطح مشترک انسان و Agent است و باید Capabilityهای آن روشن باشد.
• تنظیم سراسری را با قانون اختصاصی یک Repository مخلوط نکنید.

هر سفارشی‌سازی سطح حمله و Context را بزرگ‌تر می‌کند. قابلیت بلااستفاده را نصب نکنید و Updateها را مانند Dependency نرم‌افزار Review کنید.

نکات امنیت و حریم خصوصی

Agent به فایل، فرمان و سرویس‌های متصل دسترسی پیدا می‌کند. Worktree مرز Git است، نه Sandbox کامل سیستم‌عامل. Secretهای موجود در Environment یا پوشه‌های قابل دسترسی ممکن است در Scope ابزار قرار گیرند. برای کد حساس از محیط ایزوله، حساب کم‌دسترسی و Allowlist شبکه استفاده کنید.

• روی شاخه اصلی و Working Tree دارای تغییر ذخیره‌نشده شروع نکنید.
• Autopilot را برای عملیات مالی، انتشار یا تغییر Production به‌کار نبرید.
• قبل از اتصال MCP، متغیرهای Environment قابل انتقال را بررسی کنید.
• با BYOK سیاست داده Provider را جداگانه بپذیرید.
• Prompt، Log و Screenshot را قبل از اشتراک‌گذاری از Secret پاک کنید.
• Pull Request و CI را گیت اجباری نگه دارید.

رفع خطاهای رایج

چک‌لیست پیش از اولین PR

• Installer از صفحه رسمی دریافت شده است.
• حساب و Policy سازمانی درست‌اند.
• Repository آزمایشی و Git clean است.
• Session در Worktree یا Sandbox مناسب اجرا می‌شود.
• Task کوچک و Acceptance criteria روشن است.
• Plan قبل از Implementation تأیید شده است.
• Permissionها فقط برای نیاز همان Task داده شده‌اند.
• Diff خارج از Scope ندارد.
• Test و Lint به‌صورت تازه اجرا شده‌اند.
• PR با CI و Reviewer مستقل بررسی می‌شود.

جمع‌بندی

GitHub Copilot app برای مدیریت Agentها در مقیاس چند Task ساخته شده است: Sessionهای موازی، Worktree و Branch جدا، حالت‌های Interactive و Plan و Autopilot، Review تغییر و چرخه Pull Request را در یک رابط ارائه می‌کند. این قابلیت‌ها زمانی مفیدند که مرز کار و گیت بررسی روشن باشد.

برای شروع امن، Repository آزمایشی، Worktree و Plan mode را انتخاب کنید. Task کوچک بدهید، Plan را پیش از تغییر تأیید کنید، Diff و Test را مستقل ببینید و فقط سپس PR بسازید. بعد از یک Workflow موفق می‌توانید Sessionهای موازی و سفارشی‌سازی را مرحله‌ای اضافه کنید.

امروز GitHub Copilot app را از منبع رسمی نصب کنید و اولین Session را در یک Worktree آزمایشی با Plan mode اجرا کنید؛ پیش از ساخت PR، Diff و نتیجه Test را مستقل بررسی کنید.

منابع رسمی

• درباره GitHub Copilot app
• Quickstart و نصب برنامه
• کار با Agent Sessionها
• سفارشی‌سازی برنامه
• استفاده مسئولانه از Agentها