Pull Request: یہ کیا ہے، تخلیق کا عمل اور کوڈ ریویو

Pull Request کیا ہے؟

Pull Request (PR) ایک تقسیم شدہ ورژن کنٹرول سسٹم میں ایک برانچ سے دوسری برانچ میں تبدیلیاں شامل کرنے کی باضابطہ درخواست ہے۔ PR GitHub، GitLab اور Bitbucket پلیٹ فارمز پر باہمی ترقی کا مرکزی عنصر ہے، جو کوڈ پر بحث، خودکار جانچ اور تبدیلی کی منظوری کے عمل کو یکجا کرتا ہے۔

نام «Pull Request» آپریشن کے جوہر کو ظاہر کرتا ہے: ایک ڈیولپر ریپوزٹری کے مالک سے اپنی تبدیلیوں کو «کھینچنے» (pull) کی درخواست (request) کرتا ہے۔ یہ اصطلاح GitHub نے 2008 میں متعارف کروائی تھی — اس سے پہلے، پیچ اور merge requests (GitLab کی اصطلاح) کی شکل میں ایک ایسا ہی طریقہ کار موجود تھا۔ آج، PR Git کے ساتھ ٹیم ڈیولپمنٹ کے لیے حقیقی معیار ہے۔

GitHub Octoverse, 2025 کے مطابق، 89% اوپن سورس پروجیکٹس میں تبدیلیاں کرنے کے لیے PR بنانا ضروری ہے۔ کارپوریٹ ڈیولپمنٹ میں، یہ تعداد 95% تک پہنچ جاتی ہے۔ PR نہ صرف ایک تکنیکی آلہ بلکہ ترقی کی ثقافت کا حصہ بن گیا ہے: PR کے ذریعے علم کی منتقلی، بگ کی نشاندہی اور آرکیٹیکچرل فیصلوں کی ہم آہنگی ہوتی ہے۔

Pull Request کے اجزاء

ایک عام PR عنوان، وضاحت، تبدیل شدہ فائلوں کی فہرست (diff)، ریویو کرنے والوں کے تبصرے اور CI جانچ کی حیثیت پر مشتمل ہوتا ہے۔ ہر PR ایک مخصوص سورس برانچ اور ٹارگٹ برانچ سے منسلک ہوتا ہے، اور ضم کرنے کے بعد خود بخود حذف کیا جا سکتا ہے۔

Pull Request کیسے بنائیں

PR بنانا ریموٹ ریپوزٹری میں فیچر برانچ شائع کرنے سے شروع ہوتا ہے۔ پش کرنے کے بعد، ڈیولپر پلیٹ فارم انٹرفیس یا CLI (gh, glab) کے ذریعے PR کھولتا ہے۔ آئیے GitHub کی مثال سے عمل دیکھتے ہیں۔

برانچ پش کرنا اور PR کھولنا

پہلا قدم ریموٹ ریپوزٹری میں فیچر برانچ پش کرنا اور ویب انٹرفیس یا کمانڈ لائن کے ذریعے Pull Request بنانا ہے۔

# فیچر برانچ بنائیں اور پش کریں
git checkout -b feature/biometric-auth
git add src/auth/
git commit -m "feat: add biometric authentication"
git push -u origin feature/biometric-auth

# GitHub CLI کے ذریعے PR بنائیں
gh pr create --title "feat: add biometric authentication" \
  --body "Implements fingerprint and face recognition login.
  Closes #142" \
  --base develop

PR بنانے کے بعد، GitHub خود بخود CI پائپ لائنز (GitHub Actions) چلاتا ہے، ٹارگٹ برانچ کے ساتھ تصادم کی جانچ کرتا ہے اور ریویو کرنے والوں کو مدعو کرتا ہے۔ PR وضاحت کا ٹیمپلیٹ .github/PULL_REQUEST_TEMPLATE.md کے ذریعے ترتیب دیا جا سکتا ہے تاکہ تمام PR میں مطلوبہ حصے ہوں: مقصد، تبدیلیاں، جانچ، متعلقہ کام۔

وضاحت اور ٹیگنگ

معیاری PR وضاحت میں شامل ہے: کام کا لنک (issue/ticket)، تبدیلیوں کی مختصر وضاحت، جانچ کی ہدایات اور متعلقہ تبدیلیوں کی فہرست۔ لیبل (bug, feature, refactoring) PR کی درجہ بندی میں مدد کرتے ہیں، جبکہ assignees اور reviewers CODEOWNERS کے ذریعے خود بخود مقرر ہوتے ہیں۔

# CODEOWNERS کے ذریعے ریویو کرنے والے مقرر کریں (ریپوزٹری روٹ میں فائل)
# .github/CODEOWNERS کی مثال:
# src/auth/ @team-auth @senior-dev
# src/api/ @team-backend
# *.kt @kotlin-team

