موبائل ڈیولپمنٹ میں Git اور ورژن کنٹرول: یہ کیا ہے، بنیادی کمانڈز اور یہ کیسے کام کرتا ہے

ورژن کنٹرول اور Git: یہ کیا ہے؟

Git ایک تقسیم شدہ ورژن کنٹرول سسٹم (VCS) ہے جسے لنکس ٹوروالڈز نے 2005 میں لینکس کرنل ڈیولپمنٹ کے لیے بنایا تھا۔ مرکزی نظاموں (SVN، CVS) کے برعکس، Git ہر ڈیولپر کے کمپیوٹر پر پروجیکٹ کی تاریخ کی مکمل کاپی محفوظ کرتا ہے۔ اس کا مطلب ہے کہ آپ انٹرنیٹ کنیکشن کے بغیر بھی commit کر سکتے ہیں، تاریخ دیکھ سکتے ہیں اور شاخیں بنا سکتے ہیں۔

Git سنیشاٹس کے ساتھ کام کرتا ہے — ہر commit محفوظ کرنے کے وقت تمام پروجیکٹ فائلوں کی حالت محفوظ کرتا ہے۔ اگر فائل تبدیل نہیں ہوئی ہے، Git پچھلے ورژن کا حوالہ بناتا ہے، جگہ بچاتا ہے۔ GitHub تجزیہ (2025) کے مطابق، اوسط ریپوزٹری میں 1,200 commit اور 15 شاخیں ہوتی ہیں۔

IT Sectr میں، ہم 2017 سے تمام پروجیکٹس میں Git استعمال کر رہے ہیں۔ ہمارا تجربہ بتاتا ہے کہ پہلے دن سے مناسب Git کنفیگریشن ٹیم کو مرج اور تنازعات حل کرنے میں 30% تک وقت بچاتی ہے۔ Git ڈی فیکٹو معیار بن گیا ہے — یہ تمام جدید IDE (Android Studio، Xcode، VS Code) اور CI/CD سسٹمز میں معاون ہے۔

# بنیادی Git سیٹ اپ
git config --global user.name "آپ کا نام"
git config --global user.email "your@email.com"

# نئی ریپوزٹری بنانا
git init my-project
cd my-project

# فائلیں شامل کرنا اور commit کرنا
git add README.md
git commit -m "Initial commit"

# دوردراز ریپوزٹری کے ساتھ کام کرنا
git remote add origin https://github.com/user/my-project.git
git push -u origin main

مذکورہ کوڈ بنیادی ترتیب دکھاتا ہے: ریپوزٹری کو شروع کرنا، پہلا commit اور دوردراز سرور پر شائع کرنا۔ git init کمانڈ ایک پوشیدہ .git فولڈر بناتا ہے جو پورے پروجیکٹ کی تاریخ محفوظ کرے گا۔ ہر git commit ایک بحالی پوائنٹ بناتا ہے جہاں آپ کسی بھی وقت واپس جا سکتے ہیں۔

بنیادی تصورات: Repository، Branch، Commit

تین بنیادی تصورات — Repository، Branch اور Commit — کو سمجھنا کسی بھی ورژن کنٹرول سسٹم کے ساتھ کام کرنے کے لیے ضروری ہے۔ ریپوزٹری پورے پروجیکٹ کے لیے ایک کنٹینر ہے۔ Commit فائلوں کی محفوظ کردہ حالت ہے۔ Branch ترقی کی ایک علیحدہ لائن ہے۔

Repository (ریپوزٹری) مقامی (آپ کے کمپیوٹر پر) یا دوردراز (GitHub، GitLab سرور پر) ہو سکتی ہے۔ ہر ڈیولپر دوردراز ریپوزٹری کو اپنی مشین پر کلون کرتا ہے اور مقامی کاپی کے ساتھ کام کرتا ہے۔ تبدیلیاں push (بھیجنا) اور pull (لانا) کے ذریعے ہم آہنگ کی جاتی ہیں۔ تقسیم شدہ ورژن کنٹرول میں، ہر ڈیولپر تاریخ کی مکمل کاپی محفوظ کرتا ہے۔

