Rebase: یہ کیا ہے، rebase کیسے کام کرتا ہے اور Git کے ساتھ کام

Git میں Rebase کیا ہے

Rebase ایک Git کمانڈ ہے جو موجودہ شاخ کو ایک متعین شاخ پر دوبارہ مرتب کرتا ہے: یہ موجودہ شاخ سے تمام کمٹس لےتا ہے، عارضی طور پر محفوظ کرتا ہے، شاخ کے پوائنٹر کو ہدف کمٹ پر لے جاتا ہے اور محفوظ کمٹس کو اس کے اوپر باری بار لاگو کرتا ہے۔ نتیجہ — هیسٹری ایسی لگتی ہے جیسے ڈیولپر نے سیدھے ہدف شاخ کے آخری کمٹ سے کام کیا ہو۔

بنیادی سینٹکس: git rebase main — feature شاخ پر ہوتے ہوئے، یہ کمانڈ تمام feature کمٹس کو main کے سرے پر لے جاتا ہے۔ Git ہر انفرادی کمٹ کے لیے تین طرفہ مرج کی حکمت عملی استعمال کرتا ہے۔ اگر کمٹ A پہلے سے ہدف شاخ میں موجود ہے (ہیش سے طے کیا جاتا ہے)، Git خود برضد اسے چھوړ دیتا ہے، دوہرانے سے بچتا ہے۔

Rebase کمٹس کے ایک ذیب سیٹ کو منتقل کرنے کے لیے onto موڈ کی بھی حمایت کرتا ہے: git rebase --onto target start end — یہ فارم ایک شاخ سے کمٹس کی ایک رینج نکالنے اور انہیں دوسری کے اوپر لاگو کرنے کی اجازت دیتا ہے۔ مثال کے طور پر، git rebase --onto main feature~3 feature feature شاخ کے آخری تین کمٹس کو main کے اوپر لے جاتا ہے۔

# Switch to feature branch
git checkout feature

# Rebase feature onto main
git rebase main

# After successful rebase — history is linear
git log --oneline --graph

# Move last 3 commits to main
git rebase --onto main HEAD~3 HEAD

Rebase vs Merge: اہم فرق

Rebase اور merge ایک ہی کام حل کرتے ہیں — مختلف شاخوں سے تبدیلیوں کو ملانا — لیکن بنیادی طور پر مختلف طریقوں سے کرتے ہیں۔ Merge دو والدیں کے ساتھ merge کمٹ بنا کر مکمل مرج هیسٹری کو محفوظ رکھتا ہے۔ Rebase هیسٹری کو دوبارہ لکھتا ہے، اسے لینیار بناتا ہے۔ ان کے درمیان انتخاب ٹیم کے ورک فلو اور ریپوزٹری منیجمنٹ کے قوانین پر منحصر ہے۔

اہم فرق ہے مرج کے واقعے کو ریکارڈ کرنے کا طریقہ۔ Merge محفوظ کرتا ہے: “اس نقطے پر ہم نے feature کو main میں مرج کیا” — یہ منصوبہ کی هیسٹری کے لیے معلوماتی ہے لیکن بار بار مرج کرنے سے لاگ بیتر ہو جاتا ہے۔ Rebase دیکھاتا ہے: “feature کمٹس main کی آخری حالت سے باری بار بنائے گئے” — یہ صاف ہے لیکن اس حقیقت کو چھپاتا ہے کہ ترقی متوازی کی گئی تھی۔

دوسرا فرق ہے تصادمات کا انتظام۔ Merge کے ساتھ، تصادمات ایک بار حل کیئے جاتے ہیں اور حل merge کمٹ میں ریکارڈ کیا جاتا ہے۔ Rebase کے ساتھ، هر منتقل کمٹ کے لیے تصادمات پیدا ہو سکتے ہیں، ہر ایک کو علیحدہ حل کی ضرورت ہ۔ یہ زیادہ مشقت کا تقاضہ کرتا ہے لیکن اس بات پر زیادہ عینی کنٹرول دیتا ہے کہ کون سی تبدیلیاں حتی نسخہ میں شامل ہوڤ

انٹریکٹو Rebase: احکام اور جھنڈے

انٹریکٹو rebase (git rebase -i) ایک موڈ ہے جس میں Git کمٹس کی فہرست اور ہر ایک کے لیے دستیاب عملوں کے ساتھ ایک ایڈیٹر کھولتا ہے۔ ڈیولپر ریموٹ ریپوزٹری میں بھیجنے سے پہلے هیسٹری کو دوبارہ لکھ سکتا ہے۔ یہ feature شاخ میں صاف کمٹس برقرار رکھنے کا بنیادی آلہ ہے۔

