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 पहले नए कमिट्स डाउनलोड करता है, फिर स्थानीय परिवर्तनों को उनके ऊपर रीबेस करता है।

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 से पहले अनकमिटेड परिवर्तनों को स्वचालित रूप से छिपाता है और बाद में उन्हें पुनर्स्थापित करता है।