Branch (شاخ) ایک commit کی طرف اشارہ کرنے والا پوائنٹر ہے۔ شاخیں متوازی ترقی کی اجازت دیتی ہیں: ایک ڈیولپر نئی خصوصیت پر کام کرتا ہے (feature branch)، دوسرا بگ ٹھیک کرتا ہے (hotfix branch)، تیسرا ریلیز تیار کرتا ہے (release branch)۔ GitLab Flow (2025) کے مطابق، اوسط پروجیکٹ میں ایک ساتھ 3–5 فعال شاخیں ہوتی ہیں۔

Commit تبدیلی کی ایک اکائی ہے۔ ہر commit میں ایک منفرد ہیش (SHA-1)، پیغام، مصنف اور ٹائم سٹیمپ ہوتا ہے۔ اچھا عمل یہ ہے کہ وضاحتی پیغامات کے ساتھ چھوٹے بامعنی commit کیے جائیں — یہ کوڈ ریویو اور تبدیلیوں کو واپس لانے کو آسان بناتا ہے۔ commit کے ذریعے ورژن کنٹرول آپ کو پروجیکٹ کی مکمل تاریخ دیتا ہے۔

Feature Branch

Feature Branch (فیچر شاخ) ایک عارضی شاخ ہے جو کسی مخصوص کام کی ترقی کے لیے develop یا main سے بنائی جاتی ہے۔ کام مکمل ہونے کے بعد، شاخ Pull Request کے ذریعے واپس مرج کی جاتی ہے اور حذف کر دی جاتی ہے۔ یہ عمل مرکزی کوڈبیس کے استحکام میں خلل ڈالے بغیر تبدیلیوں کو الگ کرنے کی اجازت دیتا ہے۔

عام ورک فلو: شاخ feature/add-login بنائیں → کئی commit کریں → Pull Request بنائیں → کوڈ ریویو سے گزریں → develop میں مرج کریں۔ IT Sectr میں ہم بالکل یہی طریقہ استعمال کرتے ہیں: ہر Jira ٹاسک ایک علیحدہ فیچر شاخ سے مطابقت رکھتا ہے۔ یہ تبدیلیوں کی ٹریکنگ اور ضرورت پڑنے پر واپس لانے کو آسان بناتا ہے۔

Rebase بمقابلہ Merge

Merge ایک مرج commit بناتا ہے جو دو شاخوں کو یکجا کرتا ہے۔ یہ متوازی ترقی کی لائنوں سمیت مکمل تاریخ محفوظ رکھتا ہے۔ Rebase تاریخ کو دوبارہ لکھتا ہے: یہ ایک شاخ سے commit لیتا ہے اور انہیں دوسری شاخ کے اوپر "دوبارہ لاگو" کرتا ہے، ایک لکیری تاریخ بناتا ہے۔

Merge عوامی شاخوں اور بڑی ٹیموں کے لیے زیادہ موزوں ہے جہاں تاریخ اہم ہے۔ Rebase PR بنانے سے پہلے ذاتی فیچر شاخوں کے لیے آسان ہے — یہ تاریخ کو صاف اور زیادہ سمجھنے میں آسان بناتا ہے۔ تاہم، rebase کو ان شاخوں پر کبھی لاگو نہیں کرنا چاہیے جن پر دوسرے ڈیولپرز کام کر رہے ہیں، کیونکہ یہ تاریخ کو دوبارہ لکھتا ہے۔

# فیچر شاخ بنانا اور اس پر سوئچ کرنا
git checkout -b feature/add-login main

# شاخ میں کام کرنا
git add login-screen/
git commit -m "Add login screen layout"

# PR سے پہلے تازہ ترین main پر Rebase
git checkout main && git pull
git checkout feature/add-login
git rebase main

