Git में फ़ाइल का हिस्सा कैसे commit करें
छोटे, केंद्रित Git commits में बदलावों को बाँटना debugging, code review, और सुरक्षित rollbacks के लिए महत्वपूर्ण माना जाता है, लेकिन कई developers या तो पूरे pull requests को squash कर देते हैं या असंबंधित edits को एक साथ जोड़ देते हैं। Commenters atomic, हमेशा-green commits को लागू करने वाले workflows की तुलना उन workflows से करते हैं जो प्रति-PR एक commit वाली history को पसंद करते हैं, और वे file के हिस्सों को stage करने के लिए command-line tools जैसे `git add -p` बनाम GUIs और IDE integrations (VS Code, JetBrains, Magit, lazygit, आदि) के गुण-दोष पर बहस करते हैं। कुल मिलाकर, बातचीत यह दर्शाती है कि partial commits और thoughtful history shaping में महारत professional software development का एक मूल, लेकिन अक्सर उपेक्षित, skill है।
Commit granularity और अच्छे history का मूल्य
- कई लोग तर्क देते हैं कि बदलावों को छोटे, सुसंगत commits में बाँटना कम आँका गया है और बहुत उपयोगी है, खासकर debugging और outages को revert करने के लिए।
- दूसरे लोग नोट करते हैं कि व्यवहार में कुछ teams शायद ही कभी specific commits revert करती हैं; इसके बजाय वे deployments वापस लेती हैं या एक नया “fix” commit लिखती हैं।
- इस बात पर मजबूत सहमति है कि अच्छे commits बनाना (और Git अच्छी तरह सीखना) एक कम सराहा गया skill है, जो software quality बनाम “just ship it” productivity जैसी व्यापक चिंताओं से जुड़ा है।
Squash बनाम incremental commits, और reverts
- एक पक्ष हर PR पर squash-merge को पसंद करता है:
- PR review की unit है, न कि हर intermediate commit।
- इससे linear, bisectable history मिलती है, बिना टूटे हुए intermediate states के।
- Squashes “fix typo / actually works” जैसे noisy commits हटाने और एक अच्छा single message फिर से लिखने में मदद करते हैं।
- दूसरा पक्ष non-squashed, atomic commits को पसंद करता है:
- हर commit build होना चाहिए और tests pass करने चाहिए, ताकि bisect और fine-grained reverts आसान हों।
- Squashing महत्वपूर्ण context खो सकता है (जैसे file moves और refactors) और गंभीर bug-hunting को कठिन बना देता है।
- कुछ लोग बताते हैं कि अगर squashing से unreadable blobs बनते हैं, तो शायद PR बहुत बड़ा है या उसमें अलग-अलग concerns मिला दिए गए हैं।
- merge strategies पर एक अलग धारा:
- कुछ लोग feature branches पर rebase, लेकिन main branch पर merge commits इस्तेमाल करने की सलाह देते हैं, जिससे grouped PR commits और linear per-commit history दोनों मिलते हैं (
--first-parentबनाम--no-merges)। - दूसरे लोग individual bad commits खोजने के बजाय बस last good release पर लौट जाते हैं।
- कुछ लोग feature branches पर rebase, लेकिन main branch पर merge commits इस्तेमाल करने की सलाह देते हैं, जिससे grouped PR commits और linear per-commit history दोनों मिलते हैं (
Partial commits के लिए tools और workflows
- CLI बनाम GUI/TUI पर कड़ा विभाजन:
- CLI समर्थक:
git add -p/--patch, औरgit resetतथाgit checkoutमें इसके cousins; इन्हें तेज़, सर्वव्यापी, और careful review के लिए अच्छा माना जाता है। “split” और “edit” जैसे options fine-grained staging, यहाँ तक कि single-line edits, की अनुमति देते हैं। - आलोचक:
git add -pके interactive UI को confusing, context-poor, और GUIs में line-based selection से inferior मानते हैं।
- CLI समर्थक:
- लोकप्रिय alternatives जिनका ज़िक्र हुआ:
- TUI/CLI:
lazygit,tig,stgit,git gui,git-cola,git-crecord,magit(Emacs),vim-fugitive. - IDE/GUI: VS Code (“stage selected ranges”, लेकिन पहले CRLF bugs के साथ), JetBrains changelists, GitHub Desktop, SourceTree, Sublime Merge.
- TUI/CLI:
- कई लोग नोट करते हैं कि modern IDEs में partial staging आसान और ergonomic है, और अलग-अलग tools अलग workflows के लिए उपयुक्त हैं।
Quality बनाम speed का व्यापक तनाव
- कुछ लोग तर्क देते हैं कि “productive” होना अक्सर code और history quality की कीमत पर तेज़ी से ship करना होता है।
- दूसरे लोग “crappy” protocols और code की long-term cost पर ज़ोर देते हैं, जो व्यापक रूप से adopt हो जाने के बाद बदलना कठिन हो जाते हैं।