Git — یہ کیا ہے، کام کے اصول اور کمانڈز

Git کیا ہے؟

Git ایک ڈسٹری بیوٹڈ ورژن کنٹرول سسٹم (VCS) ہے جو فائلوں میں تبدیلیوں کو ٹریک کرتا ہے اور متعدد ڈویلپرز کو ایک ہی پروجیکٹ پر بیک وقت کام کرنے کی اجازت دیتا ہے۔ مرکزی نظاموں کے برعکس، Git میں ہر ڈویلپر کے پاس تبدیلیوں کی پوری تاریخ سمیت ریپوزٹری کی مکمل کاپی ہوتی ہے، جو سسٹم کو ڈیٹا کے نقصان کے خلاف مزاحم بناتی ہے اور مرکزی سرور سے مسلسل کنکشن کی ضرورت نہیں ہوتی۔

Git کی تاریخ 2005 میں اس وقت شروع ہوئی جب لنکس ٹوروالڈز نے BitKeeper کے لنکس کرنل ڈویلپرز کے لیے مفت لائسنس منسوخ کرنے کے بعد ایک نیا VCS بنایا۔ مقاصد تھے: رفتار، آرکیٹیکچر کی سادگی، برانچنگ کے ذریعے غیر خطی ترقی کی حمایت، اور مکمل تقسیم۔ 3 ماہ میں ٹوروالڈز نے Git کا کور لکھا، اور ایک سال کے اندر پروجیکٹ جونیو ہامانو کی قیادت میں خود انتظامی ہو گیا۔

Stack Overflow سروے (2024) کے مطابق، Git 93.9% پیشہ ور ڈویلپرز استعمال کرتے ہیں، جو اسے صنعت میں غالب ورژن کنٹرول سسٹم بناتا ہے۔ قریب ترین حریف — Subversion (SVN) — صرف 5.2% پروجیکٹس میں استعمال ہوتا ہے، بنیادی طور پر مرکزی عمل والے بڑے کارپوریٹ ماحول میں۔

Git کیسے کام کرتا ہے: ریپوزٹری اور کمٹ

Git ریپوزٹری ایک ڈائرکٹری ہے جہاں Git تمام فائلوں میں تبدیلیوں کو ٹریک کرتا ہے۔ ڈائرکٹری کے اندر ایک چھپی ہوئی فولڈر .git ہے جو تمام سسٹم آبجیکٹس: کمٹ، ٹری، بلاوب اور ریفرنسز محفوظ کرتی ہے۔ جب کوئی ڈویلپر کمٹ بناتا ہے، Git فائلوں کو مکمل طور پر کاپی نہیں کرتا — یہ ایک سنیپ شاٹ بناتا ہے اور اس کا ریفرنس محفوظ کرتا ہے۔

ہر کمٹ میں شامل ہوتا ہے: ایک منفرد SHA-1 ہیش (40 حروف)، پچھلے کمٹ کا ریفرنس (parent)، مصنف، تاریخ، کمٹ پیغام، اور ایک ٹری کا ریفرنس جو کمٹ کے وقت فائلوں کی حالت بیان کرتا ہے۔ کمٹ کی زنجیر ایک ڈائریکٹڈ سائیکلک گراف بناتی ہے جہاں ہر کمٹ ایک یا زیادہ والدین کی طرف اشارہ کرتا ہے۔

# ریپوزٹری کی ابتدا
git init my-project
cd my-project

# کمٹ بنانا
echo "ہیلو، Git" > README.md
git add README.md
git commit -m "Initial commit"

# تاریخ دیکھنا
git log --oneline --graph --all

Git تین اہم علاقے استعمال کرتا ہے: working directory (ڈسک پر فائلیں)، staging area (انڈیکس جہاں تیار فائلیں جاتی ہیں) اور repository (کمٹ ہسٹری)۔ git add کمانڈ ورکنگ ڈائرکٹری سے سٹیجنگ میں تبدیلیاں منتقل کرتا ہے، اور git commit سٹیجنگ کے مواد کو ریپوزٹری میں ریکارڈ کرتا ہے۔ یہ علیحدگی ڈویلپر کو ہر ترمیم کو الگ سے کمٹ کیے بغیر تبدیلیوں کے سیٹ سے ایک معنی خیز کمٹ جمع کرنے کی اجازت دیتی ہے۔

Git کے بنیادی کمانڈز

Git کے بنیادی کمانڈز ڈویلپر کے روزانہ کاموں کے 90% کو کور کرتے ہیں۔ git clone کمانڈ ریموٹ ریپوزٹری کی لوکل کاپی بناتا ہے، git pull سرور سے تبدیلیاں لا کر موجودہ برانچ میں ضم کرتا ہے، اور git push لوکل کمٹ کو سرور پر بھیجتا ہے۔ یہ تین کمانڈز Git کے ساتھ کام کرنے کا مرکزی چکر بناتے ہیں۔