انٹریکٹو موڈ میں دستیاب احکام: pick (کمٹ کو جیسا ہے رکھیں)، reword (کمٹ پیغام بدلیں)، edit (تبدیلی کے لیے رکیں)، squash (پځھلے کمٹ کے ساتھ ملایں، دونوں پیغام رکھیں)، fixup (ملایں، پیغام ضائع کریں)، drop (کمٹ حذف کریں)۔ ہر حکم کھولے گئے ایڈیٹر میں کمٹ ہیش سے پہلے رکھا جاتا ہے۔

Squash اور fixup کمٹس کو ملانے کے لیے سب سے زیادہ استعمال کیے جانے والے احکام ہیں۔ اگر کسی ڈیولپر نے کام کے دوران 5 چہوٹے تصحیحی کمٹ کیئے، squash انہیں ایک معنی خیز پیغام کے ساتھ ایک منطقی کمٹ میں مرج کردیتا ہے۔ Fixup ہجئے کی غلطیوں درست کرنے کے لیے مفید ہے: تبدیلیاں اپنا پیغام رکھے بغیر پځھلے کمٹ میں چلی جاتی ہیں۔

# Open editor for last 4 commits
git rebase -i HEAD~4

# Editor will show:
pick a1b2c3d Add authentication
pick e4f5g6h Fix typo in login
squash i6j7k8l Additional login fixes
pick m9n0o1p Add auth tests

# After saving — Git performs rebase
# and opens editor for squashed commit message

# Auto-squash without opening editor
git rebase -i HEAD~4 --autosquash

--autosquash جھنڈا خود برضد ان کمٹس کے لیے fixup/squash کا انتظام کرتا ہے جن کے پیغامات fixup! یا squash! سے شروع ہوتے ہیں۔ اگر ڈیولپر بعد میں ملانے کے لیے کمٹس پہلے سے نشان کردے تو یہ کام تیز کرتا ہے۔ --committer-date-is-author-date جھنڈا ریبیس کرتے وقت اصل کمٹ تاریخ کو محفوظ رکھتا ہے — هیسٹری میں وقتی ترتیب برقرار رکھنے کے لیے مفید ہے۔

Rebase کے دوران تصادمات کا حل

Rebase کے دوران تصادمات اس وقت پیدا ہوتے ہیں جب Git ہدف شاخ میں تبدیلیوں کے ساتھ تضاد کی وجہ سے منتقل کمٹ کو خود بہ خود لاگو نہیں کر سکتا۔ Merge کے برعکس، جہاں تصادم ایک بار حل ہوتا ہے، rebase کے ساتھ ہر کمٹ تصادم کا سبب بن سکتا ہے، اور اسے ہر کمٹ کے لیے سب سے پرانے سے لے کر نئے تک باری بار حل کرنا پڑتا ہے۔

جب تصادم ہوتا ہے، Git rebase کو روکتا ہے اور رپورٹ کرتا ہے کہ کس کمٹ نے مسئلہ پیدا کیا۔ ڈیولپر تصادم والی فائل کو کھولتا ہے (Git تصادم کے علاقوں کو <<<<<<<، =======، >>>>>>> نشاندهوں سے نشان کرتا ہے)، اسے ترمیم کرتا ہے، انڈیکس میں شامل کرتا ہے (git add)، اور git rebase --continue کے ساتھ rebase جاری رکھتا ہے۔ اگر کوئی حل نہیں ملتا — git rebase --abort rebase کو مکمل طور پر منسوخ کردیتا ہے۔

مشورہ: اکھرے تصادمات کے ساتھ، git mergetool استعمال کرنا زیادہ مؤثر ہے، جو تصادمات حل کرنے کے لیے ایک بصری ایڈیٹر کھولتا ہے۔ آپ مسئلہ والے کمٹ کو چھوړ بھی سکتے ہیں (git rebase --skip)، لیکن یہ اس کی تبدیلیوں کو حتی ہیسٹری سے ہٹا دیتا ہے، جو شازہ ہی صحیح فیصلہ ہوتا ہے۔

# Start rebase with conflict
git rebase main
# Auto-merging file.txt
# CONFLICT (content): Merge conflict in file.txt

# Check status
git status
# both modified: file.txt

# Edit conflicted sections → git add → continue
git add file.txt
git rebase --continue

# If uncertain — abort
git rebase --abort

Rebase کب نہیں کرنا چاہیے

