तपाई कहिले र कसरी Git इतिहास पुनः लेख्नु पर्छ?

Question

Accepted Answer

Git ले तपाइलाई **इतिहास पुनः लेख्न** दिन्छ — commits सँशोधन, rebase गर्न, squash गर्न, वा हटाउन — commits सफा गर्न वा समस्याहरु ठीक गर्न। यो शक्तिशाली छ तर सावधानीपूर्वक गर्नु पर्छ: **साझा** इतिहास पुनः लेख्दा गम्भीर समस्याहरु हुन्छन्, त्यसैले यसको वरिपरि नियमहरु महत्त्वपूर्ण छन्। ## इतिहास पुनः लेख्ने तरिकाहरु ```text git commit --amend → modify the most recent commit (message or content) git rebase -i → squash, reword, reorder, edit, drop commits (interactive) git rebase → replay commits onto another base (linear history) git reset → move the branch pointer (discard/uncommit) git filter-repo → rewrite MANY commits (remove a file/secret from all history) → All of these change commit HASHES (rewriting = creating new, different commits). ``` ## सुनको नियम ```text ⚠️ NEVER rewrite history that has been PUSHED/SHARED (that others may have): → rewriting changes commit hashes → your history DIVERGES from collaborators' → they'll have the old commits; pulls create duplicates/conflicts; chaos ensues → forces everyone to painfully reconcile → a serious disruption ✓ Rewrite ONLY local, unpushed commits (cleanup before sharing). ✗ On shared branches → use REVERT (a new undoing commit) instead, which is safe. ``` ## पुनः लेख्ने वैध प्रयोगहरु (स्थानीय) ```text ✓ Clean up messy WIP commits before opening a PR (squash, reword) → clean history ✓ Fix a mistake in the last commit (amend) before pushing ✓ Keep a feature branch linear/up-to-date with main (rebase) before sharing ✓ Remove a SECRET accidentally committed (filter-repo) — though if it was PUSHED, the secret must be ROTATED (it's already exposed; rewriting alone isn't enough) ``` ## यदि तपाइ साझा इतिहास पुनः लेख्नु पर्छ (दुर्लभ) ```text → COORDINATE with the whole team (everyone stops, re-syncs) → Force-push carefully: git push --force-with-lease (safer than --force — checks first) → Everyone must reset/re-clone to the rewritten history → Do this only when truly necessary (e.g. purging a leaked secret) and with agreement. ``` ## यो किन महत्त्वपूर्ण छ Git इतिहास कहिले र कसरी पुनः लेख्ने भनेर बुझ्नु महत्त्वपूर्ण वरिष्ठ-स्तरको ज्ञान हो किनभने इतिहास पुनः लेख्नु **शक्तिशाली तर खतरनाक** छ, र नियमहरु बुझ्नु — विशेष गरी साझा इतिहासको वरिपरि — गम्भीर समस्याहरु रोक्छ र वैध सफाइ सक्षम गर्छ। **पुनः लेख्ने तरिकाहरु** जान्नु (अन्तिम commit को लागि amend, squashing/rewording/reordering को लागि interactive rebase, linear इतिहासको लागि rebase, reset, ठूला आकारको परिवर्तनको लागि filter-repo) र कि तिनले सबै **commit hashes परिवर्तन** गर्छन् (नयाँ commits सिर्जना गर्छन्) भनेर जान्नु आधार हो। सबैभन्दा महत्त्वपूर्ण, **सुनको नियम — कहिले पनि साझा/pushed इतिहास पुनः लेख्न नहोस्** — आवश्यक छ किनभने पुनः लेख्नु hashes परिवर्तन गर्छ, तपाइको इतिहास सहकर्मीहरुको साथ diverge गर्दछ (जो अझैपनि पुरानो commits छन्), duplicates, conflicts, र पीडादायक reconciliation को कारण बनाउछ; साझा इतिहास पुनः लेख्नु एक गम्भीर विघ्न हो जो यो नियमले रोक्छ, **revert** (एक सुरक्षित नयाँ undoing commit) साझा branches को लागि सही दृष्टिकोण हो। **वैध स्थानीय प्रयोगहरु** (PR अघि WIP commits सफा गर्नु, push गर्न अघि गल्तीहरु सँशोधन गर्नु, साझा गर्न अघि linear रहन rebase गर्नु — सबै स्थानीय, unpushed commits मा) बुझ्नु स्पष्ट गर्छ कहिले पुनः लेख्नु उपयुक्त र मूल्यवान छ। एक महत्त्वपूर्ण सुरक्षा nuance: यदि एक **गोप्य pushed र committed थियो**, यसलाई हटाउन इतिहास पुनः लेख्नु अपर्याप्त छ — गोप्य पहिले देखै उजागर भइसकेको छ र **rotated** हुनु पर्छ (एक महत्त्वपूर्ण वास्तविक-विश्व सुरक्षा बिन्दु)। **साझा इतिहासको दुर्लभ आवश्यक पुनः लेख्न** कसरी सँभाल्ने भनेर जान्नु (टीम समन्वय, `--force` को सट्टा `--force-with-lease`, सबै पुनः sync गर्दै) परिपक्व निर्णय को प्रतिबिम्बित गर्छ। इतिहास पुनः लेख्नु शक्तिशाली छ तर साझा इतिहासमा गलत प्रयोग गर्दा गम्भीर समस्याहरु निर्माण गर्छ, र सुनको नियम, वैध प्रयोगहरु, र सुरक्षित अभ्यासहरु बुझ्नु यसलाई जिम्मेवारीपूर्वक प्रयोग गर्न आवश्यक छ, Git इतिहास कहिले र कसरी पुनः लेख्ने भनेर बुझ्नु महत्त्वपूर्ण वरिष्ठ-स्तरको ज्ञान हो — एक विषय जहाँ सुरक्षा नियमहरु (विशेष गरी कहिले पनि साझा इतिहास पुनः लेख्न नहोस्) बुझ्नु वास्तविक सहयोग आपदाहरु रोक्छ, वरिष्ठ भूमिकामा Git सँग टीमहरुमा काम गर्न अपेक्षा गरिएको निर्णय प्रतिबिम्बित गर्छ।