Rebase: यह क्या है, Merge से कैसे भिन्न है और कार्य सिद्धांत
Rebase Git में एक ऑपरेशन है जो कमिट्स के अनुक्रम को एक नए बेस कमिट पर ले जाता है, ब्रांच के इतिहास को फिर से लिखता है। Merge के विपरीत, Rebase कोई मर्ज कमिट नहीं बनाता, बल्कि लक्ष्य ब्रांच की वर्तमान स्थिति के ऊपर कमिट्स को पुनः लागू करता है। git-scm.com, 2026 के अनुसार, 58% Git प्रोजेक्ट्स में स्वच्छ रैखिक कमिट इतिहास बनाए रखने के लिए rebase का उपयोग किया जाता है।
मुख्य बिंदु
- Rebase कमिट्स को एक नए बेस पर ले जाता है, ब्रांच इतिहास को फिर से लिखता है
- रैखिक इतिहास rebase का मुख्य लाभ है: git log विभाजन शाखाओं के बिना पढ़ा जाता है
- सार्वजनिक ब्रांच के लिए नहीं — rebase कमिट्स को फिर से लिखता है, सहकर्मियों का इतिहास तोड़ता है
- Interactive rebase कमिट्स को मर्ज, नाम बदलने और हटाने की अनुमति देता है
- सुनहरा नियम: कभी भी उस ब्रांच का rebase न करें जिसे किसी ने पहले ही push कर दिया हो
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 रुक जाता है और समाधान की प्रतीक्षा करता है।
bash
# प्रारंभिक स्थिति: 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 के साथ उनकी प्रतियाँ बनाएगा।
bash
# 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 (git rebase -i) कमिट इतिहास को संपादित करने के लिए एक शक्तिशाली उपकरण है। यह कमिट्स और कुंजी कमांड्स की सूची के साथ एक संपादक खोलता है: pick (रखें), reword (संदेश बदलें), edit (सामग्री बदलें), squash (पिछले के साथ मर्ज करें), fixup (बिना संदेश के मर्ज करें), drop (हटाएँ)।
bash
# अंतिम 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परिणाम: तीन कमिट्स (लॉगिन स्क्रीन, वैलिडेशन, लेआउट) एक में संकुचित हो जाते हैं, और टिप्पणियों वाला कमिट हटा दिया जाता है। यह बिना ड्राफ्ट और सुधारों के कोड समीक्षा के लिए एक स्वच्छ इतिहास प्रस्तुत करने की अनुमति देता है। Pull Request से पहले फीचर ब्रांच तैयार करने के लिए इंटरैक्टिव rebase एक मानक उपकरण है।
Rebase vs Merge: तुलना
Rebase और Merge एक ही समस्या का समाधान करते हैं — परिवर्तनों को एकीकृत करना — लेकिन मौलिक रूप से अलग-अलग तरीकों से। उनके बीच चुनाव इस बात पर निर्भर करता है कि आप git log में किस प्रकार का इतिहास देखना चाहते हैं और आपकी ब्रांच के साथ और कौन काम कर रहा है।
| मानदंड | Merge | Rebase |
|---|---|---|
| इतिहास | शाखाकरण संरक्षित करता है | रैखिक, बिना शाखाओं के |
| मर्ज कमिट | बनाया जाता है (ff को छोड़कर) | नहीं बनाया जाता |
| कमिट SHA | नहीं बदलते | नए बनाए जाते हैं |
| सुरक्षा | सार्वजनिक ब्रांचों के लिए सुरक्षित | खतरनाक — इतिहास फिर से लिखता है |
| लॉग पठनीयता | शाखाकरण ग्राफ़ | सीधी रेखा |
| git bisect | सुविधाजनक — मर्ज बिंदु दिखता है | सुविधाजनक — रैखिक अनुक्रम |
व्यावहारिक नियम: साझा ब्रांचों (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 के खिलाफ स्वचालित सुरक्षा सर्वर-साइड hooks के माध्यम से कार्यान्वित की जाती है: Git सर्वर पर pre-receive hook जाँच सकता है कि क्या push प्रकाशित कमिट्स को फिर से लिखता है। GitHub और GitLab संरक्षित ब्रांचों के लिए अंतर्निहित सुरक्षा प्रदान करते हैं — force push तब तक अवरुद्ध रहता है जब तक कि प्रशासक द्वारा सुरक्षा न हटा दी जाए।
अक्सर पूछे जाने वाले प्रश्न
यदि आप किसी सार्वजनिक ब्रांच का rebase करते हैं तो क्या होता है?
ब्रांच का इतिहास बदल जाएगा — कमिट SHA अलग हो जाएँगे। जिन सभी ने इस ब्रांच को push किया है या इससे चाइल्ड ब्रांच बनाई है, उन्हें git pull करने पर विरोधों का सामना करना पड़ेगा। पुनर्प्राप्ति के लिए मैन्युअल हस्तक्षेप की आवश्यकता होगी और कमिट्स की हानि हो सकती है।
क्या rebase को पूर्ववत किया जा सकता है?
पूरा होने से पहले — git rebase --abort। पूरा होने के बाद — केवल git reflog के माध्यम से, यदि rebase हाल ही में किया गया हो। reflog HEAD की गतिविधियों का इतिहास संग्रहीत करता है, जिसके द्वारा rebase से पहले की स्थिति में वापस लौटा जा सकता है: git reset --hard HEAD@{1}।
Rebase cherry-pick से कैसे भिन्न है?
Rebase कमिट्स के अनुक्रम को एक नए बेस पर ले जाता है। Cherry-pick वर्तमान ब्रांच में एक या अधिक विशिष्ट कमिट्स लागू करता है। Rebase पूरी श्रृंखला के लिए स्वचालित है, cherry-pick में प्रत्येक कमिट का मैन्युअल चयन आवश्यक है।
क्या प्रत्येक Pull Request से पहले rebase करना चाहिए?
अनुशंसित है, लेकिन अनिवार्य नहीं। PR से पहले rebase ब्रांच को main/develop की वर्तमान स्थिति में अपडेट करता है और इतिहास साफ करता है। यदि ब्रांच हाल ही में बनाई गई है और उसे अपडेट की आवश्यकता नहीं है, तो कमिट्स की सफाई के लिए इंटरैक्टिव rebase पर्याप्त है।
Rebase टैग्स को कैसे प्रभावित करता है?
टैग rebase के दौरान स्थानांतरित नहीं होते। यदि किसी कमिट पर जो rebase किया गया था, कोई टैग था, तो वह टैग पुराने कमिट पर रहेगा जो अब ब्रांच के इतिहास का हिस्सा नहीं है। फीचर ब्रांचों पर कमिट्स को टैग न करने की अनुशंसा की जाती है, केवल main पर।
सारांश
- Rebase — कमिट्स को एक नए बेस पर रीबेज़ करना, रैखिक इतिहास बनाना
- Merge के विपरीत मर्ज कमिट नहीं बनाता और कमिट SHA को फिर से लिखता है
- इंटरैक्टिव rebase कमिट्स को संकुचित, नाम बदलने और हटाने की अनुमति देता है
- सुनहरा नियम: केवल व्यक्तिगत ब्रांचों का rebase करें, सार्वजनिक का कभी नहीं
- Rebase के बाद force push आवश्यक है (अधिमानतः --force-with-lease)
- Pull Request के लिए rebase + -i के माध्यम से इतिहास की सफाई अनुशंसित
- हाइब्रिड दृष्टिकोण: फीचर ब्रांच अपडेट के लिए rebase, अंतिम रूप देने के लिए --no-ff merge
हम एक मोबाइल एप्लिकेशन टर्नकी विकसित करेंगे
IT Sectr 2017 से स्टार्टअप और व्यवसायों के लिए iOS और Android एप्लिकेशन बनाता है। हम आपको सलाह देंगे और सर्वोत्तम समाधान प्रस्तावित करेंगे।
यह भी पढ़ें