# دوردراز ریپوزٹری میں Push
git push origin feature/add-login

یہ مثال ایک عام ورک فلو دکھاتی ہے: main سے فیچر شاخ بنانا، کئی commit، اور جائزے کے لیے بھیجنے سے پہلے صاف لکیری تاریخ حاصل کرنے کے لیے rebase۔ یہ طریقہ مرج تنازعات کو کم کرتا ہے۔

Git Flow بمقابلہ Trunk-Based Development

Git Flow اور Trunk-Based Development دو اہم ورژن کنٹرول حکمت عملیاں ہیں جو یہ طے کرتی ہیں کہ ٹیم Git کے ساتھ کام کو کیسے منظم کرتی ہے۔ انتخاب کا انحصار ٹیم کے سائز، ریلیز کی تعدد اور استحکام کی ضروریات پر ہے۔

Git Flow ایک سخت ماڈل ہے جس میں متعدد مستقل شاخیں ہوتی ہیں: main (ریلیز کوڈ)، develop (موجودہ ترقی)، feature/* (نئی خصوصیات)، release/* (ریلیز کی تیاری) اور hotfix/* (فوری اصلاحات)۔ یہ ماڈل واضح ریلیز سائیکل والے پروجیکٹس کے لیے اچھا ہے (مثلاً، ورژن 1.0، 2.0 والی موبائل ایپس)۔

Trunk-Based Development ایک اہم شاخ (trunk/main) والا طریقہ ہے جہاں تمام ڈیولپرز دن میں کئی بار تبدیلیاں مرج کرتے ہیں۔ نامکمل خصوصیات کو چھپانے کے لیے فیچر فلیگ استعمال کیے جاتے ہیں۔ یہ طریقہ ویب ڈیولپمنٹ اور اسٹارٹ اپس میں مقبول ہے جہاں ترسیل کی رفتار اہم ہے۔

Git Flow

Git Flow، جسے ونسنٹ ڈریسن نے 2010 میں تجویز کیا تھا، سب سے مقبول ماڈلز میں سے ایک ہے۔ اس کا بنیادی فائدہ لائف سائیکل مراحل کے لحاظ سے کوڈ کی سخت علیحدگی ہے۔ main شاخ میں صرف ریلیز کوڈ ہوتا ہے، develop میں موجودہ ترقی ہوتی ہے، اور فیچر شاخیں نئی خصوصیات کو ایک دوسرے سے الگ کرتی ہیں۔

Hotfix شاخیں فوری اصلاحات کے لیے main سے بنائی جاتی ہیں اور مرج کرنے کے بعد main اور develop دونوں میں واپس مرج کی جاتی ہیں۔ Release شاخیں develop سے بنائی جاتی ہیں جب ٹیم ریلیز کے لیے تیار ہوتی ہے۔ ان میں صرف بگ فکس اور میٹاڈیٹا (ورژن، بلڈ) شامل کیے جاتے ہیں۔ ریلیز کے بعد، release شاخ main اور develop میں مرج کی جاتی ہے۔ JetBrains سروے (2024) کے مطابق، 37% ٹیمیں Git Flow استعمال کرتی ہیں۔ یہ ورژن کنٹرول ماڈل مقررہ ریلیز والے پروجیکٹس کے لیے معیار بنا ہوا ہے۔

# Git Flow مثال: ریلیز پر کام شروع کرنا
git checkout -b release/1.2.0 develop

# release شاخ میں بگ فکس
git commit -m "Fix login button crash"

# ریلیز مکمل کرنا — main اور develop میں مرج
git checkout main
git merge --no-ff release/1.2.0
git tag -a 1.2.0

git checkout develop
git merge --no-ff release/1.2.0

# release شاخ حذف کرنا
git branch -d release/1.2.0

کوڈ release شاخ بنانے، اسے مستحکم کرنے اور اہم شاخوں میں مرج کرنے کی وضاحت کرتا ہے۔ --no-ff فلیگ مرج commit کی ضمانت دیتا ہے، اس معلومات کو محفوظ رکھتا ہے کہ تبدیلیاں release شاخ سے آئی ہیں۔

Pull Request اور کوڈ ریویو

Pull Request (PR) ایک طریقہ کار ہے جس کے ذریعے ڈیولپر اپنی شاخ سے اہم شاخ میں تبدیلیاں تجویز کرتا ہے۔ PR ٹیم ورک میں ورژن کنٹرول کا ایک اہم عنصر ہے — یہ صرف کوڈ مرج کرنے کا طریقہ نہیں ہے، بلکہ بحث، جائزہ اور معیار کی جانچ کا عمل ہے۔ GitLab میں، اسی طرح کے طریقہ کار کو Merge Request (MR) کہا جاتا ہے، لیکن جوہر ایک ہی ہے: ٹیم کو تبدیلیوں سے آگاہ کرنا اور منظوری حاصل کرنا۔

ایک اچھا PR چھوٹا (300 لائن کوڈ تک)، ایک کام پر مرکوز ہونا چاہیے اور اس میں اس بات کی وضاحت ہونی چاہیے کہ کیا کیا گیا اور کیوں کیا گیا۔ Google تحقیق (2025) کے مطابق، 400 لائنوں سے زیادہ کے PR کا جائزہ لینے میں دوگنا وقت لگتا ہے اور بگ دریافت کرنے کا امکان 30% کم ہو جاتا ہے۔ کوڈ ریویو (Code Review) مرج سے پہلے کسی دوسرے ڈیولپر کے ذریعے کوڈ کی جانچ ہے۔

IT Sectr میں، ہم ہر PR کے لیے لازمی کوڈ ریویو کرتے ہیں۔ یہ نہ صرف کوڈ کے معیار کو بہتر بناتا ہے بلکہ ٹیم کے اندر علم پھیلانے میں بھی مدد کرتا ہے۔ کوڈ ریویو چیک کرتا ہے: کیا کوڈ آرکیٹیکچر کے اصولوں پر عمل کرتا ہے، کیا بگ ہیں، کیا کافی ٹیسٹ ہیں، کیا متغیرات صحیح نامزد کیے گئے ہیں۔ تمام تبصروں پر مرج ہونے تک PR میں بحث کی جاتی ہے۔

پلیٹ فارم: GitHub، GitLab، Bitbucket

Git ایک پروٹوکول ہے، لیکن تعاون کے لیے ایک ورژن کنٹرول پلیٹ فارم کی ضرورت ہے جو ویب انٹرفیس، رسائی کا انتظام، CI/CD اور جائزہ کے اوزار فراہم کرے۔ مارکیٹ میں تین پلیٹ فارم غالب ہیں: GitHub، GitLab اور Bitbucket۔

GitHub 56 ملین سے زیادہ ڈیولپرز کے ساتھ سب سے بڑا پلیٹ فارم ہے۔ Microsoft کی ملکیت، یہ Actions (CI/CD)، Pages (ہوسٹنگ)، Discussions اور Copilot پیش کرتا ہے۔ مفت منصوبے میں 3 افراد تک کی ٹیموں کے لیے لامحدود نجی ریپوزٹریز شامل ہیں۔ GitHub اوپن سورس کمیونٹی میں مقبول ہے۔

GitLab ایک مکمل DevOps پلیٹ فارم ہے جس میں مربوط CI/CD، کنٹینر رجسٹری اور انفراسٹرکچر مینجمنٹ ہے۔ GitHub کے برعکس، GitLab آپ کے اپنے سرور پر انسٹال کیا جا سکتا ہے (Self-Managed)۔ Atlassian کا Bitbucket Jira اور Confluence کے ساتھ مضبوطی سے مربوط ہے، جو اسے ان ٹیموں کے لیے انتخاب بناتا ہے جو پہلے ہی Atlassian ایکو سسٹم استعمال کر رہی ہیں۔