Version Control on kenji.blog

【Git कमांड】rebase और merge के बीच का अंतर, और व्यवहार में इनका सही उपयोग कैसे करें

Sun, 13 Sep 2026 09:00:00 +0900

1. परिचय: “merge या rebase” हमेशा एक बहस का विषय क्यों है?

Git आधुनिक सॉफ़्टवेयर विकास में एक अपरिहार्य वर्ज़न कंट्रोल सिस्टम है। जब कई डेवलपर्स एक साथ कोडबेस में परिवर्तन करते हैं, तो Git का शक्तिशाली ब्रांच मॉडल अपनी ताकत दिखाता है। हालाँकि, टीम डेवलपमेंट में “क्या merge या rebase का उपयोग करना चाहिए” यह चर्चा हमेशा शुरुआती लोगों से लेकर अनुभवी डेवलपर्स तक को परेशान करने वाले विषयों में से एक रही है।

इस लेख में, हम Git की आंतरिक संरचना, जैसे DAG (Directed Acyclic Graph) और कमिट हैश के गणितीय गुणों से शुरू करते हुए, git merge और git rebase के मैकेनिज़्म के बीच के अंतर को गहराई से समझेंगे। इसके अलावा, हम व्यावहारिक वर्कफ़्लो के साथ विस्तार से बताएंगे कि वास्तविक काम में इनका सही तरीके से उपयोग कैसे किया जाए। केवल कमांड्स के परिचय से आगे बढ़कर, बैकग्राउंड में Git किस तरह की गणनाएँ कर रहा है, यह समझने से आपका कॉन्फ्लिक्ट (टकराव) का डर खत्म हो जाएगा और आप एक साफ़ और ट्रैक करने योग्य इतिहास (history) बना सकेंगे।

2. Git की आंतरिक संरचना: कमिट हैश और ऑब्जेक्ट मॉडल

Git इतिहास को कैसे इंटीग्रेट (एकीकृत) करता है, इसे समझने के लिए पहले यह जानना ज़रूरी है कि Git डेटा को कैसे सेव करता है। Git केवल फ़ाइल में बदलावों के अंतर (पैच) को सेव नहीं करता है, बल्कि यह किसी विशिष्ट समय पर पूरे फ़ाइल सिस्टम के स्नैपशॉट को सेव करता है।

2.1 कमिट हैश के क्रिप्टोग्राफ़िक गुण

Git का प्रत्येक कमिट इसके कंटेंट के आधार पर कैलकुलेट किए गए SHA-1 (Secure Hash Algorithm 1) हैश फ़ंक्शन द्वारा 40-अंकीय हेक्साडेसिमल संख्या से विशिष्ट रूप से पहचाना जाता है। कमिट ऑब्जेक्ट में निम्नलिखित तत्व (elements) होते हैं:

Tree ऑब्जेक्ट का पॉइंटर: उस समय के डायरेक्टरी स्ट्रक्चर और फ़ाइल (Blob) का स्नैपशॉट।
पैरेंट कमिट का पॉइंटर: एक या अधिक पैरेंट कमिट्स के हैश मान (पहले कमिट का कोई पैरेंट नहीं होता है, और मर्ज कमिट के 2 या अधिक पैरेंट होते हैं)।
लेखक की जानकारी (Author): वह व्यक्ति जिसने कोड लिखा है और उसका समय।
कमिटर की जानकारी (Committer): वह व्यक्ति जिसने कमिट बनाया/लागू किया है और उसका समय।
कमिट मैसेज: बदलाव के उद्देश्य को स्पष्ट करने वाला टेक्स्ट।

गणितीय रूप से व्यक्त करें, तो कमिट ऑब्जेक्ट $C$ के लिए हैश मान $H(C)$ को इस प्रकार परिभाषित किया गया है:

$$ H(C) = \text{SHA-1}( \text{tree} \parallel \text{parent} \parallel \text{author} \parallel \text{committer} \parallel \text{message} ) $$

यहाँ, $\parallel$ डेटा के संयोजन को दर्शाता है। हैश फ़ंक्शन की विशेषताओं के कारण, भले ही कमिट मैसेज में एक अक्षर बदल दिया जाए, या पैरेंट कमिट अलग हो, पूरी तरह से अलग हैश मान उत्पन्न होता है। दूसरे शब्दों में, कमिट अपरिवर्तनीय (Immutable) होते हैं। बाद में जिस rebase का वर्णन “इतिहास को फिर से लिखने” के रूप में किया गया है, वह वास्तव में “एक नया कमिट बना रहा है जिसकी सामग्री समान है लेकिन हैश मान अलग है।”

हैश स्पेस का आकार $2^{160}$ है, और टकराव की संभावना (Collision) (यह संभावना कि विभिन्न कमिट्स का हैश मान समान होगा) $P$ को बर्थडे पैराडॉक्स (Birthday Paradox) थ्योरी का उपयोग करके इस प्रकार अनुमानित किया जा सकता है ($n$ कमिट्स की संख्या है):

$$ P(\text{collision}) \approx 1 - \exp\left(-\frac{n^2}{2 \times 2^{160}}\right) $$

यह संभावना बहुत ही कम है, और व्यावहारिक रूप से यह लगभग असंभव है कि Git का कमिट हैश आपस में टकराए।

3. ग्राफ़ थ्योरी और DAG: Git इतिहास का गणितीय मॉडल

Git के कमिट इतिहास को ग्राफ़ थ्योरी में “डायरेक्टेड एसाइक्लिक ग्राफ़ (Directed Acyclic Graph, DAG)” के रूप में मॉडल किया गया है।

3.1 DAG (डायरेक्टेड एसाइक्लिक ग्राफ़) क्या है?

ग्राफ़ $G = (V, E)$ में, $V$ कमिट्स (Vertices) का सेट है, और $E$ कमिट्स के बीच पैरेंट-चाइल्ड संबंध को दर्शाने वाले डायरेक्टेड एजेज़ (Directed Edges) का सेट है। Git में, एजेज़ की दिशा “चाइल्ड कमिट से पैरेंट कमिट” की ओर होती है। ऐसा इसलिए है क्योंकि नए कमिट पिछले कमिट का पॉइंटर रखते हैं।

graph BT
A["कमिट A (प्रारंभिक)"]
B["कमिट B"]
C["कमिट C (Main)"]
D["कमिट D (Feature)"]
E["कमिट E (Merge)"]
B --> A
C --> B
D --> B
E --> C
E --> D

DAG की सबसे बड़ी विशेषता यह है कि “इसमें कोई चक्र (Cycle) नहीं होता है”। इस वजह से, कमिट इतिहास को पीछे ट्रेस करने वाला एल्गोरिदम कभी भी अनंत लूप में नहीं फँसता है, और यह निश्चित रूप से अंत (प्रारंभिक कमिट) तक पहुँच सकता है।

3.2 टोपोलॉजिकल सॉर्ट और इतिहास का क्रम