حالت دیکھنے کے لیے git status استعمال کیا جاتا ہے — یہ دکھاتا ہے کہ کون سی فائلیں تبدیل ہوئی ہیں، کون سی سٹیجنگ میں شامل کی گئی ہیں اور کون سی غیر ٹریکڈ ہیں۔ git diff سٹیجنگ میں شامل کرنے سے پہلے فائلوں میں مخصوص تبدیلیاں دکھاتا ہے۔ نیچے سب سے زیادہ استعمال ہونے والے کمانڈز کی ایک جدول ہے:

تبدیلیاں واپس لینے کے لیے، Git کئی اختیارات فراہم کرتا ہے۔ git reset برانچ پوائنٹر کو مخصوص کمٹ پر لے جاتا ہے اور سٹیجنگ یا ورکنگ ڈائرکٹری کو ری سیٹ کر سکتا ہے۔ git revert ایک نیا کمٹ بناتا ہے جو مخصوص کمٹ کی تبدیلیاں واپس لیتا ہے — یہ مشترکہ برانچز کے لیے واپس لینے کا ایک محفوظ طریقہ ہے کیونکہ تاریخ دوبارہ نہیں لکھی جاتی۔

Git میں برانچنگ: main، feature اور release

Git میں برانچز مخصوص کمٹ کی طرف ہلکے حرکت پذیر پوائنٹر ہیں۔ نئی برانچ بنانے سے فائلیں کاپی نہیں ہوتیں، بلکہ صرف ایک نیا پوائنٹر بنتا ہے، جو برانچنگ کو تقریباً فوری بنا دیتا ہے۔ main برانچ (پہلے master) پروجیکٹ کی مرکزی برانچ ہے جس میں مستحکم، ریلیز کے لیے تیار کوڈ ہوتا ہے۔

