rebase र merge बीचको फरक के हो?

Question

Accepted Answer

दुवै **merge** र **rebase** ले एक शाखाबाट अर्को शाखामा परिवर्तनहरू एकीकृत गर्छ, तर तिनीहरूले यसलाई फरक तरिकाले गर्छन्: merge ले **इतिहास सुरक्षित राखता** merge commit संग, जबकि rebase ले **इतिहास पुनः लेख्न** एक रैखिक अनुक्रम बनाउन। प्रत्येक कहिले प्रयोग गर्ने भनेर बुझ्न महत्त्वपूर्ण छ।

## Merge — इतिहास सुरक्षित राखता (एकीकृत गर्छ)

```text
main:     A───B───C───────M     ← M is a MERGE COMMIT (two parents)
                  \       /
feature:           D───E
→ git merge feature: creates M combining the branches
  ✓ Preserves the actual history (shows the branch existed, when it merged)
  ✗ History has merge commits (can look cluttered with many merges)
```

## Rebase — रैखिक इतिहासको लागि पुनः लेख्न (दोहोरिनु)

```text
BEFORE:  main: A───B───C    feature: A───B───D───E
AFTER rebase feature onto main:
         main: A───B───C    feature: A───B───C───D'───E'
→ git rebase main (on feature): REPLAYS feature's commits (D,E) ON TOP of main's latest (C)
  ✓ LINEAR, clean history (no merge commits) — as if feature was built on current main
  ✗ REWRITES commits (D→D', E→E' are NEW commits with new hashes)
```

Rebase ले **अग्रसर गर्छ** तपाईंको शाखाका commits लाई अर्को शाखाको tip बाट सुरु गर्न, नयाँ commits सिर्जना गर्छ — एक स्वच्छ, रैखिक इतिहास उत्पादन गर्छ।

## Rebasing को स्वर्णिम नियम

```text
⚠️ NEVER rebase commits that have been PUSHED/SHARED (public history):
  → rebasing rewrites commits (new hashes) → diverges from what others have
  → causes serious confusion and conflicts for collaborators
→ Rebase only LOCAL, unpushed commits. Merge for integrating shared/public branches.
```

## प्रत्येक कहिले प्रयोग गर्ने

```text
MERGE  → integrating shared branches; preserving true history; team default for merging
  features to main (often via pull requests). Safe, non-destructive.
REBASE → cleaning up LOCAL commits before sharing; keeping a feature branch up-to-date
  with main (linear); achieving clean linear history. On local/private commits only.
→ Common workflow: rebase locally to tidy up, then merge (or PR) into main.
```

## किन यो महत्त्वपूर्ण छ

Rebase र merge बीचको फरक बुझ्न महत्त्वपूर्ण छ किनकि दुवै परिवर्तनहरू एकीकृत गर्छन् तर इतिहासमा मौलिक रूपमा फरक प्रभाव पारछन्, र सही तरिकाले (र सुरक्षित रूपमा) छनोट गर्नु महत्त्वपूर्ण छ, त्यसैले यो मूल्यवान Git ज्ञान हो जुन सामान्यतः छलफल गरिन्छ।

मूल भिन्नता — **merge ले इतिहास सुरक्षित राखता** (एक merge commit सिर्जना गर्छ जसले शाखाहरू एकीकृत हुनु रेकर्ड गर्छ, साँचो विकास इतिहास राख्छ) जबकि **rebase ले इतिहास पुनः लेख्न** (अर्को शाखाको tip मा commits दोहोरिनु गर्छ एक स्वच्छ, रैखिक अनुक्रम बनाउन जस्तो कि काम नयाँ कोडमा गरिएको थियो) — प्रकल्पको इतिहास कस्तो देखिन्छ र पढिन्छ भनेर प्रभाव पारछ।

ट्रेड-अफ्स बुझ्न (merge: सटीक तर सम्भवत merge commits संग अव्यवस्थित; rebase: स्वच्छ र रैखिक तर commits पुनः लेख्न) सहायता गर्छ कि साँचो इतिहास वा रैखिक स्वच्छता को आधारमा छनोट गर्न।

सबैभन्दा गुरुत्वपूर्ण रूपमा, **rebasing को स्वर्णिम नियम** बुझ्न — **कहिले पनि commits लाई rebase गर्नुहुँदैन जो pushed/shared भएका छन्** — आवश्यक छ किनकि rebasing ले commits पुनः लेख्न (नयाँ hashes दिई), त्यसैले rebasing shared इतिहास अलग हुन्छ जो सहकर्मीहरुसँग छ, गम्भीर भ्रम र द्वन्द्व सिर्जना गर्छ; rebase केवल स्थानीय, unpushed commits को लागि सुरक्षित छ।

यो सुरक्षा नियम महत्त्वपूर्ण छ र उल्लङ्घन गरेको अवस्थामा समस्याको सामान्य स्रोत हो।

**प्रत्येक कहिले प्रयोग गर्ने** बुझ्न (merge को लागि shared शाखाहरू एकीकृत गर्न र इतिहास सुरक्षित राख्न, सामान्यतः pull requests मार्फत features merge गर्नको लागि टीम डिफल्ट; rebase को लागि साझा गर्न अघि स्थानीय commits सफा गर्न वा एक feature शाखा रैखिकतामा अप-टु-डेट राख्न — केवल स्थानीय commits मा) ध्वनि Git अभ्यास प्रतिबिम्बित गर्छ।

परिवर्तनहरू एकीकृत गर्नु आधारभूत छ र merge-vs-rebase छनोट (यसको इतिहास र सुरक्षा निहितार्थ संग) एक बारम्बार निर्णय र अन्तरवार्ता विषय छ, भिन्नता बुझ्न — तिनीहरुको इतिहासमा प्रभाव, गुरुत्वपूर्ण स्वर्णिम नियम, र प्रत्येक कहिले प्रयोग गर्ने — मूल्यवान, व्यावहारिक रूपमा-महत्त्वपूर्ण Git ज्ञान हो जो स्वच्छ इतिहास सुरक्षित रूपमा राख्न केन्द्रीय छ र यो सामान्यतः-चर्चा गरिने भिन्नता हर विकासकर्ताले बुझ्न पनि।