जब Git के git log कमांड आदि का उपयोग करके इतिहास प्रदर्शित किया जाता है, तो DAG को टोपोलॉजिकल सॉर्ट (Topological Sort) एल्गोरिदम का उपयोग करके एक 1-आयामी (1-dimensional) सूची के रूप में क्रमित किया जाता है। DAG में किसी भी डायरेक्टेड एज $u \to v$ ($u$, $v$ का चाइल्ड है) के लिए, यह इस तरह से पुनर्व्यवस्थित होता है कि सूची में $u$, $v$ से पहले आए।

4. git merge का मैकेनिज़्म और प्रकार

ब्रांच के बदलावों को इंटीग्रेट करने के लिए सबसे बुनियादी कमांड git merge है। हालाँकि, वर्तमान स्थिति के आधार पर, Git स्वचालित रूप से अलग-अलग मर्ज रणनीतियों का चयन करता है।

4.1 Fast-Forward मर्ज (–ff)

यदि लक्ष्य (जैसे: main) ब्रांच सोर्स (जैसे: feature) ब्रांच का प्रत्यक्ष पूर्वज (direct ancestor) है, तो Git “Fast-Forward” (तेज़ी से आगे बढ़ाना) मर्ज को निष्पादित करता है। यह एक ऐसा ऑपरेशन है जो नया कमिट नहीं बनाता है, बल्कि यह बस ब्रांच पॉइंटर को आगे बढ़ाता है।

gitGraph
commit id: "A"
commit id: "B"
branch feature
checkout feature
commit id: "C"
commit id: "D"
checkout main
merge feature

Fast-Forward मर्ज इतिहास को एक सीधी रेखा में रखता है, लेकिन इसका एक नुकसान यह है कि “कौन से कमिट्स का समूह एक फीचर (feature) के विकास के रूप में एक साथ था”, इसका संदर्भ (Context) खो जाता है।

4.2 Non-Fast-Forward मर्ज (–no-ff)

यदि आप स्पष्ट रूप से git merge --no-ff निर्दिष्ट करते हैं, तो भले ही Fast-Forward संभव हो, यह हमेशा एक नया “मर्ज कमिट” बनाएगा। मर्ज कमिट 2 पैरेंट्स वाला एक विशेष कमिट होता है।

gitGraph
commit id: "A"
commit id: "B"
branch feature
checkout feature
commit id: "C"
commit id: "D"
checkout main
commit id: "Main Work 1"
merge feature type: NORMAL

इस पद्धति का लाभ यह है कि फीचर ब्रांच का अस्तित्व और इतिहास DAG पर स्पष्ट रूप से रहता है। जब कोई समस्या उत्पन्न होती है, तो आप git revert -m 1 <मर्ज कमिट का हैश> चलाकर पूरे फीचर को एक ही बार में सुरक्षित रूप से पूर्ववत (रिवर्ट) कर सकते हैं।

4.3 3-वे मर्ज (3-Way Merge) एल्गोरिदम

जब लक्ष्य ब्रांच और सोर्स ब्रांच दोनों के अपने स्वयं के कमिट होते हैं, तो Git 3-वे मर्ज निष्पादित करता है। इस समय, Git DAG को खोजता है और दोनों ब्रांचों के “न्यूनतम सामान्य पूर्वज (Lowest Common Ancestor, LCA)” का पता लगाता है।

LCA खोजने के लिए एल्गोरिदम की कम्प्यूटेशनल जटिलता (Computational Complexity) $T_{\text{LCA}}$ को वर्टिसेस की संख्या $|V|$ और एजेज़ की संख्या $|E|$ के सापेक्ष रैखिक समय (Linear Time) में निष्पादित किया जा सकता है:

$$ T_{\text{LCA}} = \mathcal{O}(|V| + |E|) $$

Git तीन चीजों की तुलना करता है: “LCA की स्थिति”, “वर्तमान ब्रांच की स्थिति”, और “दूसरी ब्रांच की स्थिति”, और यदि परिवर्तनों में कोई टकराव (conflict) नहीं होता है, तो यह स्वचालित रूप से एक मर्ज कमिट उत्पन्न करता है।

5. git rebase का मैकेनिज़्म और इतिहास का पुनर्निर्माण

जबकि git merge इतिहास को “एकीकृत (Integrate)” करता है, git rebase इतिहास का “पुनर्निर्माण (Rebuild)” करता है।

5.1 Rebase के पीछे की कार्यप्रणाली

जब आप feature ब्रांच को main ब्रांच में रिबेस करते हैं (git rebase main), तो आंतरिक कार्यप्रणाली इस प्रकार होती है:

feature ब्रांच और main ब्रांच के सामान्य पूर्वज (LCA) का पता लगाएं।
LCA से लेकर feature ब्रांच के शीर्ष तक के कमिट्स के अंतर को एक अस्थायी क्षेत्र (Temporary Area) में सेव करें।
feature ब्रांच के पॉइंटर को main ब्रांच के शीर्ष (Tip) पर ले जाएं।
सहेजे गए अंतरों को एक-एक करके नए बेस (main के शीर्ष) पर क्रमिक रूप से लागू (Cherry-Pick) करें, और नए कमिट्स बनाएं।

graph TD
A["कमिट A"] --> B["कमिट B"]
B --> C["कमिट C (Main)"]
B --> D["कमिट D (पुराना फीचर)"]
D -.-> E["कमिट D' (नया फीचर)"]
C --> E
style D stroke-dasharray: 5 5, fill: #f9f9f9, color: #999

यहाँ सबसे महत्वपूर्ण बात यह है कि रिबेस द्वारा उत्पन्न कमिट $D'$, मूल कमिट $D$ से एक अलग पैरेंट कमिट होने के कारण, पूरी तरह से अलग हैश मान रखता है (ऊपर उल्लिखित हैश फ़ंक्शन परिभाषा $H(C)$ देखें)।

5.2 इंटरएक्टिव रिबेस (Interactive Rebase)

git rebase -i (या --interactive) का उपयोग करके, आप अपनी इच्छानुसार कमिट इतिहास में हेरफेर कर सकते हैं। स्थानीय (Local) इतिहास को व्यवस्थित करने के लिए यह सबसे शक्तिशाली टूल है।

pick : कमिट को वैसे ही अपनाएं।
reword : केवल कमिट मैसेज को संशोधित करें।
edit : कमिट के कंटेंट को संशोधित करने के लिए रुकें।
squash : इस कमिट को पिछले कमिट के साथ मिलाएँ, और संदेशों को भी जोड़ें।
fixup : squash के समान, लेकिन इस कमिट के मैसेज को हटा दें।
drop : कमिट को पूरी तरह से हटा दें।

गणितीय दृष्टिकोण से देखें तो, यदि किसी ब्रांच में $N$ कमिट हैं, तो रिबेस के क्रम को बदलकर उत्पन्न किए जा सकने वाले रैखिक इतिहास के रूपों (Permutations) $P$ की गणना इस प्रकार है:

$$ P = N! $$