معیاری عمل Git Flow یا GitHub Flow استعمال کرنا ہے۔ Git Flow برانچز استعمال کرتا ہے: main (ریلیز کوڈ)، develop (انضمام برانچ)، feature/* (نئی خصوصیات)، release/* (ریلیز کی تیاری) اور hotfix/* (فوری اصلاحات)۔ GitHub Flow آسان ہے: صرف main اور فیچر برانچز، اور تمام تبدیلیاں Pull Request کے ذریعے فراہم کی جاتی ہیں۔

# برانچ بنانا اور تبدیل کرنا
git branch feature-auth
git checkout feature-auth
# یا ایک کمانڈ کے ساتھ:
git checkout -b feature-auth

# برانچز کی فہرست
git branch --list
git branch -a  # تمام برانچیں، بشمول حذف شدہ

# برانچ حذف کرنا
git branch -d feature-auth

Git برانچنگ کی ایک اہم خصوصیت cherry-pick ہے: git cherry-pick <hash> کمانڈ کا استعمال کرتے ہوئے انفرادی کمٹ کو ایک برانچ سے دوسری میں منتقل کرنا۔ یہ اس وقت مفید ہے جب آپ کو پوری برانچ کو ضم کیے بغیر فیچر برانچ سے ریلیز میں بگ فکس منتقل کرنے کی ضرورت ہو۔ Git کمٹ کو سکواش، دوبارہ ترتیب دینے اور ترمیم کرنے کے لیے ریبیس اور انٹرایکٹو ریبیس (git rebase -i) کی بھی حمایت کرتا ہے۔

Merge اور Rebase

Merge (انضمام) ایک خاص انضمام کمٹ بناتا ہے جس کے دو والدین ہوتے ہیں۔ یہ کمٹ دو برانچز کے انضمام کی حقیقت کو ریکارڈ کرتا ہے اور مکمل تاریخ محفوظ رکھتا ہے — دیکھا جا سکتا ہے کہ انضمام کہاں اور کب ہوا۔ Merge تاریخ کو ویسے ہی محفوظ رکھتا ہے جیسے اسے بنایا گیا تھا، جو آڈٹ کو آسان بناتا ہے لیکن کمٹ گراف کو مزید پیچیدہ بناتا ہے۔

Rebase (ریباس) انضمام کمٹ بنانے کے بجائے، موجودہ برانچ کے کمٹ کو ہدف برانچ کی نوک پر منتقل کرتا ہے۔ تاریخ لکیری ہو جاتی ہے — یہ تاثر پیدا کرتا ہے کہ ترقی ترتیب وار تھی۔ تاہم، ریباس تاریخ کو دوبارہ لکھتا ہے، کمٹ کے SHA-1 ہیش کو تبدیل کرتا ہے، جس سے یہ مشترکہ برانچز کے لیے خطرناک ہو جاتا ہے جہاں دوسرے ڈویلپرز کی رسائی ہوتی ہے۔

سفارش: عوامی برانچز کے لیے merge استعمال کریں جہاں تاریخ دوسرے ڈویلپرز کو نظر آتی ہے (feature → develop)، اور مقامی کام کے لیے rebase استعمال کریں جب آپ Pull Request بنانے سے پہلے اپنی فیچر برانچ میں main سے نئی تبدیلیاں لاگو کرنا چاہتے ہیں۔ اصول آسان ہے: اگر کمٹ پہلے ہی سرور پر بھیجا جا چکا ہے — تو اسے ریباس نہ کریں۔

تنازعات کا حل

انضمام کا تنازع اس وقت ہوتا ہے جب Git ایک فائل میں تبدیلیوں کو خود بخود ضم نہیں کر سکتا۔ Git فائل میں تنازع والے حصوں کو خصوصی نشانوں سے نشان زد کرتا ہے: <<<<<<< (ہماری تبدیلیاں)، ======= (جدا کرنے والا)، >>>>>>> (ان کی تبدیلیاں)۔ ڈویلپر دستی طور پر فائل میں ترمیم کرتا ہے، مطلوبہ اختیار منتخب کرتا ہے یا دونوں کو یکجا کرتا ہے، اور کمٹ کے ساتھ انضمام مکمل کرتا ہے۔

ریموٹ ریپوزٹریز کے ساتھ کام کرنا

ریموٹ ریپوزٹری (remote) سرور پر واقع Git ریپوزٹری کی ایک کاپی ہے۔ GitHub، GitLab اور Bitbucket ریموٹ ریپوزٹریز کی میزبانی کے لیے سب سے مقبول پلیٹ فارم ہیں۔ وہ کوڈ دیکھنے، رسائی کے انتظام، کوڈ کا جائزہ لینے اور CI/CD سسٹمز کے ساتھ انضمام کے لیے ویب انٹرفیس فراہم کرتے ہیں۔

Git میں، آپ ایک پروجیکٹ کے لیے متعدد ریموٹ ریپوزٹریز ترتیب دے سکتے ہیں۔ ڈیفالٹ کے طور پر، مرکزی ریموٹ کو origin کہا جاتا ہے۔ git remote add کمانڈ ایک نیا ریموٹ شامل کرتا ہے، git fetch بغیر ضم کیے تبدیلیاں لاتا ہے، اور git pull git fetch + git merge کا مخفف ہے۔ Pull Request کے ذریعے کوڈ کے ساتھ کام کرنے کے لیے، ایک ڈویلپر ریپوزٹری کا فورک بناتا ہے، اسے کلون کرتا ہے، فیچر برانچ میں کام کرتا ہے، اور اصل ریپوزٹری کو انضمام کی درخواست بھیجتا ہے۔

# ریموٹ ریپوزٹری شامل کرنا
git remote add origin https://github.com/user/repo.git

# ریموٹ ریپوزٹریز دیکھنا
git remote -v

# سرور پر برانچ بھیجنا
git push -u origin feature-auth

# ریموٹ برانچ سے تبدیلیاں لانا
git pull origin main

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

متوازی کام کے لیے Git Worktree

Git Worktree آپ کو ان کے درمیان سوئچ کیے بغیر مختلف ڈائرکٹریز میں بیک وقت متعدد برانچز کے ساتھ کام کرنے کی اجازت دیتا ہے۔ git worktree add ../feature-auth feature-auth کمانڈ ایک نیا ورکنگ ڈائرکٹری feature-auth بناتا ہے جہاں آپ مرکزی ڈائرکٹری میں برانچ سوئچ کیے بغیر کوڈ لکھ سکتے ہیں۔ Worktree ریلیز برانچ میں فوری اصلاحات کے لیے مفید ہے جب مرکزی ڈائرکٹری طویل مدتی ترقی میں مصروف ہو۔

انحصار کے لیے Git Submodules

Git Submodules ایک Git ریپوزٹری کو دوسری کے اندر شامل کرنے کا ایک طریقہ کار ہے۔ سب ماڈیول بیرونی ریپوزٹری کے ایک مقررہ کمٹ کا ریفرنس محفوظ کرتا ہے، جو بلڈ کی تولیدی صلاحیت کو یقینی بناتا ہے۔ git submodule add https://github.com/example/lib.git کمانڈ بیرونی لائبریری کو سب ماڈیول کے طور پر شامل کرتا ہے۔ سب ماڈیولز والے پروجیکٹ کو کلون کرتے وقت، تمام انحصار ڈاؤن لوڈ کرنے کے لیے git submodule update --init --recursive چلانا ضروری ہے۔