منظوری / منظوری حاصل کرنا: یہ کیا ہے، Git میں منظوری اور code review

pull request منظوری کیا ہے

منظوری pull request پر ایک منفی جائزہ ہے، جس کا مطلب ہے کہ جائز نے کوڈ چیک کیا، کوئی تنقیدی مسائل نہیں پائے، اور تبدیلیوں کو merge کے لیے تیار سمجھتا ہے۔ GitHub انٹرفیس میں، یہ PR صفحہ پر سبز «Approve» بٹن ہے۔ منظوری کے بعد، مصنف (یا لکھنے کی اجازت رکھنے والا کوئی بھی رکن) merge کر سکتا ہے۔

منظوری کا عمل Branch Protection Rules کا حصہ ہے۔ ریپوزیٹری کے مالک لازمی ضرورتات مقرر کرتے ہیں: کم سے کم منظوریوں کی تعداد (مثال کے طور 1 یا 2)، کون منظوری دے سکتا ہے (کوڈ مالک، ٹیم ارکان)، اور کیا تبدیلیوں کے بعد PR کو دوبارہ منظوری دی جانی چاہیے (Dismiss stale reviews)۔ قواعد کی ترتیب کے بغیر، منظوری اختیاری ہے، لیکن پیشےcard ٹیموں میں یہ لازمی ہے۔

GitLab ایک مشابہ میکانزم استعمال کرتا ہے جسے Approval Rules کہتے ہیں۔ GitLab میں، آپ مختلف گروپوں سے مطلوبہ منظوریوں کی تعداد مقرر کر سکتے ہیں (مثال کے طور، بیک انڈ ڈیویلپرز سے 2 اور DevOps سے 1)۔ تمام لازمی منظوریاں ملنے کے بعد، CI/CD پائپ لائن کے سبز ہونے پر PR merge کے لیے خودکار طور پر کھول جاتا ہے۔

جائزے کی اقسام: Approve, Request Changes, Comment

GitHub اور GitLab میں جائز کے pull request پر چھوڑنے کے لیے تین اقسام کے جائزے ہیں۔ ہر قسم کی مختلف حالت اور merge کے عمل کے لیے مختلف نتائج ہوتے ہیں۔ Approve سبز، Request Changes سرخ، Comment غیر جانبدار دھوئی ہے۔ انتخاب کوڈ کے معیار اور تبدیلیوں کی قبولیت کی تیاری پر منحصر کرتا ہے۔

Approve — جائز تصدیق کرتا ہے: کوڈ صحیح طور پر لیکھا گیا ہے، معایار پورے کرتا ہے، کوئی واضح غلطی نہیں ہے، اور merge کیا جا سکتا ہے۔ Approve کا مطلب کوڈ کامل ہے نہیں ہے — صرف یہ کہ یہ پیداوار کے لیے کافی اچھا ہے۔ اگر چھوٹے تبصرے (انداز، نام رکھنا) ہیں، تو انہیں PR کو روکے بغیر تبصروں کے طور پر چھوڑا جا سکتا ہے۔

Request Changes — جائز وہ مسائل پاتا ہے جو merge سے پہلے طہ کیے جاں: منطقی غلطیاں، کمزوریاں، آرکیٹیکچر خلاف ورزی، ٹیسٹ کی کمی۔ Request Changes کے بعد PR روک جاتا ہے، اور اسے کھولنے کے لیے اسی جائز کی دوبارہ منظوری درکار ہے (اگر نئے کمٹوں پر Dismiss stale reviews کا اختیار فعال ہو)۔

• Approve — کوڈ merge کے لیے تیار، CI پار کرنے کے بعد merge کیا جا سکتا ہے۔
• Request Changes — لازمی تصحیحات، دوبارہ جائزے تک PR ممنوع۔
• Comment — PR کو روکے بغیر عام تبصرہ یا مشورہ۔

ریپوزیٹری میں منظوری کے قواعد کی ترتیب