Git डेवलपर्स को $N!$ तरीकों की स्वतंत्रता देता है, जिससे वे अपने इतिहास को एक तार्किक और सुंदर स्थिति में रख सकते हैं।

6. रिबेस का सुनहरा नियम (The Golden Rule of Rebase)

rebase बहुत शक्तिशाली है, लेकिन इसका एक निरपेक्ष नियम (Absolute Rule) है:

“सार्वजनिक (Public) किए गए इतिहास पर कभी भी रिबेस (Rebase) न करें” (Never rebase public history)

6.1 सार्वजनिक इतिहास को रिबेस क्यों नहीं करना चाहिए?

Git एक डिस्ट्रिब्यूटेड (Distributed) सिस्टम है। आपने जो कमिट origin/main पर पुश किए हैं, उन्हें अन्य डेवलपर्स के स्थानीय रिपॉजिटरी में भी क्लोन (प्रतिलिपि) किया गया है। अगर आप पहले से ही पुश किए गए कमिट्स को रिबेस करके इतिहास को फिर से लिखते हैं और git push --force का उपयोग करके इसे जबरन ओवरराइट करते हैं, तो क्या होगा?

अन्य डेवलपर्स के स्थानीय (Local) DAG और रिमोट (Remote) DAG मौलिक रूप से अलग हो जाएंगे। जब अन्य डेवलपर git pull निष्पादित करते हैं, तो Git अलग-अलग इतिहास वाले कमिट्स को जबरन मर्ज करने का प्रयास करेगा, जिससे भारी मात्रा में कॉन्फ्लिक्ट्स और डुप्लिकेट कमिट्स (समान परिवर्तन लेकिन अलग-अलग हैश वाले कमिट) उत्पन्न होंगे, और रिपॉजिटरी में अफरा-तफरी मच जाएगी।

यह एक सख्त नियम है कि रिबेस केवल “उन स्थानीय ब्रांचों पर किया जाना चाहिए जिन्हें अभी तक किसी के साथ साझा नहीं किया गया है”।

7. कॉन्फ्लिक्ट (टकराव) का समाधान और git rebase –continue

जब कई लोग एक ही फ़ाइल के एक ही हिस्से में बदलाव करते हैं, तो कॉन्फ्लिक्ट होता है। merge और rebase में कॉन्फ्लिक्ट को हल करने की प्रक्रिया अलग-अलग होती है।

7.1 Merge में कॉन्फ्लिक्ट का समाधान

git merge के मामले में, कॉन्फ्लिक्ट का समाधान केवल एक बार होता है। आप अंतिम मर्ज कमिट बनाने से ठीक पहले सभी टकराव वाले हिस्सों को एक ही बार में ठीक करते हैं।

7.2 Rebase में कॉन्फ्लिक्ट का समाधान

git rebase के मामले में, कमिट्स को एक-एक करके फिर से लागू करने की प्रकृति के कारण, प्रत्येक कमिट पर कॉन्फ्लिक्ट होने की संभावना होती है।

यदि रिबेस के दौरान कोई कॉन्फ्लिक्ट होता है, तो Git प्रक्रिया को रोक देगा। समाधान का प्रवाह (Flow) इस प्रकार है:

एडिटर या IDE (जैसे VS Code) खोलें और कॉन्फ्लिक्ट मार्कर्स (<<<<<<< , ======, और >>>>>>>) को मैन्युअल रूप से ठीक करें।
संशोधित फ़ाइल को इंडेक्स में जोड़ें:
1

git add <संशोधित_फ़ाइल>
बिना कोई कमिट बनाए रिबेस प्रक्रिया फिर से शुरू करें:
1

git rebase --continue

यदि आप रिबेस को रद्द करना चाहते हैं और मूल स्थिति में वापस लौटना चाहते हैं, तो यह कमांड चलाएँ:

1

git rebase --abort

(* यदि आपको कॉन्फ्लिक्ट को हल करने की आवश्यकता नहीं है और आप उस कमिट को पूरी तरह से छोड़ना चाहते हैं, तो git rebase --skip का उपयोग करें।)

8. व्यावहारिक रूप से सही उपयोग (वर्कफ़्लो प्रैक्टिस)

तो, वास्तविक विकास के वातावरण में आपको merge और rebase का उपयोग कैसे करना चाहिए? यहाँ हम सबसे मानक (Standard) और सुरक्षित दृष्टिकोण प्रस्तुत कर रहे हैं।

8.1 [परिदृश्य 1] स्थानीय कार्य इतिहास को व्यवस्थित करना (Rebase का उपयोग)

मान लीजिए कि किसी फीचर ब्रांच में विकास के दौरान बहुत सारे छोटे-छोटे कमिट्स (“Typo फिक्स”, “अस्थायी सेव”, आदि) जमा हो गए हैं। पुल रिक्वेस्ट (PR) सबमिट करने से पहले, इन कमिट्स को सार्थक इकाइयों में व्यवस्थित करने के लिए इंटरएक्टिव रिबेस का उपयोग करें।

1
2
3


# फीचर ब्रांच में रहते हुए निष्पादित करें
git rebase -i HEAD~5
# (एडिटर खुलेगा, जहाँ आप squash और fixup का उपयोग करके इतिहास को साफ़ कर सकते हैं)

इससे, आप एक सुंदर कमिट इतिहास बना सकते हैं जिससे समीक्षकों (Reviewers) के लिए आपके इरादे को समझना आसान हो जाएगा।

8.2 [परिदृश्य 2] नवीनतम main ब्रांच के साथ अपडेट रहना (Rebase का उपयोग)

यदि विकास में अधिक समय लग रहा है, और अन्य लोगों के परिवर्तन लगातार main ब्रांच में मर्ज किए जा रहे हैं, तो आपकी feature ब्रांच पुरानी हो जाएगी। इस स्थिति में, आप अपनी feature ब्रांच को नवीनतम main ब्रांच में रिबेस करके इसे अपडेट कर सकते हैं।

1
2
3
4
5


# main की नवीनतम जानकारी प्राप्त करें
git fetch origin

# फीचर ब्रांच को नवीनतम main के शीर्ष पर स्थानांतरित करें
git rebase origin/main

इससे इतिहास एक सीधी रेखा बन जाता है, जिससे भविष्य में मर्ज करते समय कॉन्फ्लिक्ट्स को रोका जा सकता है। इसके अलावा, यह अनावश्यक मर्ज कमिट्स (“Merge branch ‘main’ into feature”) उत्पन्न होने से भी रोकता है।

8.3 [परिदृश्य 3] पूर्ण हुए फीचर को एकीकृत करना (Merge का उपयोग)

यह वह चरण है जब feature ब्रांच में विकास पूरा हो चुका है, और आप अंततः इसे main ब्रांच में एकीकृत (Integrate) कर रहे हैं। यहाँ, हम git merge --no-ff का उपयोग करेंगे (यह GitHub जैसे प्लेटफ़ॉर्म पर पुल रिक्वेस्ट में “Create a merge commit” चुनने के समान है)।

