Rebase: یہ کیا ہے، Merge سے کیسے مختلف ہے اور کام کرنے کا اصول

Rebase کیا ہے؟

Rebase (ریباسنگ) ایک Git آپریشن ہے جو موجودہ برانچ سے کمٹس کو ایک نئے بیس پوائنٹ پر منتقل کرتا ہے۔ مرج کمٹ بنانے کے بجائے، rebase ماخذ برانچ سے ہر کمٹ لیتا ہے اور نئی بنیاد پر ایک ایک کرکے لاگو کرتا ہے۔ نتیجہ شاخوں کے بغیر کمٹس کا ایک لکیری سلسلہ ہے۔

نام rebase «re-base» سے آیا ہے — بنیاد بدلنا۔ جہاں merge دو برانچز کو ایک نقطہ پر جوڑتا ہے، rebase آپ کی پوری برانچ کو ایک نئی جگہ منتقل کرتا ہے، جیسے آپ نے ہدف برانچ کی موجودہ حالت سے ترقی شروع کی ہو۔ یہ مکمل طور پر ترتیب وار کام کا وہم پیدا کرتا ہے۔

Atlassian، 2025 کے مطابق، فیچر برانچز کے لیے rebase استعمال کرنے والی ٹیمیں صرف merge استعمال کرنے والی ٹیموں کے مقابلے میں کمٹ ہسٹری کے تجزیے میں 30% کم وقت صرف کرتی ہیں۔ لکیری تاریخ git blame، bisect اور git log --oneline کے ذریعے لاگ دیکھنے کو آسان بناتی ہے۔

Merge سے بنیادی فرق

Merge دو والدین والا کمٹ بنا کر برانچز کو جوڑتا ہے۔ Rebase تاریخ دوبارہ لکھتا ہے: نئے کمٹ نئے ہیش کے ساتھ بنائے جاتے ہیں، اگرچہ ان کی تبدیلیاں اصلی جیسی ہی ہوں۔ اس کا مطلب ہے کہ rebase کمٹس کے SHA شناخت کنندگان کو بدل دیتا ہے، جو عوامی برانچز کے لیے اہم ہے۔

Rebase کیسے کام کرتا ہے

Rebase میکانزم چار مراحل پر مشتمل ہے: Git موجودہ اور ہدف برانچ کا مشترکہ آباؤاجداد (مرج بیس) متعین کرتا ہے، پھر موجودہ برانچ کے ہر کمٹ کو ترتیب وار ہدف برانچ پر لاگو کرتا ہے۔ اگر کسی مرحلے پر تنازع ہو تو، rebase رک جاتا ہے اور حل کا انتظار کرتا ہے۔

# ابتدائی صورتحال: feature برانچ develop سے 3 کمٹ پیچھے ہے
git checkout feature/new-login
git rebase develop

# Git feature سے 3 کمٹ لیتا ہے اور develop پر لاگو کرتا ہے
# اگر کوئی تنازع نہیں — rebase خود بخود مکمل ہو جاتا ہے
# اگر ہیں — Git تنازع والے کمٹ پر رک جاتا ہے

Rebase کے بعد، فیچر برانچ میں develop کے تمام کمٹ اور ساتھ ہی اس کے اپنے کمٹ شامل ہوتے ہیں، جو develop کے تسلسل کے طور پر ظاہر ہوتے ہیں۔ یہ مرج کمٹ بنائے بغیر fast-forward کے ذریعے develop میں ضم کرنے کی اجازت دیتا ہے۔

مرحلہ وار عمل

ایک تفصیلی مثال دیکھیں: ایک ڈویلپر نے develop سے ایک فیچر برانچ بنائی، دو کمٹ کیے، اور اس دوران دوسرے ڈویلپرز نے develop میں تین کمٹ شامل کیے۔ Rebase دو فیچر کمٹس کو ایک نئی جگہ منتقل کرے گا، نئے SHA کے ساتھ ان کی کاپیاں بنائے گا۔

# 1. ایک feature برانچ بنائیں
git checkout -b feature/payment-refactor develop

# 2. feature میں کمٹ کریں
git commit -m "refactor: extract payment validation"
git commit -m "refactor: add payment gateway interface"

# 3. develop کو اپ ڈیٹ کریں (ساتھیوں کا کام)
git checkout develop
git pull

# 4. نئے develop پر feature کا rebase کریں
git checkout feature/payment-refactor
git rebase develop

# 5. اب feature کو fast-forward کے ذریعے ضم کیا جا سکتا ہے
git checkout develop
git merge feature/payment-refactor