Branch Protection Rules merge کے معیار کو قابو کرنے کا GitHub کا میکانزم ہے۔ ہر محفوظ برانچ (main, develop, release/*) کے لیے Settings → Branches میں ترتیب دی جاتی ہے۔ اہم پیرامیٹرز: لازمی منظوریوں کی تعداد، کوڈ مالک (CODEOWNERS)، لازمی CI/CD جانچ، اور PR کے بغیر push کی ممنوعیت۔

Dismiss stale pull request approvals پیرامیٹر PR میں نئا کمٹ شامل ہونے پر خودکار طور پر منظوریاں ہٹا دیتا ہے۔ یہ اس بات کی ضمانت دیتا ہے کہ جائز merge کیے جانے والے کوڈ کے عینی ورژن کی منظوری دیتے ہیں۔ اس ترتیب کے بغیر، مصنف منظوری کے بعد نئا کوڈ شامل کر سکتا ہے اور یہ دوبارہ جانچ کے بغیر 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: کیا چیک کریں

منظوری سے پہلے code review diff پر ایک سرسری نظر نہیں بلکہ ایک منظم کوڈ جانچ ہے۔ ایک معیاری code review میں آرکیٹیکچر، منطق، انداز، ٹیسٹ اور سیکیورٹی کی جانچ شامل ہے۔ اس جانچ کے بغیر، منظوری ایک کوالیٹی کنٹرول ٹول کے بجائے ایک رسمیات بن جاتی ہے۔

سب سے پہلے کیا چیک کیا جاتا ہے: تبدیلیوں کی منطق — کیا کوڈ کام کو حل کرتا ہے، کیا مضر اثرات ہیں، کیا حدودی معاملات کا طریقہ صحیح ہے۔ ٹیسٹ — کیا نئے ٹیسٹ تمام مناظروں کو کرتے ہیں، کیا موجودہ ٹیسٹ تبدیلیوں کے بعد پاس ہوتے ہیں۔ سیکیورٹی — کیا SQL انجیکشن، XSS، حساس ڈیٹا لیک نہیں ہے۔

کیا جائزے کا موضوع نہیں ہونا چاہیے: فارمیٹنگ انداز (اس کے لیے linters اور formatters موجود ہیں)، پہلے سے کیے گئے آرکیٹیکچر فیصلے (ان پر کوڈ لکھنے سے پہلے تبادلہ کیا جاتا ہے)۔ اگر ایک جائزہ 400 سطروں سے تجاوز کرتا ہے یا ایک گھنٹے سے زیادہ لیتا ہے، تو یہ اس بات کی نشانی ہے کہ کام بہت بڑا ہے اور اسے توڑنے کی ضرورت ہے۔ بہترین جائزے کے طریقے — PR بنانے کے 24 گھنٹوں کے اندر 200–400 سطروں کے حصے۔

• منطق — حل کی صحت، غلطی کا طریقہ، حدودی معاملات۔
• ٹیسٹ — نئے مناظروں کا احاطہ، موجودہ ٹیسٹ پاس، 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 کرتے ہیں۔ یہ عمل کو تیز کرتا ہے اور merge میں انسانی عامل کو ختم کرتا ہے۔

ایک جدید طریقہ trunk-based development ہے جس میں مختصر مدت کی شاخیں استعمال ہوتی ہیں۔ اس کام کے بہاو میں، منظوری چند گھنٹوں میں مل جانی چاہیے، ورنہ کام فرسودہ سمجھا جاتا ہے اور اسے main کے ساتھ دوبارہ مطابقت کی ضرورت ہوتی ہے۔ اعلی جائزے کی ثقافت والی ٹیمیں منظوری کے وقت کو 4 کامی گھنٹوں سے زیادہ نہیں رکھتیں۔

منظوری میں غلطیاں اور ان سے کیسے بچیں

سب سے عام غلطی حقیقی کوڈ جانچ کے بغیر رسمی منظوری ہے۔ جب PR بڑا ہو یا آخری تاریخ قریب ہو، تو جائز تبدیلیوں کو جانچے بغیر Approve دبا سکتا ہے۔ یہ پورے code review کے عمل کو بے اہمیت بنا دیتا ہے۔ حل: PR کے حجم پر ایک حد لگائیں (400 سطروں سے زیادہ نہیں) اور خودکار جانچ کے لیے کوڈ تجزیے کے اوزار (SonarQube, CodeClimate) استعمال کریں۔

دوسری غلطی ضرورت سے زائد سخت منظوری ہے۔ کامل کوڈ کی توقع ترقی کو روک دیتی ہے۔ جائز کبھی کبھی اندازی تبصروں کو درست کرنے کا مطالبہ کرتے ہیں جو کوالیٹی کو متاثر نہیں کرتے۔ حل: لازمی تبصروں (blocking) اور اختیاری مشوروں (تبصرے) کے درمیان واضح فرق کریں۔ GitHub آپ کو واضح طور پر تعین کرنے کی اجازت دیتا ہے کہ ایک تبصرہ ممنوع کرنے والا ہے یا نہیں۔

تیسری غلطی CI/CD کو چیک کیے بغیر منظوری دینا ہے۔ اگرچہ کوڈ صحیح لگتا ہے، ہو سکتا ہے کہ یہ کمپائل نہ ہو یا ٹیسٹ میں ناکام ہو۔ ترتیب دادہ Branch Protection سرخ CI پر merge کو خودکار طور پر روک دیتی ہے، لیکن کچھ ٹیمیں تیزی کے لیے اس تحفظ کو معذور کر دیتی ہیں۔ حل: منظوری سے پہلے ہمیشہ CI کی حالت چیک کریں اور سرخ پائپ لائن والے PR کو کبھی منظوری ندیں۔

• رسمی منظوری — حقیقی کوڈ جانچ کی عدم موجودگی۔ حل: فی PR 400 سطر کی حد۔
• ضرورت سے زائد سختی — اندازی تبصروں کی وجہ سے روکنا۔ حل: blocking اور optional میں تقسیم کریں۔
• CI کو نظرانداز کرنا — سرخ پائپ لائن پر منظوری۔ حل: ہمیشہ ٹیسٹ کی حالت چیک کریں۔
• مصنف کا تقرر — PR مصنف کی منظوری۔ حل: مصنف کے خلاف Branch Protection ترتیب دیں۔