1
2
3


git checkout main
git merge --no-ff feature -m "Merge feature: यूज़र लॉगिन फीचर का कार्यान्वयन"
git push origin main

इससे, main ब्रांच के DAG पर एक ऐतिहासिक नोड (मर्ज कमिट) बन जाएगा जो यह दर्शाएगा कि “यहाँ एक फीचर मर्ज किया गया था”। जब आप बाद में इतिहास को देखेंगे, तो फीचर के आधार पर कोड को ट्रैक करना आसान होगा।

9. निष्कर्ष (सारांश)

Git ऑपरेशन्स में “सब कुछ Merge के साथ करना” या “सब कुछ Rebase के साथ सीधा करना” जैसे चरम (Extreme) दृष्टिकोणों के अपने-अपने फायदे और नुकसान हैं।

वास्तविक अभ्यास में सबसे अच्छी प्रथा (Best Practice) यह हाइब्रिड (Hybrid) दृष्टिकोण है: “अपने स्थानीय निजी इतिहास को खूबसूरती से व्यवस्थित करने के लिए rebase का उपयोग करें, और सार्वजनिक एकीकरण इतिहास के संदर्भ को बनाए रखने के लिए merge –no-ff का उपयोग करें।”

स्थानीय (व्यक्तिगत कार्यक्षेत्र - Local): अनावश्यक कमिट्स को खत्म करने के लिए rebase का उपयोग करें, और नवीनतम मेनलाइन के साथ अपडेट रहकर एक सीधा इतिहास बनाए रखें।
ग्लोबल (साझा कार्यक्षेत्र - Global): फीचर ब्रांच के अस्तित्व को मर्ज कमिट के रूप में DAG में दर्ज करने के लिए merge --no-ff का उपयोग करें, ताकि इसे रिवर्ट या ट्रैक करना आसान हो।

DAG की संरचना और हैश फ़ंक्शन्स के तंत्र जैसी गणितीय और संरचनात्मक पृष्ठभूमि को समझकर, Git कमांड्स का उपयोग केवल याद रखने से “इरादे के साथ इतिहास डिजाइन करने” में बदल जाता है। रिबेस के सुनहरे नियम का पालन करते हुए, स्थिति के अनुसार सबसे उपयुक्त कमांड चुनें, और एक साफ़ कमिट इतिहास बनाएँ जिसे पूरी टीम के लिए पढ़ना और मेंटेन करना आसान हो।

Git शुरुआती लोगों द्वारा की जाने वाली आम गलतियाँ और समाधान कमांड (कन्फ्लिक्ट रिज़ॉल्यूशन आदि)

Sat, 12 Sep 2026 17:00:00 +0900

Git शुरुआती लोगों द्वारा की जाने वाली आम गलतियाँ और समाधान कमांड (कन्फ्लिक्ट रिज़ॉल्यूशन आदि)

1. परिचय: हम Git में गलतियाँ क्यों करते हैं?

सॉफ्टवेयर विकास में, Git हवा और पानी की तरह अपरिहार्य हो गया है। हालाँकि, कई शुरुआती लोगों (और कभी-कभी अनुभवी लोगों) के लिए, Git एक “डरावने जादुई ब्लैक बॉक्स” की तरह महसूस हो सकता है। कमिट्स का गायब होना, अनजाने में गलत ब्रांच में भारी बदलाव पुश कर देना, या स्क्रीन पर ऐसे कन्फ्लिक्ट एरर मैसेज आना जिन्हें आपने पहले कभी नहीं देखा…। जब आप इस तरह के “Git ट्रैप” में फँसते हैं, तो आपका काम पूरी तरह से रुक जाता है, और सबसे खराब स्थिति में, आप इस डर से घबरा जाते हैं कि कहीं आप अपने सोर्स कोड को नष्ट तो नहीं कर देंगे।

Git इतना कठिन और गलतियों का कारण क्यों है? इसका सबसे बड़ा कारण यह है कि “हम Git के अंदर क्या हो रहा है, यह समझे बिना केवल बाहरी कमांड्स को याद करके उनका उपयोग करते हैं।” Git एक डिस्ट्रीब्यूटेड वर्जन कंट्रोल सिस्टम (DVCS) के रूप में एक मजबूत डिज़ाइन फिलॉसफी पर आधारित है, लेकिन इसका इंटरफ़ेस (CLI) हमेशा सहज नहीं होता है।

इस लेख में, हम उन “गलतियों (सामान्य गलतियों)” को कई मामलों में वर्गीकृत करेंगे जिनका अक्सर Git शुरुआती लोग सामना करते हैं, और प्रत्येक के लिए विशिष्ट समाधान कमांड प्रदान करेंगे। हालाँकि, यह सिर्फ कमांड्स की एक सूची (चीट शीट) नहीं होगी। “वह गलती क्यों होती है” और “उस कमांड को चलाने पर Git के अंदर डेटा कैसे चलता है”, इस पर हम 10,000 से अधिक वर्णों के साथ गहराई से चर्चा करेंगे, जिसमें .git डायरेक्टरी की संरचना, बैकग्राउंड में चल रहे Diff एल्गोरिदम की गणितीय पृष्ठभूमि और Mermaid आरेख शामिल होंगे।

जब आप इस लेख को पढ़ना समाप्त कर लेंगे, तो आप “Git डरावना है” की भावना से मुक्त हो जाएंगे, और इसके बजाय यह आश्वस्त महसूस करेंगे कि “Git से अधिक विश्वसनीय कोई साथी नहीं है।” तो चलिए Git की गहरी दुनिया में गोता लगाते हैं।

2. Git की गहराई: `.git` डायरेक्टरी की आंतरिक संरचना को समझना

कई समस्या-समाधान (troubleshooting) को आसान बनाने का पहला कदम यह जानना है कि Git डेटा कैसे स्टोर करता है। आपके प्रोजेक्ट की रूट डायरेक्टरी में मौजूद छिपा हुआ फ़ोल्डर .git, Git का हृदय है। Git केवल फ़ाइल के अंतर (पैच) को क्रम में रिकॉर्ड करने वाला सिस्टम नहीं है, बल्कि यह डेटा को स्नैपशॉट के स्ट्रीम के रूप में प्रबंधित करता है।

2.1 ऑब्जेक्ट मॉडल: Blob, Tree, Commit

Git रिपॉजिटरी की स्थिति को दर्शाने के लिए मुख्य रूप से 3 ऑब्जेक्ट्स का उपयोग करता है। ये ऑब्जेक्ट्स .git/objects में सेव किए जाते हैं।