# gh cli کے ذریعے ریویو کرنے والے مقرر کرتے ہوئے PR بنائیں
gh pr create --reviewer "team-auth" --label "feature"

CODEOWNERS تبدیل شدہ فائلوں کی بنیاد پر خود بخود ریویو کرنے والوں کو مقرر کرنے کے لیے ایک معیاری GitHub/GitLab طریقہ کار ہے۔ مثال کے طور پر، src/auth/ ڈائریکٹری میں کوئی بھی تبدیلی خود بخود team-auth اور senior-dev کو ریویو کرنے والے کے طور پر مقرر کرتی ہے۔ یہ عمل کو تیز کرتا ہے اور یقینی بناتا ہے کہ صحیح لوگ PR دیکھیں۔

ریویو کی بنیاد پر PR کو اپ ڈیٹ کرنا

ریویو کرنے والے کے تبصرے ملنے کے بعد، ڈیولپر اسی فیچر برانچ میں تصحیح کرتا ہے اور نئے کمٹ پش کرتا ہے — PR خود بخود اپ ڈیٹ ہو جاتا ہے۔ اگر PR پہلے سے کھلا ہے تو شائع شدہ فیچر برانچ میں تاریخ کو دوبارہ لکھنا (rebase) اہم نہیں ہے، کیونکہ یہ تبصروں میں مخصوص کمٹ کے لنکس کو توڑ دیتا ہے۔

# ریویو کرنے والے کے تبصروں کی بنیاد پر تبدیلیاں کریں
git checkout feature/biometric-auth
# کوڈ درست کریں
git commit -m "fix: handle biometric timeout per review"
git push

# PR خود بخود اپ ڈیٹ ہو جائے گا
# منظوری کے بعد — GitHub انٹرفیس کے ذریعے PR ضم کریں

کوڈ ریویو کا عمل

کوڈ ریویو Pull Request کا مرکزی عنصر ہے۔ ریویو کرنے والا درستگی، کوڈ اسٹائل، سیکیورٹی اور آرکیٹیکچرل ہم آہنگی کے لیے تبدیلیوں کی جانچ کرتا ہے۔ معیاری ریویو نہ صرف بگز کو روکتا ہے بلکہ ٹیم میں کوڈ بیس کے بارے میں علم پھیلاتا ہے۔

Google کی Engineering Practices (2025) کوڈ ریویو کے درج ذیل اصولوں کی سفارش کرتی ہیں: ریویو کرنے والے کو تبدیلیوں کے سیاق و سباق کو سمجھنا چاہیے، عام تبصروں کے بجائے مخصوص سفارشات دینی چاہئیں، اور تکنیکی اور اسٹائلسٹک تبصروں کو الگ کرنا چاہیے۔ ریویو کا وقت PR بنانے کے 24 گھنٹے سے زیادہ نہیں ہونا چاہیے۔

موبائل ڈیولپمنٹ کے لیے، کوڈ ریویو میں مخصوص جانچ شامل ہے: targetSdk کے ساتھ مطابقت، درست lifecycle ہینڈلنگ (Android) / view lifecycle (iOS)، میموری لیک کی عدم موجودگی (LeakCanary, Instruments)، ڈارک تھیم سپورٹ اور لوکلائزیشن۔ ان جانچوں کو linters اور Detekt/ktlint کے ذریعے خودکار کیا جا سکتا ہے۔

تبصروں کی اقسام

PR پلیٹ فارم تین قسم کے تبصروں کو سپورٹ کرتے ہیں: عام (پورے PR پر)، سطری (کوڈ کی مخصوص لائن پر)، اور تجاویز (متبادل کوڈ کے ساتھ)۔ تجاویز ایک کلک میں تبدیلی لاگو کرنے کی اجازت دیتی ہیں، عمل کو تیز کرتی ہیں اور تکرار کی تعداد کم کرتی ہیں۔

تمام تبصروں کے حل ہونے اور CI جانچ پاس ہونے کے بعد، ریویو کرنے والا منظوری (Approved) بھیجتا ہے۔ PR کو ضم کیا جا سکتا ہے۔ GitHub اور GitLab برانچ پروٹیکشن قوانین کو سپورٹ کرتے ہیں: مطلوبہ منظوریوں کی تعداد، لازمی CI جانچ، اور PR کے بغیر main میں پش پر پابندی۔ موبائل پروجیکٹس کے لیے، برانچ پروٹیکشن میں بلڈ تصدیق بھی شامل ہے: اگر ایپلیکیشن بلڈ نہیں ہوتی (gradle build failed / xcodebuild failed) تو PR کو ضم نہیں کیا جا سکتا۔

PR میں تصادم کا حل