اگر مرحلہ 4 میں تنازع ہوتا ہے، Git مسئلہ کمٹ پر رک جاتا ہے۔ ڈویلپر تنازع حل کرتا ہے، git add چلاتا ہے اور git rebase --continue کرتا ہے۔ کمٹ چھوڑنے کے لیے — git rebase --skip، پورے rebase کو منسوخ کرنے کے لیے — git rebase --abort۔

خالی کمٹس کا خودکار چھوڑنا

--empty فلیگ خالی کمٹس (ایسی صورتحال جہاں کمٹ کی تمام تبدیلیاں پہلے سے ہدف برانچ میں موجود ہوں) پر rebase کے رویے کو کنٹرول کرتا ہے۔ ڈیفالٹ طور پر، rebase رک جاتا ہے اور فیصلہ مانگتا ہے۔ --empty=drop کے ساتھ، Git بغیر رکے خودکار طور پر ایسے کمٹس کو چھوڑ دیتا ہے، جس سے بڑی تعداد میں کمٹس کے ساتھ اجتماعی rebase تیز ہو جاتا ہے۔

انٹرایکٹو Rebase

انٹرایکٹو rebase (git rebase -i) کمٹ ہسٹری میں ترمیم کا ایک طاقتور ٹول ہے۔ یہ کمٹس اور اہم کمانڈز (pick (رکھیں)، reword (پیغام بدلیں)، edit (مواد بدلیں)، squash (پچھلے کے ساتھ ضم کریں)، fixup (پیغام کے بغیر ضم کریں)، drop (حذف کریں)) کی فہرست کے ساتھ ایک ایڈیٹر کھولتا ہے۔

# آخری 4 کمٹس کا انٹرایکٹو rebase
git rebase -i HEAD~4

# ایڈیٹر rebase منصوبہ کے ساتھ کھلے گا:
# pick a1b2c3 feat: add login screen
# pick d4e5f6 fix: login validation
# pick g7h8i9 fix: login layout
# pick j0k1l2 docs: add login comments

# اس میں تبدیل کریں:
# pick a1b2c3 feat: add login screen
# squash d4e5f6 fix: login validation
# squash g7h8i9 fix: login layout
# drop j0k1l2 docs: add login comments

نتیجہ: تین کمٹس (لاگ ان سکرین، توثیق، لے آؤٹ) ایک میں سمٹ جاتے ہیں اور تبصروں والا کمٹ حذف ہو جاتا ہے۔ یہ ڈرافٹ اور تصحیحات کے بغیر کوڈ جائزہ کے لیے صاف ستھری تاریخ جمع کروانے کی اجازت دیتا ہے۔ انٹرایکٹو rebase Pull Request سے پہلے فیچر برانچ تیار کرنے کا ایک معیاری ٹول ہے۔

Rebase vs Merge: موازنہ

Rebase اور Merge ایک ہی مسئلہ — تبدیلیوں کا انضمام — حل کرتے ہیں لیکن بنیادی طور پر مختلف طریقوں سے۔ ان کے درمیان انتخاب اس بات پر منحصر ہے کہ آپ git log میں کس قسم کی تاریخ دیکھنا چاہتے ہیں اور آپ کی برانچ کے ساتھ اور کون کام کر رہا ہے۔

عملی اصول: مشترکہ برانچز (develop, main) میں انضمام کے لیے merge استعمال کریں اور ذاتی فیچر برانچز کو اپ ڈیٹ کرنے کے لیے rebase استعمال کریں۔ بہت سی ٹیمیں دونوں کو یکجا کرتی ہیں: develop پر فیچر کا rebase، پھر develop میں --no-ff merge۔

git bisect پر اثر

Git bisect وہ کمٹ ڈھونڈنے کا آلہ ہے جس نے تنزلی متعارف کروائی۔ merge استعمال کرتے وقت، git bisect دونوں والدین کو مدنظر رکھتے ہوئے مرج کمٹس سے صحیح طور پر گزرتا ہے۔ rebase کے ساتھ، bisect تیزی سے کام کرتا ہے کیونکہ تاریخ لکیری ہے اور شاخوں کی ضرورت نہیں۔ تاہم، اگر کمٹس ٹیم کو معلوم ہونے کے بعد rebase کیا گیا، تو اصلی SHA کھو جاتے ہیں اور bisect مسئلہ کمٹ نہیں ڈھونڈ سکتا۔

Rebase کب استعمال کریں

Rebase تین منظرناموں میں بہترین ہے: Pull Request کے لیے فیچر برانچ تیار کرنا، main/develop کی موجودہ حالت میں ذاتی برانچ کو اپ ڈیٹ کرنا، اور ضم کرنے سے پہلے تاریخ صاف کرنا۔ ہر صورت میں، rebase ٹیم ورک کے خطرے کے بغیر تاریخ کی پڑھنے کی اہلیت کو بہتر بناتا ہے۔