Blob (Binary Large Object) यह वह ऑब्जेक्ट है जो फ़ाइल की सामग्री को ही सेव करता है। फ़ाइल का नाम और अनुमतियों की जानकारी इसमें शामिल नहीं होती है। शुद्ध बाइट अनुक्रम को zlib के साथ संपीड़ित किया जाता है और SHA-1 हैश मान (40-वर्ण हेक्साडेसिमल) द्वारा पहचाना जाता है।
Tree यह एक ऑब्जेक्ट है जो डायरेक्टरी की संरचना को दर्शाता है। Tree ऑब्जेक्ट में अन्य Tree ऑब्जेक्ट्स (सबडायरेक्टरी) या Blob ऑब्जेक्ट्स (फ़ाइलें) के पॉइंटर्स (SHA-1 हैश मान), साथ ही उनके फ़ाइल नाम और एक्सेस अनुमतियां शामिल होती हैं। यह UNIX डायरेक्टरी की तरह काम करता है।
Commit यह किसी विशिष्ट समय पर संपूर्ण रिपॉजिटरी के शीर्ष-स्तरीय Tree ऑब्जेक्ट के लिए एक पॉइंटर, मेटाडेटा (निर्माता, कमिट तिथि, और कमिट संदेश), और पिछले कमिट (पैरेंट कमिट) के लिए एक पॉइंटर रखता है।

graph TD
Commit1["कमिट (Hash: 9f8a)"] --> Tree1["ट्री (Hash: 4b82)"]
Tree1 --> Blob1["ब्लॉब (Hash: 8d7e) : index.js"]
Tree1 --> Tree2["ट्री (Hash: 3a2c) : src/"]
Tree2 --> Blob2["ब्लॉब (Hash: 5f1b) : app.js"]

2.2 HEAD और संदर्भ (Refs) की वास्तविकता

Git में काम करते समय आप अक्सर HEAD शब्द देखते हैं। यह एक सिम्बॉलिक रेफरेंस (Symbolic Reference) है जो उस ब्रांच (या कमिट) को इंगित करता है जिसे आपने वर्तमान में चेक आउट किया है। यदि आप टेक्स्ट एडिटर में .git/HEAD फ़ाइल खोलते हैं, तो आपको निम्न स्ट्रिंग दिखाई देगी:

1

ref: refs/heads/main

इसका अर्थ है, “वर्तमान स्थिति main ब्रांच के सिरे पर है।” और यदि आप .git/refs/heads/main खोलते हैं, तो वहां एक 40-वर्ण का SHA-1 हैश लिखा होता है, जो नवीनतम Commit ऑब्जेक्ट को इंगित करता है। Git ब्रांच केवल हल्के पॉइंटर्स (फ़ाइलें) हैं जो विशिष्ट कमिट्स को इंगित करते हैं। केवल इस तथ्य को जानने से यह डर दूर हो जाता है कि “अगर मैं ब्रांच को हटा दूं तो क्या सारी फ़ाइलें गायब हो जाएंगी?”

3. गणित से Git को समझना: Diff एल्गोरिदम और हैश फ़ंक्शन

जब Git कन्फ्लिक्ट का पता लगाता है या फ़ाइलों के बीच अंतर दिखाता है, तो आंतरिक रूप से अत्यधिक उन्नत एल्गोरिदम काम कर रहे होते हैं।

3.1 Myers का Diff एल्गोरिदम

Git का डिफ़ॉल्ट अंतर पहचान (difference detection) एल्गोरिदम Eugene W. Myers द्वारा विकसित किया गया था। जब दो टेक्स्ट फ़ाइलें $A$ और $B$ होती हैं, तो $A$ को $B$ में बदलने के लिए “न्यूनतम संपादन चरण (सम्मिलन और विलोपन)” खोजने की समस्या को ग्राफ सिद्धांत में सबसे छोटे पथ की समस्या (shortest path problem) के रूप में तैयार किया जा सकता है।

मान लें कि स्ट्रिंग की लंबाई क्रमशः $N, M$ है, और कुल $V = N + M$ है। Myers का एल्गोरिदम संपादन दूरी (Edit Distance) $D$ की खोज करता है। इस एल्गोरिदम की समय जटिलता (time complexity) निम्नलिखित समीकरण द्वारा व्यक्त की जाती है:

$$ \mathcal{O}(V \cdot D) $$

यहाँ, यदि फ़ाइलों के बीच का अंतर छोटा है (यानी, $D$ छोटा है), तो एल्गोरिदम बहुत तेजी से $\mathcal{O}(V)$ पर चलता है। हालाँकि, यदि फ़ाइलें पूरी तरह से अलग हैं, तो $D \approx V$, और सबसे खराब स्थिति की जटिलता (worst-case complexity) $\mathcal{O}(V^2)$ हो जाती है।

3.2 Patience Diff और Histogram Diff

हालांकि Myers का एल्गोरिदम उत्कृष्ट है, यह ऐसे अंतर उत्पन्न कर सकता है जो मनुष्यों के लिए सहज (अर्थपूर्ण) नहीं हैं, जैसे कि जब कार्यों या वर्गों के क्रम को बहुत बदल दिया जाता है। इसे हल करने के लिए, Git Patience Diff और Histogram Diff लागू करता है।

Patience Diff “उन अद्वितीय पंक्तियों पर ध्यान केंद्रित करता है जो दोनों फ़ाइलों में केवल एक बार दिखाई देती हैं” और उनके सबसे लंबे सामान्य अनुवर्ती (Longest Common Subsequence: LCS) को ढूंढता है। अद्वितीय तत्वों की संख्या को $U$ मानकर, LCS की गणना निम्नलिखित जटिलता के साथ हल की जा सकती है:

$$ \mathcal{O}(U \log U) $$

जब आपको लगता है कि कन्फ्लिक्ट को हल करना मुश्किल है, तो एक तरीका git diff --histogram का उपयोग करना है, या इस एल्गोरिदम को मर्ज रणनीति के रूप में निर्दिष्ट करना है (git merge -s recursive -X histogram)।

3.3 SHA-1 और टक्कर की संभावना (Collision Probability)

Git सभी ऑब्जेक्ट्स को SHA-1 हैश मानों के साथ प्रबंधित करता है। हैश स्पेस का आकार $2^{160}$ है। जन्मदिन के विरोधाभास (Birthday Paradox) का उपयोग करके हैश टक्कर (विभिन्न सामग्री का समान हैश मान होना) होने की संभावना का अनुमान लगाते हुए, 50% की टक्कर संभावना $p$ होने के लिए आवश्यक ऑब्जेक्ट्स की संख्या $k$ इस प्रकार है:

$$ k \approx \sqrt{2 \ln(2)} \cdot 2^{80} \approx 1.2 \times 2^{80} $$

यह एक खगोलीय संख्या है, और सामान्य सॉफ्टवेयर विकास में अनजाने में होने वाली टक्कर की संभावना वस्तुतः शून्य है। इसलिए, Git हैश मान को “पूर्ण अद्वितीय ID” के रूप में भरोसा करके काम करता है।

4. केस स्टडी 1: गलत ब्रांच में कमिट कर दिया!