ضم کرنے کے تصادم Pull Request میں فعال ٹیم ورک میں ایک عام صورت حال ہے۔ پلیٹ فارم ویب انٹرفیس کے ذریعے تصادم کا حل فراہم کرتے ہیں (سادہ تصادم کے لیے) یا مقامی طور پر حل کرنے کی سفارش کرتے ہیں۔ GitHub Actions فیچر برانچ میں ہر پش پر خود بخود ضم ہونے کی صلاحیت چیک کرتا ہے اور اگر ضم ممکن نہ ہو تو PR کو تصادم کے طور پر نشان زد کرتا ہے۔

Pull Request کے بہترین طریقہ کار

مؤثر Pull Requests کوڈ ریویو کو تیز کرتی ہیں اور بگز کی تعداد کم کرتی ہیں۔ SmartBear (2025) کے ایک مطالعے سے پتہ چلا ہے کہ 200 لائنوں تک کے کوڈ والے PRs کو 1000 لائنوں سے زیادہ والے PRs کے مقابلے میں 2 گنا زیادہ بامعنی تبصرے ملتے ہیں، اور ریویو کا وقت 3 گنا کم ہو جاتا ہے۔

• چھوٹے PR — بہترین سائز 100-300 لائنیں ہے۔ بڑے PRs کو منطقی حصوں میں تقسیم کریں: ہر PR ایک کام حل کرتا ہے۔ اس سے ریویو آسان ہوتا ہے اور تصادم کا امکان کم ہوتا ہے
• واضح وضاحت — Conventional Commits کے مطابق عنوان (feat:, fix:, refactor:)، باڈی میں «کیسے» کے بجائے «کیا اور کیوں» ہوتا ہے (کوڈ خود بولتا ہے)۔ ٹیمپلیٹ: مقصد → تبدیلیاں → جانچ → متعلقہ issues
• فوری فیڈبیک — 24 گھنٹے کے اندر ریویو۔ اگر PR ایک دن سے زیادہ انتظار کرے تو ٹیم سیاق و سباق کھو دیتی ہے اور ضم کرنے کے تصادم کی تعداد بڑھ جاتی ہے
• آٹومیشن — linters، فارمیٹرز اور ٹیسٹ PR بناتے وقت خود بخود چلنے چاہئیں۔ سرخ CI جانچ والے PRs کو ضم کرنے کی اجازت نہ دیں
• Draft PR — ابتدائی آرکیٹیکچر بحث کے لیے استعمال کریں۔ Draft PR کو ریویو کی ضرورت نہیں ہوتی اور اسے ضم نہیں کیا جا سکتا، لیکن یہ ابتدائی مرحلے میں ساتھیوں کو کوڈ دکھانے کی اجازت دیتا ہے

اضافی طریقہ کار: جمعہ کی شام PR نہ بنائیں (پیر تک کوئی ریویو نہیں کرے گا)، 1-2 لوگوں سے ریویو کی درخواست کریں (زیادہ معیار کو بہتر کیے بغیر عمل کو سست کرتا ہے)، ضم کرنے سے پہلے تاریخ کو سکیڑنے کے لیے squash merge استعمال کریں۔ موبائل پروجیکٹس کے لیے، PR وضاحت میں ٹیسٹ بلڈ (Firebase App Distribution / TestFlight) کا لنک شامل کرنے کی بھی سفارش کی جاتی ہے تاکہ ریویو کرنے والا چلتی ہوئی ایپلیکیشن میں تبدیلیوں کی تصدیق کر سکے۔

مختلف پلیٹ فارمز پر Pull Request

Pull Requests کے ساتھ کام کرنے کے لیے اہم پلیٹ فارمز GitHub، GitLab اور Bitbucket ہیں۔ مشترکہ تصور کے باوجود، ہر ایک میں خصوصیات ہیں جو ٹیم کے لیے آلہ منتخب کرتے وقت غور کرنے کے قابل ہیں۔

GitHub سب سے بڑی کمیونٹی، CI/CD کے لیے Actions اور ایپلیکیشنز کے وسیع ایکو سسٹم (GitHub Marketplace) کے ساتھ سب سے مقبول پلیٹ فارم ہے۔ GitLab مربوط CI/CD اور مکمل سیلف ہوسٹڈ ڈپلائمنٹ کی صلاحیت کے ساتھ نمایاں ہے۔ Bitbucket Jira اور Atlassian ایکو سسٹم کے ساتھ قریب سے مربوط ہے، کارپوریٹ ماحول میں مقبول ہے۔

موبائل ڈیولپمنٹ کے لیے، پلیٹ فارم کا انتخاب اکثر CI/CD صلاحیتوں سے طے ہوتا ہے: GitHub Actions iOS بلڈز کے لیے macOS رنرز کو سپورٹ کرتا ہے، GitLab میں iOS/Android کے لیے بلٹ ان رنرز ہیں، Bitbucket Firebase Test Lab کے ساتھ اچھی طرح مربوط ہوتا ہے۔ پلیٹ فارم سے قطع نظر، PR عمل ایک جیسا رہتا ہے: برانچ → ریویو → CI → ضم۔