आपको Git history कब और कैसे rewrite करनी चाहिए?

Question

Accepted Answer

Git आपको **history rewrite करने** देता है — commits को amend, rebase, squash, या remove करना — commits को साफ़ करने या समस्याओं को ठीक करने के लिए। यह शक्तिशाली है लेकिन सावधानी से किया जाना चाहिए: **साझा** history को rewrite करना गंभीर समस्याएँ पैदा करता है, इसलिए इसके आसपास के नियम महत्वपूर्ण हैं। ## History rewrite करने के तरीके ```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. ``` ## Rewriting के वैध उपयोग (स्थानीय) ```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) ``` ## यदि आपको साझा history को rewrite करना ही पड़े (दुर्लभ) ```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 history को कब और कैसे rewrite करना है यह समझना महत्वपूर्ण senior-स्तरीय ज्ञान है क्योंकि history rewriting **शक्तिशाली लेकिन खतरनाक** है, और नियमों को समझना — विशेष रूप से साझा history के आसपास — वैध cleanup को सक्षम करते हुए गंभीर समस्याओं को रोकता है। **rewrite करने के तरीकों** को जानना (अंतिम commit के लिए amend, squashing/rewording/reordering के लिए interactive rebase, linear history के लिए rebase, reset, बड़े पैमाने पर परिवर्तनों के लिए filter-repo) और यह कि वे सभी **commit hashes बदलते हैं** (नए commits बनाते हुए) नींव है। सबसे महत्वपूर्ण रूप से, **स्वर्णिम नियम — साझा/pushed history को कभी rewrite न करें** — को समझना आवश्यक है क्योंकि rewriting hashes को बदलता है, जिससे आपकी history collaborators' (जिनके पास अभी भी पुराने commits हैं) से अलग हो जाती है, जो duplicates, conflicts, और दर्दनाक reconciliation की ओर ले जाती है; साझा history को rewrite करना एक गंभीर व्यवधान है जिसे यह नियम रोकता है, **revert** (एक सुरक्षित नया undoing commit) के साथ साझा branches के लिए सही दृष्टिकोण होने के बजाय। **वैध स्थानीय उपयोगों** को समझना (PR से पहले WIP commits को साफ़ करना, push से पहले गलतियों को amend करना, साझा करने से पहले linear रहने के लिए rebase करना — सभी स्थानीय, unpushed commits पर) यह स्पष्ट करता है कि rewriting कब उपयुक्त और मूल्यवान है। एक महत्वपूर्ण security बारीकी: यदि एक **secret committed और pushed किया गया**, तो इसे हटाने के लिए history को rewrite करना अपर्याप्त है — secret पहले से ही उजागर है और इसे **rotate** किया जाना चाहिए (एक महत्वपूर्ण वास्तविक-दुनिया security बिंदु)। **साझा history के दुर्लभ आवश्यक rewrite को संभालना** जानना (team coordination, `--force` के बजाय `--force-with-lease`, सभी का re-sync) परिपक्व निर्णय को दर्शाता है। चूँकि history rewriting शक्तिशाली है लेकिन साझा history पर गलत उपयोग करने पर गंभीर समस्याएँ पैदा करता है, और चूँकि स्वर्णिम नियम, वैध उपयोगों, और सुरक्षित प्रथाओं को समझना इसे ज़िम्मेदारी से उपयोग करने के लिए आवश्यक है, Git history को कब और कैसे rewrite करना है यह समझना महत्वपूर्ण senior-स्तरीय ज्ञान है — एक ऐसा विषय जहाँ सुरक्षा नियमों को समझना (विशेष रूप से साझा history को कभी rewrite न करना) वास्तविक collaboration आपदाओं को रोकता है, teams में Git के साथ काम करने वाली senior भूमिकाओं के लिए अपेक्षित निर्णय को दर्शाता है।