【स्थिति】 यह महसूस किए बिना कि मैं main ब्रांच पर काम कर रहा हूँ, मैंने नई सुविधा के लिए तेज़ी से कोड लिख दिया, और यहां तक कि git commit भी कर दिया। मुझे feature/login नाम से एक ब्रांच बनानी चाहिए थी और वहां काम करना चाहिए था!

समाधान: `git reset` और ब्रांच बनाना

Git में, कमिट स्वतंत्र ऑब्जेक्ट हैं, और ब्रांच केवल पॉइंटर्स हैं। इसलिए, आप “एक नई ब्रांच बनाकर और फिर वर्तमान ब्रांच के पॉइंटर को पीछे हटाकर” इसे तुरंत हल कर सकते हैं।

1
2
3
4
5
6
7
8
9


# 1. वर्तमान कमिट (गलती से बनाया गया कमिट) को इंगित करने वाली एक नई ब्रांच बनाएँ
$ git branch feature/login

# 2. main ब्रांच के पॉइंटर को 1 कमिट पहले (HEAD~1) रिवाइंड करें
# --keep का उपयोग करके, आप कार्यशील डायरेक्टरी में बिना कमिट किए गए परिवर्तनों को बनाए रखते हुए सुरक्षित रूप से रीसेट कर सकते हैं।
$ git reset --keep HEAD~1

# 3. सही ब्रांच पर स्विच करें
$ git checkout feature/login

आरेख: अंदर क्या हुआ?

आइए इस दौरान ब्रांच पॉइंटर्स की गति की कल्पना करने के लिए Mermaid के gitGraph का उपयोग करें।

gitGraph
commit id: "प्रारंभिक कमिट"
commit id: "बग फिक्स"
commit id: "गलत कमिट" type: HIGHLIGHT
branch feature/login
checkout feature/login
checkout main

प्रारंभ में, main और HEAD “गलत कमिट” को इंगित कर रहे थे, लेकिन git branch feature/login के साथ, वहां एक नया पॉइंटर बनाया गया है। उसके बाद, git reset के माध्यम से केवल main पॉइंटर “बग फिक्स” स्थिति में वापस आ जाता है। कोई भी ऑब्जेक्ट वास्तव में डिलीट नहीं हुआ है।

5. केस स्टडी 2: पुश किए गए कमिट को रद्द करना चाहता हूँ!

【स्थिति】 मैंने आधी रात के जोश में बग से भरा कोड कमिट किया, और इसे git push origin main के साथ रिमोट रिपॉजिटरी में भी पब्लिश कर दिया। मुझे एक गंभीर बग का एहसास हुआ और मैं पीला पड़ गया।

समाधान 1: इतिहास को रद्द करने के लिए `git revert` (अनुशंसित और सुरक्षित)

टीम डेवलपमेंट में, git reset आदि के साथ पहले से ही पुश किए गए कमिट्स के इतिहास के साथ छेड़छाड़ करना सख्त मना है। यह अन्य डेवलपर्स के स्थानीय रिपॉजिटरी के साथ असंगत हो जाएगा। सही तरीका यह है कि “गलत कमिट के परिवर्तनों को पूरी तरह से रद्द करने के लिए एक नया विपरीत कमिट बनाएँ।” यही git revert है।

1
2
3
4
5
6
7


# नवीनतम कमिट को रद्द करने के लिए एक कमिट बनाएँ
$ git revert HEAD
[main 7f3a8b2] Revert "गलत कमिट का संदेश"
 1 file changed, 1 insertion(+), 10 deletions(-)

# रिमोट पर पुश करें
$ git push origin main

gitGraph
commit id: "कमिट A"
commit id: "कमिट B (गलती)"
commit id: "कमिट B को Revert करें" type: REVERSE

इतिहास आगे बढ़ता रहता है, केवल कोड की स्थिति वापस आ जाती है।

समाधान 2: इतिहास के साथ छेड़छाड़ करने के लिए `git push --force-with-lease`

यदि आपने अभी-अभी किसी ऐसी ब्रांच में पुश किया है जिसका उपयोग केवल आप करते हैं, तो इतिहास को फिर से लिखना स्वीकार्य है।

1
2
3
4
5
6
7


# स्थानीय रूप से कमिट को रीसेट करें और ठीक करें
$ git reset --hard HEAD~1
$ git add .
$ git commit -m "Correct implementation"

# रिमोट इतिहास को जबरन ओवरराइट करें
$ git push origin feature/login --force-with-lease

--force-with-lease एक सुरक्षित फोर्स पुश है जो गलती से किसी और के काम को ओवरराइट करने से रोकता है।

6. केस स्टडी 3: काम के बीच में किसी अन्य ब्रांच पर स्विच करना चाहता हूँ (Stash का जादू)

【स्थिति】 feature/A ब्रांच पर एक नई सुविधा लागू करते समय, सोर्स कोड अभी भी आधी-अधूरी स्थिति में है जहां यह संकलित (compile) भी नहीं होगा। अचानक, मेरे बॉस ने मुझे निर्देश दिया, “main ब्रांच के प्रोडक्शन वातावरण में एक आपातकालीन बग है, कृपया इसे अभी ठीक करें!”

समाधान: `git stash` के साथ आश्रय लेना

git stash एक ऐसा कमांड है जो बिना कमिट किए गए परिवर्तनों को अस्थायी क्षेत्र में सेव करता है।

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 1. काम प्रगति पर है उसे सेव करें
$ git stash push -m "WIP: feature A partially implemented"

# 2. main ब्रांच पर स्विच करने में सक्षम
$ git checkout main
# ...(आपातकालीन बग फिक्स करें, कमिट करें और पुश करें)...

# 3. काम पूरा होने पर मूल ब्रांच पर वापस आएं
$ git checkout feature/A

# 4. सेव किए गए परिवर्तनों को पुनर्स्थापित करें
$ git stash pop

जब आप git stash चलाते हैं, तो Git आंतरिक रूप से दो विशेष कमिट ऑब्जेक्ट बनाता है और उन्हें refs/stash नामक संदर्भ में सहेजता है। दूसरे शब्दों में, Stash अंततः “बिना नाम का एक अस्थायी कमिट” है।

7. केस स्टडी 4: “Detached HEAD” अवस्था का डर

【स्थिति】 मैं अतीत में एक विशिष्ट बिंदु पर कोड की जांच करना चाहता था, इसलिए मैंने git checkout 9f8a7b6 चलाया। तब You are in 'detached HEAD' state. प्रदर्शित हुआ। मैंने वैसे ही कमिट किया, लेकिन जब मैंने ब्रांच स्विच की तो कमिट गायब हो गया!

Detached HEAD का तंत्र

आमतौर पर HEAD एक ब्रांच की ओर इशारा करता है जैसे refs/heads/main। हालाँकि, यदि आप सीधे किसी विशिष्ट कमिट को चेक आउट करते हैं, तो HEAD सीधे कमिट ऑब्जेक्ट की ओर इशारा करेगा। इसे Detached HEAD (अलग हुआ HEAD) कहा जाता है।

