GitHub یک مسیر ساده‌تر برای ادامهٔ کارهای عامل‌های هوش مصنوعی معرفی کرده است: نشست فعال GitHub Copilot app را می‌توان مستقیماً در Visual Studio Code باز کرد و گفت‌وگو، تغییرات کد، برنامهٔ انجام کار و worktree همان نشست را حفظ کرد. این قابلیت برای تیم‌هایی مهم است که می‌خواهند کارهای تکراری را به Copilot بسپارند، اما بررسی نهایی، اصلاح دستی و اجرای تست را داخل محیط توسعهٔ اصلی خود انجام دهند.
چرا انتقال نشست GitHub Copilot به VS Code مهم است؟
در جریان‌های کاری قدیمی، عامل هوش مصنوعی در یک پنجره تغییراتی ایجاد می‌کرد و توسعه‌دهنده برای بررسی آن مجبور بود فایل‌ها، توضیحات و تصمیم‌های قبلی را در محیط دیگری دوباره جمع‌آوری کند. این جابه‌جایی معمولاً باعث از دست رفتن زمینه می‌شد؛ به‌خصوص وقتی کار شامل چند فایل، شاخهٔ Git یا یک pull request نیمه‌تمام بود. GitHub می‌گوید با گزینهٔ Open in VS Code، نشست اصلی همراه با تاریخچه، برنامه و تغییراتش به ویرایشگر منتقل می‌شود.
این رویکرد، GitHub Copilot را از یک ابزار تولید کد جداشده از محیط توسعه به بخشی از چرخهٔ واقعی بازبینی تبدیل می‌کند. عامل می‌تواند بخش تکراری پیاده‌سازی را انجام دهد و توسعه‌دهنده در همان نشست، diff را خط‌به‌خط ببیند، توضیح بخواهد و تصمیم نهایی را با شناخت کامل‌تری بگیرد.
برای تیم‌های چندنفره، این پیوستگی یک مزیت عملی دیگر هم دارد. وقتی یک نشست GitHub Copilot به شاخه و worktree مشخصی متصل است، فرد بعدی می‌تواند بداند چه چیزی انجام شده، چه فرض‌هایی در برنامه وجود داشته و کدام بخش هنوز نیازمند تصمیم انسانی است. این موضوع، مخصوصاً در کارهای refactor، رفع باگ و آماده‌سازی pull request، از تکرار تحلیل اولیه جلوگیری می‌کند و امکان تحویل مسئولانه‌تر کار را به وجود می‌آورد.
چه چیزهایی در نشست حفظ می‌شود؟
مقالهٔ رسمی GitHub تأکید می‌کند که فقط فایل‌های تغییرکرده منتقل نمی‌شوند. task اولیه، برنامهٔ پیشنهادی عامل، گفت‌وگوی شکل‌گرفته در طول کار، تغییرات کد و worktree مرتبط نیز در دسترس باقی می‌مانند. به همین دلیل، توسعه‌دهنده مجبور نیست خلاصه‌ای طولانی از کار قبلی تهیه کند یا مکالمه را در یک پنجرهٔ تازه از ابتدا بازسازی کند.
پس از باز شدن پروژه در VS Code، می‌توان از نمای Source Control برای بررسی تغییرات استفاده کرد. بررسی خط‌به‌خط کمک می‌کند رفتار ناخواسته، تغییرات خارج از محدوده یا کمبود تست قبل از ادغام pull request شناسایی شود. همچنین می‌توان مستقیماً در فایل‌ها ویرایش کرد و از Copilot خواست برای همان تغییر، تست جدید اضافه کند یا بخش مشخصی را با توجه به context موجود اصلاح کند.
در این مرحله، GitHub Copilot بیشتر شبیه یک همکار قابل‌بررسی عمل می‌کند تا یک فرایند کاملاً خودکار. توسعه‌دهنده می‌تواند دربارهٔ علت یک تغییر سؤال کند، از عامل بخواهد اثر آن را روی فایل‌های دیگر توضیح دهد و سپس تصمیم بگیرد کدام پیشنهاد وارد شاخهٔ اصلی شود. ثبت این تصمیم‌ها در pull request نیز به اعضای تیم کمک می‌کند مسیر تغییر را بعداً بازسازی کنند.
مسیر پیشنهادی برای استفادهٔ امن
انتقال نشست GitHub Copilot به VS Code به معنی پذیرش خودکار همهٔ تغییرات نیست. ابتدا باید task و خروجی عامل در Copilot app مرور شود. سپس در VS Code، diff، قراردادهای پروژه، مدیریت خطا و تست‌های مرتبط بررسی شوند. برای تغییرات رابط کاربری، حالت‌های loading، خالی و خطا نیز باید جداگانه آزموده شوند.
بعد از اصلاح دستی، تست‌های معمول پروژه مانند lint، تست واحد و اجرای محلی را انجام دهید. اگر نشست به یک pull request متصل است، پیش از push نهایی، فایل‌های تغییرکرده و تفاوت شاخه را دوباره بررسی کنید. در پروژه‌های حساس، بازبینی هم‌تیمی و کنترل دسترسی repository همچنان ضروری است؛ حفظ context فقط اصطکاک جابه‌جایی را کم می‌کند و جایگزین مسئولیت مهندسی نمی‌شود.
جمع‌بندی
قابلیت جدید GitHub مسیر همکاری بین عامل و توسعه‌دهنده را پیوسته‌تر می‌کند. Copilot app می‌تواند کارهای پرحجم یا تکراری را آغاز کند و VS Code محیط مناسبی برای بررسی دقیق، ویرایش دستی، اجرای تست و آماده‌سازی انتشار فراهم می‌کند. بهترین نتیجه زمانی به دست می‌آید که تیم، این انتقال را در کنار diff review، تست خودکار، دسترسی حداقلی و فرایند pull request استاندارد به کار بگیرد.
منبع اصلی: GitHub Blog — How to continue a GitHub Copilot app session in VS Code. برای آشنایی با خدمات طراحی و توسعه وب، صفحهٔ خدمات تکتاز را ببینید.