Pull Request سے پہلے، ڈرافٹ کمٹس (WIP، جائزہ کے بعد کی اصلاحات) کو بامعنی منطقی اکائیوں میں یکجا کرنے کے لیے انٹرایکٹو rebase کرنے کی سفارش کی جاتی ہے۔ یہ کوڈ جائزہ کو آسان بناتا ہے: جائزہ لینے والا 15 چھوٹے کمٹس نہیں بلکہ واضح پیغامات کے ساتھ 3-5 ساختہ تبدیلیاں دیکھتا ہے۔

فیچر برانچ کو اپ ڈیٹ کرنے کے لیے، rebase merge سے بہتر ہے کیونکہ یہ غیر ضروری مرج کمٹس نہیں بناتا۔ اگر آپ وقتاً فوقتاً فیچر برانچ کے اندر git rebase develop چلاتے ہیں، تو حتمی ضم میں 10 مرج کمٹس کا جھرنا نہیں ہوگا — develop کے اوپر صرف صاف فیچر کمٹس ہوں گے۔

ضم کرنے سے پہلے انٹرایکٹو rebase کے ذریعے تاریخ کی صفائی معمولی اصلاحات (ٹائپو، فارمیٹنگ) چھپانے اور کمٹس کو فعالیت کے مطابق گروپ کرنے کی اجازت دیتی ہے۔ Git پیغامات کو Conventional Commits کنونشن (fix:, feat:, refactor:, docs:) کی پیروی کرنی چاہیے، جو خودکار changelog بناتا ہے۔

Rebase کے خطرات اور اصول

Rebase ایک خطرناک آپریشن ہے اگر غلط طریقے سے لاگو کیا جائے۔ بنیادی خطرہ شائع شدہ تاریخ کو دوبارہ لکھنا ہے۔ اگر کوئی ڈویلپر اس برانچ کا rebase کرے جسے دوسروں نے پہلے ہی push کیا ہے اور استعمال کر رہے ہیں، تو ان کی مقامی کاپیاں غیر مطابقت ہو جائیں گی اور انہیں ڈیٹا کے نقصان کے خطرے کے ساتھ force-pull کرنا پڑے گا۔

• سنہری اصول: کبھی بھی ان کمٹس کا rebase نہ کریں جو پہلے سے مشترکہ ذخیرے میں موجود ہیں۔ یہ ٹیم کے دیگر افراد کی قابل رسائی برانچز پر بھی لاگو ہوتا ہے
• Force push: مقامی فیچر برانچ کے rebase کے بعد، --force-with-lease فلیگ کے ساتھ push ضروری ہے، جو --force سے زیادہ محفوظ ہے کیونکہ یہ چیک کرتا ہے کہ کسی اور نے سرور پر برانچ کو اپ ڈیٹ کیا ہے یا نہیں
• سیاق و سباق کا نقصان: rebase اس معلومات کو تباہ کرتا ہے کہ فیچر برانچ کب اور کس برانچ سے بنائی گئی تھی۔ اگر برانچ بنانے کی تاریخیں محفوظ رکھنا اہم ہے تو merge استعمال کریں
• تنازعات: rebase کے دوران، تنازعات کو ہر کمٹ کے لیے الگ الگ حل کرنا ہوتا ہے، جو بڑی تعداد میں کمٹس کے ساتھ تھکا دینے والا ہو سکتا ہے

خطرات کم کرنے کے لیے، اس اصول پر عمل کریں: صرف ذاتی برانچز کے لیے rebase کریں جو شائع نہیں ہوئیں۔ اگر کوئی برانچ پہلے سے مشترکہ ذخیرے میں ہے، تو --no-ff کے ساتھ merge استعمال کریں۔ اگر آپ کو شائع شدہ برانچ کا rebase کرنے کی ضرورت ہے، تو ٹیم کو پہلے سے آگاہ کریں اور force push کو مربوط کریں۔

خطرناک rebase کے خلاف خودکار تحفظ سرور سائیڈ ہکس کے ذریعے نافذ کیا جاتا ہے: Git سرور پر pre-receive hook چیک کر سکتا ہے کہ push شائع شدہ کمٹس کو دوبارہ تو نہیں لکھ رہا۔ GitHub اور GitLab محفوظ برانچز کے لیے بلٹ ان تحفظ فراہم کرتے ہیں — جب تک ایڈمنسٹریٹر تحفظ نہ ہٹائے force push مسدود رہتا ہے۔