graph TD
A["कमिट A"] --> B["कमिट B"]
B --> C["कमिट C"]
C --> D["कमिट D"]
BranchMain["ब्रांच: main"] --> D
HEAD["HEAD"] --> B
style HEAD fill:#f9f,stroke:#333,stroke-width:4px

इस स्थिति में कमिट्स जोड़ने के बाद भी, कोई भी ब्रांच उस नए कमिट को ट्रैक नहीं करेगी। जिस क्षण आप किसी अन्य ब्रांच पर स्विच करते हैं, नया कमिट खो जाएगा।

समाधान: इसे एक नई ब्रांच के रूप में सहेजें

आप जहां हैं वहां एक नई ब्रांच बनाकर इसे हल किया जा सकता है।

1
2


# वर्तमान HEAD की स्थिति पर एक नई ब्रांच बनाएँ और उस पर स्विच करें
$ git checkout -b feature/recovered-work

8. केस स्टडी 5: मर्ज और रिबेस में कन्फ्लिक्ट का समाधान

【स्थिति】 जब मैंने git merge या git rebase चलाया, तो CONFLICT (content) प्रदर्शित हुआ, और प्रक्रिया बाधित हो गई।

मर्ज (Merge) और रिबेस (Rebase) के बीच अंतर

Merge (मर्ज) 2 ब्रांचों के नवीनतम कमिट और एक सामान्य पूर्वज का उपयोग करके 3-वे मर्ज करता है, और एक मर्ज कमिट बनाता है।
Rebase (रिबेस) वर्तमान ब्रांच के कमिट्स को अस्थायी रूप से सेव करता है, और उन्हें लक्ष्य (target) के शीर्ष पर फिर से लागू करता है। इतिहास एक सीधी रेखा बन जाता है।

gitGraph
commit id: "M1"
commit id: "M2"
branch feature
checkout feature
commit id: "F1"
commit id: "F2"
checkout main
commit id: "M3"
merge feature

कन्फ्लिक्ट का समाधान कैसे करें

जिन फ़ाइलों में कन्फ्लिक्ट है उनमें निम्नलिखित मार्कर डाले गए हैं:

1
2
3
4
5


<<<<<<< HEAD
const apiUrl = "https://api.production.example.com";
=======
const apiUrl = "https://api.staging.example.com";
>>>>>>> feature/new-api

समाधान की प्रक्रिया अत्यंत सरल है।

मार्कर्स को हटाएँ और सही कोड में ठीक करें।

1
2
3


const apiUrl = process.env.NODE_ENV === 'production'
 ? "https://api.production.example.com"
 : "https://api.staging.example.com";

हल की गई फ़ाइल को स्टेजिंग में जोड़ें। git add की भूमिका “Git को यह बताना है कि कन्फ्लिक्ट हल हो गया है।”
1

$ git add index.js

प्रक्रिया को पूरा करें।

1
2
3
4
5


# मर्ज के मामले में
$ git commit -m "Resolve merge conflict in index.js"

# रिबेस के मामले में
$ git rebase --continue

यदि आप घबराते हैं, तो आप हमेशा $ git merge --abort या $ git rebase --abort के साथ निरस्त (abort) कर सकते हैं।

9. केस स्टडी 6: कमिट इतिहास बहुत गंदा है! `git rebase -i`

【स्थिति】 कई छोटे कमिट्स हैं जैसे “टाइपो ठीक किया”, “फिर से ठीक किया”, “टेस्ट जोड़ा”, आदि। यदि मैं इसे इसी तरह main में मर्ज करता हूं, तो इतिहास गंदा हो जाएगा।

समाधान: इंटरएक्टिव रिबेस

git rebase -i (interactive) का उपयोग करके, आप पिछले कमिट्स के क्रम को पुनर्व्यवस्थित कर सकते हैं, कई कमिट्स को एक (squash) में जोड़ सकते हैं, या कमिट संदेशों को संशोधित कर सकते हैं।

1
2


# पिछले 3 कमिट्स को व्यवस्थित करें
$ git rebase -i HEAD~3

संपादक (editor) खुल जाएगा और निम्न प्रदर्शित करेगा:

1
2
3


pick 1a2b3c4 टाइपो ठीक किया
pick 2b3c4d5 फिर से ठीक किया
pick 3c4d5e6 टेस्ट जोड़ा

इसे इस प्रकार फिर से लिखें:

1
2
3


pick 1a2b3c4 फीचर X लागू किया
squash 2b3c4d5 फिर से ठीक किया
squash 3c4d5e6 टेस्ट जोड़ा

जब आप इसे सहेजते हैं और बंद करते हैं, तो ये 3 कमिट खूबसूरती से एक में मिल जाएंगे।

10. केस स्टडी 7: मुझे नहीं पता कि बग कब पेश किया गया था! `git bisect`

【स्थिति】 वर्तमान main ब्रांच में एक बग है, लेकिन 1 महीने पहले रिलीज के समय यह सामान्य था। मैं यह पता लगाना चाहता हूं कि किस कमिट ने बग पेश किया, लेकिन 100 से अधिक कमिट हैं और इसे मैन्युअल रूप से करना असंभव है!

समाधान: बाइनरी सर्च के साथ बग की पहचान करना

Git में एक अंतर्निहित उपकरण है जो गणितीय बाइनरी सर्च (Binary Search) के माध्यम से उस कमिट को ढूंढता है जिसने बग पेश किया था। चूँकि जटिलता $\mathcal{O}(\log N)$ है, भले ही 1000 कमिट हों, इसे लगभग 10 परीक्षणों में पहचाना जा सकता है।

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# खोज शुरू करें
$ git bisect start

# वर्तमान कमिट में एक बग है (bad)
$ git bisect bad

# 1 महीने पहले (उदाहरण के लिए हैश a1b2c3d है) सामान्य था (good)
$ git bisect good a1b2c3d

# Git स्वचालित रूप से मध्यवर्ती कमिट्स की जांच करेगा, इसलिए परीक्षण चलाएँ
# यदि परीक्षण सफल होता है:
$ git bisect good
# यदि परीक्षण विफल रहता है:
$ git bisect bad

बस इसे दोहराने से, Git आपको सटीक रूप से बता देगा कि “यह कमिट पहला Bad कमिट है।” पूरा होने पर, मूल स्थिति में वापस आने के लिए $ git bisect reset का उपयोग करें।

11. अंतिम सुरक्षा जाल: `git reflog`

Git में हर “गलती” के लिए अंतिम गुप्त तकनीक git reflog है। Git कुछ समय के लिए सभी स्थानीय संचालन इतिहास (HEAD गति इतिहास) रिकॉर्ड करता है। भले ही आप किसी ब्रांच को हटा दें या गलत तरीके से रीसेट कर दें, आप git reflog के साथ पिछले हैश को ढूंढ सकते हैं, और केवल git reset --hard का उपयोग करके उसे पुनर्प्राप्त कर सकते हैं।

1
2
3