Rebase کا سنہری قاعدہ: ان کمٹس کو کبھی ریبیس نہ کریں جو پہلے سے ریموٹ ریپوزٹری میں بھیجے جا چکے ہیں اور دوسرے ڈیولپرز کے لیے دستیاب ہیں۔ چونکہ rebase کمٹ ہیشز کو دوبارہ لکھتا ہے، ساتھی ملازم مطابقت کی کوشش کرتے وقت تصادمات کا سامنا کریں گے — ان کی مقامی هیسٹری دوبارہ لکھی گئی ریموٹ ہیسٹری سے مختلف ہو گی۔

ایک حالت جس میں rebase مکمل طور پر ممنوع ہے: اگر کسی نے پہلے سے آپ کے کمٹس کی بنیاد پر ایک شاخ بنائی ہو (مثال کے طور پر، آپ کے ساتھی نے آپ کی feature سے ایک شاخ بنائی ہو)، تو هیسٹری کو دوبارہ لکھنا اس کا کام تباہ کر دے گا۔ ایسے معاملوں میں، merge استعمال کریں۔ دیدالائن سے عور rebase کرنا تجویز نہیں کیا جاتا — تصادم حل کرنے میں غلطی امیڈ سے زیادہ وقت لے سکتی ہے اور ریلیز کو بلاک کر سکتی ہے۔

مستثنیٰ: اگر شاخ صرف ایک ڈیولپر استعمال کرتا ہے (ذاتی feature شاخ، شائع نہیں کی گئی یا مسودہ موڈ میں شائع کی گئی)، push سے پہلے rebase ایک معمولی طریقہ ہے۔ اشاعہ اور مشترکہ کام کا آغاز کرنے کے بعد — صرف merge۔ GitHub اور GitLab طرف مطابقت کے طور پر squash merge پرے شیاہ کرتے ہیں: یہ کمٹس کو ایک میں ملاتا ہے لیکن ہدف شاخ کی هیسٹری کو دوبارہ نہیں لکھتا۔

• عوام شاخیں (main, develop, release) — rebase مکمل طور پر ممنوع ہے۔
• دوسروں کے کمٹس — اگر شاخ میں کسی دوسرے ڈیولپر کے کمٹس ہیں، rebase جائز نہیں ہے۔
• ریلیز سے پہلے — تصادم کے خطرات زیادہ: دیدالائن سے ایک روز پہلے merge زیادہ محفوظ ہے۔
• ٹیگ والی شاخیں — ٹیگ والے کمٹ کو منتقل کرنا سیمانٹک ورشننگ کے قواعد کی خلاف ورزی ہے۔
• CI/CD ہیشوں سے منسلک — کچھ تعیناتی سیسٹم بائلڈز کو کمٹ ہیش سے شناخت کرتے ہیں؛ rebase ٹریکنگ کو توڑ دے گا۔

Rebase کے ساتھ عملی ورک فلو

جدید ٹیمیں اکسر GitHub Flow کے ساتھ ملکر rebase پر مرکوز ورک فلو استعمال کرتی ہیں۔ عمل یوں ہے: ڈیولپر main سے ایک feature شاخ بناتا ہے، اس میں کام کرتا ہے، وقتا بہ وقتہ git rebase main کے ذریعہ مطابقت کرتا ہے، اور پل ریکویسٹ بنانے سے پہلے هیسٹری صاف کرنے کے لیے انٹریکٹو rebase کرتا ہے۔

PR بنانے کے بعد (اگر main سے نئی تبدیلیاں کھینچنے کی ضرورت ہو)، ایک عام git pull کے بجائے git pull --rebase main استعمال کیا جاتا ہے۔ یہ ایک ضروری merge کمٹ بنائے بغیر تبدیلیاں کھینچتا ہے۔ --rebase جھنڈے کے ساتھ git pull git fetch + git rebase کے مساوی ہے — Git پہلے نئے کمٹس ڈاؤن لوڈ کرتا ہے، پھر مقامی تبدیلیوں کو ان کے اوپر rebase کرتا ہے۔

Git pull کے لیے rebase کو طرف ست رویہ کے طور پر مقرر کرنے کی اجازت دیتا ہے: git config --global pull.rebase true۔ اس ترتیب کے بعد، git pull ہمیشہ merge کے بجائے rebase کرتا ہے۔ اگر ایک عام pull کی ضرورت ہو — git pull --no-rebase استعمال کیا جاتا ہے۔ بہت سی ٹیمیں autostash بھی فعال کرتی ہیں: git config --global rebase.autoStash true — یہ rebase سے پہلے غیر کمٹ شدہ تبدیلیوں کو خود برضد چھپاتا ہے اور بعد میں انہیں بحال کرتا ہے۔