GitHub Copilot اب PR منظور کرسکتا ہے—مگر اختیار پہلے سے بند ہے
GitHub کے یکم ستمبر 2026 کے سرکاری اعلان کے مطابق Copilot code review اب pull request پر باقاعدہ Approve review جمع کراسکتا ہے۔ یہ صلاحیت public preview میں ہے، default طور پر بند رہتی ہے اور Copilot Pro، Pro+، Max، Business اور Enterprise منصوبوں پر دستیاب ہے۔
یکم ستمبر کو جاری ہونے والی اس public preview میں Copilot کی منظوری required-approval rule پورا کرسکتی ہے، لیکن صرف اس وقت جب منتظم approval بھی فعال کرے اور اسے merge requirement میں شمار کرنے کی الگ اجازت بھی دے۔ Byteiota کی حالیہ رپورٹ نے بھی اسی default-off حیثیت، تین سطحی انتظامی control اور نئی commit پر سابق منظوری ختم ہونے کی تصدیق کی ہے؛ اس لیے موجودہ protected branches خود بخود AI approval قبول نہیں کرتیں۔
Assessment اور باقاعدہ منظوری الگ نتائج ہیں
ہر Copilot code review کے overview comment میں approval assessment دکھائی دے سکتا ہے۔ یہ صرف Copilot کی رائے بتاتا ہے کہ pull request منظوری کے لیے تیار نظر آتی ہے یا نہیں؛ assessment خود کوئی Approve review نہیں اور merge requirement میں شمار نہیں ہوتا۔
ضابطہ جاتی تبدیلی دو repository controls فعال ہونے کے بعد آتی ہے۔ پہلا control Copilot کو approving review جمع کرانے دیتا ہے، جبکہ دوسرا اس approval کو merge requirements میں شمار کرنے کی اجازت دیتا ہے۔ یوں منتظم Copilot سے رسمی منظوری لے سکتا ہے مگر اسے لازمی approval کی گنتی سے باہر بھی رکھ سکتا ہے۔
پاکستانی software teams، open-source maintainers اور GitHub Enterprise administrators کے لیے یہی بنیادی فرق اہم ہے۔ Copilot کا assessment مشورہ ہے؛ counted approval protected branch کا gate کھولنے میں حصہ لے سکتا ہے اور اس لیے اسے عام review automation کے بجائے repository governance کا اختیار سمجھنا چاہیے۔
اختیار enterprise سے repository تک کیسے پہنچتا ہے
Enterprise سطح پر default policy Disabled everywhere ہے۔ Enterprise administrator approvals کو تمام organizations کے لیے بند رکھ سکتا ہے، منتخب organizations میں فعال کرسکتا ہے یا organization owners کو فیصلہ کرنے دے سکتا ہے۔ اوپر کی سطح پر اجازت نہ ملے تو نیچے کا administrator اسے فعال نہیں کرسکتا۔
Organization سطح پر اصل انتخاب یہ ہے کہ Copilot approvals merge requirements میں کہاں شمار ہوسکیں: ہر repository میں، صرف منتخب repositories میں، repository administrators کے فیصلے پر، یا کہیں بھی نہیں۔ اس طرح ایک organization تجرباتی repositories کھول کر production repositories کو اسی policy سے باہر رکھ سکتی ہے۔
Repository administrator کے سامنے تین الگ فیصلے آتے ہیں۔ GitHub کی configuration دستاویزات کے مطابق Auto-approval میں Copilot کو Approve review بھیجنے اور اس approval کو merge requirement میں شمار کرنے کے الگ toggles ہیں؛ file paths کے لیے فی سطر ایک glob اور زیادہ سے زیادہ 15 globs دیے جاسکتے ہیں۔ approval صرف اس pull request کی requirement پوری کرے گا جس کی ہر تبدیل شدہ file کسی درج pattern سے match کرے، جبکہ path فہرست خالی چھوڑنے سے تمام files شامل ہوجاتی ہیں۔
اس hierarchy کا مختصر decision tree یہ ہے: enterprise پہلے طے کرے کہ کن organizations کو اختیار ملے گا؛ organization repositories کا دائرہ مقرر کرے؛ پھر repository administrator submission، merge-counting اور file-path scope الگ الگ منتخب کرے۔ Branch ruleset اس سے جدا یہ طے کرتا ہے کہ Copilot review خودکار طور پر کن branches اور pushes پر مانگا جائے گا۔
حساس code پر انسانی approval کیوں برقرار رہے
File-path restriction ایک تکنیکی حد دیتی ہے، لیکن risk classification ہر ٹیم کی اپنی ذمہ داری ہے۔ محتاط ابتدائی policy میں counted Copilot approval کو کم خطرے اور آسانی سے واپس لی جانے والی تبدیلیوں، مثلاً محدود documentation یا غیر حساس test fixtures، تک رکھا جاسکتا ہے۔ یہ ادارتی governance سفارش ہے، GitHub کی safety guarantee نہیں۔
Authentication، authorization، secrets، payment logic، deployment permissions، infrastructure policy اور approval rules بدلنے والی files پر Copilot کو واحد required approval نہیں ہونا چاہیے۔ ایسے paths کے لیے نامزد انسانی reviewer یا متعلقہ team کی الگ منظوری merge شرط رہ سکتی ہے۔ اگر ایک pull request میں کم خطرے والی files کے ساتھ کوئی حساس file بھی شامل ہو تو narrow allowlist اسے counted Copilot approval سے باہر رکھ دے گی۔
AI کے لکھے ہوئے code اور اسی ecosystem کے AI reviewer کو دو آزاد انسانی opinions کے برابر سمجھنا بھی کمزور governance ہوگا۔ Public preview کی دستیاب معلومات انسانی جواب دہی، threat modeling یا کاروباری اثر کی جانچ کے مساوی reliability ثابت نہیں کرتیں۔ Audit trail میں یہ فرق واضح رہنا چاہیے کہ approval انسان نے دیا، Copilot نے دیا یا دونوں نے۔
- Enterprise سطح پر صرف نامزد organizations کو approval آزمانے دیں۔
- Organization میں repositories کا واضح scope مقرر کریں؛ عمومی enablement کو دانستہ فیصلہ بنائیں۔
- Repository میں approval submission اور merge-counting دونوں toggles الگ جانچیں۔
- Path list خالی نہ چھوڑیں اگر مقصد صرف محدود files کو شامل کرنا ہے۔
- حساس branches اور paths پر کم از کم ایک واضح انسانی gate برقرار رکھیں۔
نئی commit سابق منظوری ختم کردیتی ہے
Copilot کی منظوری pull request کی اس حالت سے منسلک ہے جس کا اس نے review کیا تھا۔ approval کے بعد نئی commit push ہونے پر سابق منظوری dismiss ہوجاتی ہے، جیسے انسانی reviewer کی پرانی منظوری، اور تازہ approval کے لیے Copilot سے دوبارہ review مانگنا پڑتا ہے۔ پہلے منظور شدہ diff اس طرح بعد کی تبدیلیوں کے لیے خاموش اجازت نہیں بنتا۔
Approval dismissal اور automatic re-review الگ رویے ہیں۔ Branch ruleset میں Review new pushes فعال ہو تو ہر نئی push پر Copilot review خودکار طور پر طلب کیا جاسکتا ہے؛ یہ option منتخب نہ ہو تو Copilot pull request کا صرف ایک مرتبہ خودکار review کرتا ہے۔ ایسی صورت میں maintainer کو نئی commit کے بعد review دوبارہ مانگنا ہوگا۔
Merge automation کے لیے صرف یہ دیکھنا کافی نہیں کہ pull request پر کبھی Copilot approval موجود تھا۔ مؤثر gate کو تازہ ترین revision کے خلاف موجود approval دیکھنا چاہیے، جبکہ حساس code کے لیے انسانی approval کی الگ شرط Copilot کی status سے آزاد رہنی چاہیے۔
Public preview میں ابھی کیا نامعلوم ہے
فی الحال تصدیق شدہ صورت یہ ہے کہ Copilot approval public preview، default-off اور enterprise، organization اور repository policies کے تابع ہے۔ GitHub نے اعلان میں مختلف programming languages، repository sizes یا risk classes کے لیے درست اور غلط منظوریوں کی شرح جاری نہیں کی؛ اس لیے دستیاب مواد سے اسے انسانی review کے مساوی ثابت شدہ پیمانہ نہیں کہا جاسکتا۔
یہ تبدیلی لازمی migration نہیں بلکہ ایک نیا اختیاری اختیار ہے۔ جن teams نے approval submission اور merge-counting فعال نہیں کیے، ان کے required approvals محض Copilot assessment سے پورے نہیں ہوں گے۔ Preview کے اگلے مرحلے میں اصل قابلِ مشاہدہ سوال یہ ہوگا کہ GitHub approval quality، audit visibility اور مزید policy controls کے بارے میں کیا معلومات فراہم کرتا ہے؛ تب تک محدود repositories، واضح path allowlists اور حساس code پر مستقل انسانی gate اس اختیار کی محتاط حد بندی ہیں۔
یہ بھی پڑھیں:
ہمارا نیوز لیٹر سبسکرائب کریں
ویب 3، AI اور کرپٹو کی تازہ خبریں براہ راست اپنے اِن باکس میں پائیں۔