$ git reflog
9f8a7b6 (HEAD -> main) HEAD@{0}: commit: Add new feature
1a2b3c4 HEAD@{1}: reset: moving to HEAD~1

12. निष्कर्ष

हमने Git शुरुआती लोगों द्वारा की जाने वाली आम गलतियों, उनके पीछे Git के तंत्र और समाधानों को बहुत विस्तार से समझाया है। गलत ब्रांच में कमिट करना, पुश किए गए कमिट को रद्द करना, Stash का उपयोग करना, Detached HEAD से वापस आना, और कन्फ्लिक्ट्स को हल करना। इन सभी में, यह कल्पना करना महत्वपूर्ण है कि “पर्दे के पीछे Git किन ऑब्जेक्ट्स और पॉइंटर्स में हेरफेर कर रहा है।”

सख्त Diff एल्गोरिदम जो गणितीय सूत्रों में व्यक्त किया जा सकता है, फ़ाइलों के बीच अंतर की गणना करता है, और क्रिप्टोग्राफ़िक हैश फ़ंक्शन इतिहास की अखंडता (integrity) सुनिश्चित करते हैं। यदि आप इस सुंदर डिज़ाइन दर्शन को समझते हैं, तो आप महसूस करेंगे कि Git कभी भी “अज्ञात ब्लैक बॉक्स” नहीं है, बल्कि आपके सोर्स कोड की सुरक्षा करने वाली सबसे मजबूत ढाल है।

अगली बार जब आप सोचें “मैंने गलती कर दी!”, तो टर्मिनल को जल्दी में बंद न करें, एक गहरी सांस लें और git status टाइप करें। Git निश्चित रूप से आपको पुनर्प्राप्ति (recovery) के लिए संकेत देगा।

Version Control on kenji.blog

【Git कमांड】rebase और merge के बीच का अंतर, और व्यवहार में इनका सही उपयोग कैसे करें

1. परिचय: “merge या rebase” हमेशा एक बहस का विषय क्यों है?

2. Git की आंतरिक संरचना: कमिट हैश और ऑब्जेक्ट मॉडल

2.1 कमिट हैश के क्रिप्टोग्राफ़िक गुण

3. ग्राफ़ थ्योरी और DAG: Git इतिहास का गणितीय मॉडल

3.1 DAG (डायरेक्टेड एसाइक्लिक ग्राफ़) क्या है?

3.2 टोपोलॉजिकल सॉर्ट और इतिहास का क्रम

4. git merge का मैकेनिज़्म और प्रकार

4.1 Fast-Forward मर्ज (–ff)

4.2 Non-Fast-Forward मर्ज (–no-ff)

4.3 3-वे मर्ज (3-Way Merge) एल्गोरिदम

5. git rebase का मैकेनिज़्म और इतिहास का पुनर्निर्माण

5.1 Rebase के पीछे की कार्यप्रणाली

5.2 इंटरएक्टिव रिबेस (Interactive Rebase)

6. रिबेस का सुनहरा नियम (The Golden Rule of Rebase)

6.1 सार्वजनिक इतिहास को रिबेस क्यों नहीं करना चाहिए?

7. कॉन्फ्लिक्ट (टकराव) का समाधान और git rebase –continue

7.1 Merge में कॉन्फ्लिक्ट का समाधान

7.2 Rebase में कॉन्फ्लिक्ट का समाधान

8. व्यावहारिक रूप से सही उपयोग (वर्कफ़्लो प्रैक्टिस)

8.1 [परिदृश्य 1] स्थानीय कार्य इतिहास को व्यवस्थित करना (Rebase का उपयोग)

8.2 [परिदृश्य 2] नवीनतम main ब्रांच के साथ अपडेट रहना (Rebase का उपयोग)

8.3 [परिदृश्य 3] पूर्ण हुए फीचर को एकीकृत करना (Merge का उपयोग)

9. निष्कर्ष (सारांश)

Git शुरुआती लोगों द्वारा की जाने वाली आम गलतियाँ और समाधान कमांड (कन्फ्लिक्ट रिज़ॉल्यूशन आदि)

Git शुरुआती लोगों द्वारा की जाने वाली आम गलतियाँ और समाधान कमांड (कन्फ्लिक्ट रिज़ॉल्यूशन आदि)

1. परिचय: हम Git में गलतियाँ क्यों करते हैं?

2. Git की गहराई: .git डायरेक्टरी की आंतरिक संरचना को समझना

2.1 ऑब्जेक्ट मॉडल: Blob, Tree, Commit

2.2 HEAD और संदर्भ (Refs) की वास्तविकता

3. गणित से Git को समझना: Diff एल्गोरिदम और हैश फ़ंक्शन

3.1 Myers का Diff एल्गोरिदम

3.2 Patience Diff और Histogram Diff

3.3 SHA-1 और टक्कर की संभावना (Collision Probability)

4. केस स्टडी 1: गलत ब्रांच में कमिट कर दिया!

समाधान: git reset और ब्रांच बनाना

आरेख: अंदर क्या हुआ?

5. केस स्टडी 2: पुश किए गए कमिट को रद्द करना चाहता हूँ!

समाधान 1: इतिहास को रद्द करने के लिए git revert (अनुशंसित और सुरक्षित)

समाधान 2: इतिहास के साथ छेड़छाड़ करने के लिए git push --force-with-lease

6. केस स्टडी 3: काम के बीच में किसी अन्य ब्रांच पर स्विच करना चाहता हूँ (Stash का जादू)

समाधान: git stash के साथ आश्रय लेना

7. केस स्टडी 4: “Detached HEAD” अवस्था का डर

Detached HEAD का तंत्र

समाधान: इसे एक नई ब्रांच के रूप में सहेजें

8. केस स्टडी 5: मर्ज और रिबेस में कन्फ्लिक्ट का समाधान

मर्ज (Merge) और रिबेस (Rebase) के बीच अंतर

कन्फ्लिक्ट का समाधान कैसे करें

9. केस स्टडी 6: कमिट इतिहास बहुत गंदा है! git rebase -i

समाधान: इंटरएक्टिव रिबेस

10. केस स्टडी 7: मुझे नहीं पता कि बग कब पेश किया गया था! git bisect

समाधान: बाइनरी सर्च के साथ बग की पहचान करना

11. अंतिम सुरक्षा जाल: git reflog

12. निष्कर्ष

2. Git की गहराई: `.git` डायरेक्टरी की आंतरिक संरचना को समझना

समाधान: `git reset` और ब्रांच बनाना

समाधान 1: इतिहास को रद्द करने के लिए `git revert` (अनुशंसित और सुरक्षित)

समाधान 2: इतिहास के साथ छेड़छाड़ करने के लिए `git push --force-with-lease`

समाधान: `git stash` के साथ आश्रय लेना

9. केस स्टडी 6: कमिट इतिहास बहुत गंदा है! `git rebase -i`

10. केस स्टडी 7: मुझे नहीं पता कि बग कब पेश किया गया था! `git bisect`

11. अंतिम सुरक्षा जाल: `git reflog`