कमिट करना — यह क्या है, फ़ॉर्मेटिंग नियम और Git के साथ काम करना
कमिट करना Git वर्जन कंट्रोल सिस्टम में चेंजेज़ को सेव करने की क्रिया है, जो प्रोजेक्ट हिस्ट्री में एक सेव पॉइंट बनाती है। प्रत्येक कमिट में हैश, लेखक, तारीख और चेंजेज़ का विवरण शामिल होता है। GitHub Octoverse 2024 के अनुसार, दुनिया भर में प्रतिदिन 50 मिलियन से अधिक कमिट बनाए जाते हैं। Commit वर्जनिंग के साथ काम करने की मूल इकाई है, जिसके बिना आधुनिक सॉफ़्टवेयर डेवलपमेंट की कल्पना नहीं की जा सकती।
मुख्य बिंदु
- कमिट करना — किए गए संशोधनों के विवरण के साथ Git में चेंजेज़ सेव करना
- प्रत्येक कमिट में एक अद्वितीय हैश, लेखक, तारीख और संदेश होता है
- परमाणुकता — प्रत्येक कमिट में एक तार्किक परिवर्तन होता है
- कमिट संदेश को इस प्रश्न का उत्तर देना चाहिए कि परिवर्तन क्यों किया गया
- कमिट को git amend और rebase के माध्यम से पूरक, रद्द और संयोजित किया जा सकता है
Git में कमिट क्या है
Git में कमिट एक ऑब्जेक्ट है जो किसी विशिष्ट समय पर प्रोजेक्ट फ़ाइलों की स्थिति को संग्रहीत करता है। प्रत्येक कमिट में सभी ट्रैक की गई फ़ाइलों का स्नैपशॉट, पैरेंट कमिट का संदर्भ और मेटाडेटा होता है। अन्य वर्जन कंट्रोल सिस्टम के विपरीत, Git कंटेंट-एड्रेसेबल स्टोरेज का उपयोग करता है — प्रत्येक ऑब्जेक्ट को उसकी सामग्री के SHA-1 हैश द्वारा पहचाना जाता है।
जब डेवलपर चेंजेज़ कमिट करता है, Git एक कमिट ऑब्जेक्ट बनाता है जो संग्रहीत करता है: ट्री ऑब्जेक्ट (फ़ाइल संरचना), पैरेंट कमिट हैश, लेखक, कमिटर, तारीख और संदेश। यह ऑब्जेक्ट अपरिवर्तनीय है — बनने के बाद, कमिट को उसके हैश को बदले बिना संशोधित नहीं किया जा सकता। यह अपरिवर्तनीयता प्रोजेक्ट हिस्ट्री की अखंडता सुनिश्चित करती है।
bash
# चेंजेज़ स्टेज करें और कमिट करें
git add index.html style.css
git commit -m "Fix responsive layout on mobile devices"
# कमिट विवरण देखें
git log --oneline -3
git show HEAD
# सभी चेंजेज़ स्टेज करें और एक चरण में कमिट करें
git commit -a -m "Update dependencies to latest versions"कमिट एक निर्देशित अचक्रीय ग्राफ़ (DAG) बनाते हैं, जहाँ प्रत्येक नया कमिट पिछले एक को संदर्भित करता है। यह हिस्ट्री में नेविगेट करने, चेंजेज़ को रिवर्ट करने और कोडबेस के विकास का विश्लेषण करने की अनुमति देता है। Git DAG की संरचना को समझना कमिट के साथ उन्नत कार्य का आधार है।
चेंजेज़ को सही तरीके से कैसे कमिट करें
Git में कमिट प्रक्रिया दो चरणों से मिलकर बनी है: स्टेजिंग एरिया (इंडेक्स) में चेंजेज़ जोड़ना और कमिट बनाना। स्टेजिंग एरिया डेवलपर को यह चुनने की अनुमति देता है कि कमिट में कौन से विशिष्ट चेंजेज़ शामिल होंगे, भले ही वर्किंग डायरेक्टरी में कई फ़ाइलें बदली गई हों।
परमाणुकता का नियम एक अच्छे कमिट का मुख्य सिद्धांत है। प्रत्येक कमिट में एक तार्किक परिवर्तन होना चाहिए। यदि डेवलपर बग ठीक करता है और कोड रिफ़ैक्टर करता है — ये दो अलग-अलग कमिट होने चाहिए। परमाणु कमिट कोड रिव्यू, चेंजेज़ रोलबैक और हिस्ट्री विश्लेषण को सरल बनाते हैं।
कमिट करने से पहले, जाँच करना उचित है: क्या कोड में डीबग आउटपुट, कमेंट किए गए ब्लॉक या आकस्मिक चेंजेज़ बचे हैं। इसके लिए git diff --cached कमांड का उपयोग किया जाता है, जो दिखाता है कि कमिट में वास्तव में क्या शामिल होगा। git status के माध्यम से अतिरिक्त जाँच स्टेजिंग एरिया में फ़ाइलों की सूची प्रदर्शित करती है।
- चेंजेज़ जाँचें — git diff --cached दिखाता है कि कमिट में क्या शामिल होगा
- गुणवत्ता जाँचें — कोड को कमिट से पहले लिंटर और टेस्ट पास करना चाहिए
- संदेश लिखें — परिवर्तन के उद्देश्य का स्पष्ट विवरण
- स्टेज की गई फ़ाइलें जाँचें — git status फ़ाइल सूची की पुष्टि करता है
कमिट संदेश लिखने के नियम
कमिट संदेश भविष्य के डेवलपर्स के लिए परिवर्तन का दस्तावेज़ीकरण है। एक अच्छा संदेश प्रश्नों का उत्तर देता है: क्या बदला गया और क्यों। Conventional Commits सम्मेलन (Angular टीम, 2016) कई परियोजनाओं के लिए मानक बन गया है और प्रारूप को परिभाषित करता है: प्रकार(क्षेत्र): विवरण।
| प्रकार | उद्देश्य | उदाहरण |
|---|---|---|
| feat | नई कार्यक्षमता | feat(api): add user registration endpoint |
| fix | बग फिक्स | fix(auth): resolve token refresh issue |
| refactor | व्यवहार बदले बिना रिफ़ैक्टरिंग | refactor(core): extract payment validator |
| docs | दस्तावेज़ीकरण | docs(readme): update installation guide |
| test | परीक्षण जोड़ना | test(cart): add unit tests for checkout |
एक अच्छे कमिट संदेश में शीर्षक (50 वर्ण तक) और मुख्य भाग (वैकल्पिक, प्रति पंक्ति 72 वर्ण तक) होता है। शीर्षक अनिवार्य मूड में लिखा जाता है: “Add” न कि “Added” या “Adds”। Capitalization और शीर्षक के अंत में पूर्ण विराम का उपयोग नहीं किया जाता — यह एक अंतरराष्ट्रीय Git सम्मेलन है।
खराब संदेश: “fix things” या “update” — यह जानकारी नहीं देता। एक महीने में, डेवलपर समझ नहीं पाएगा कि वास्तव में क्या और क्यों बदला गया था। अच्छा संदेश: “fix(payment): handle timeout in stripe callback” — तुरंत स्पष्ट हो जाता है कि कहाँ और क्या ठीक किया गया।
कमिट करते समय सामान्य गलतियाँ
डेवलपर, विशेष रूप से शुरुआती, अक्सर कमिट करते समय सामान्य गलतियाँ करते हैं। सबसे आम है बहुत बड़ा कमिट, जिसमें दर्जनों बदलाव मिश्रित होते हैं। ऐसे कमिट को आंशिक रूप से रिवर्ट नहीं किया जा सकता, और कोड रिव्यू यातना बन जाता है।
दूसरी सबसे आम गलती खराब कमिट संदेश है। “fix”, “update”, “changes” या “wip” जैसे संदेश भविष्य के डेवलपर्स को संदर्भ प्रदान नहीं करते। छह महीने में, किसी को याद नहीं रहेगा कि वास्तव में क्या ठीक किया गया था। नियम सरल है: कल्पना करें कि एक साल बाद आप हिस्ट्री देख रहे हैं और एक विशिष्ट बदलाव खोजने की कोशिश कर रहे हैं।
तीसरी गलती बिना कंपाइल या गैर-कार्यशील कोड को कमिट करना है। कमिट के बाद, कोड को कम से कम कंपाइल होना चाहिए। बिल्ड को न तोड़ना साझा ब्रांच में किसी भी कमिट के लिए एक बुनियादी आवश्यकता है। इसके लिए कमिट से पहले बिल्ड और टेस्ट चलाए जाते हैं।
चौथी गलती गोपनीय डेटा को कमिट करना है। API कुंजियाँ, पासवर्ड और टोकन Git हिस्ट्री में नहीं आने चाहिए। यदि कोई रहस्य पहले ही कमिट हो चुका है, तो उसे नए कमिट में हटाना पर्याप्त नहीं है, बल्कि git filter-branch या BFG Repo-Cleaner के माध्यम से पूरी हिस्ट्री से हटाना होगा।
कमिट के साथ काम करने की उन्नत तकनीकें
Git कमिट हिस्ट्री के प्रबंधन के लिए उपकरण प्रदान करता है। सबसे उपयोगी में से एक है git commit --amend, जो अंतिम कमिट को नए चेंजेज़ के साथ पूरक करने या संदेश को ठीक करने की अनुमति देता है। यह सुविधाजनक है यदि डेवलपर फ़ाइल शामिल करना भूल गया या संदेश में टाइपिंग की गलती की।
bash
# अंतिम कमिट संदेश ठीक करें
git commit --amend -m "fix(auth): correct token validation logic"
# अंतिम कमिट में छूटी फ़ाइल जोड़ें
git add missed-file.txt
git commit --amend --no-edit
# अंतिम 3 कमिट के लिए इंटरैक्टिव रीबेस
git rebase -i HEAD~3Interactive rebase हिस्ट्री को फिर से लिखने के लिए एक शक्तिशाली उपकरण है। यह कमिट को संयोजित करने (squash), संदेश बदलने (reword), पुनर्क्रमित करने (reorder) और कमिट हटाने (drop) की अनुमति देता है। हालांकि, rebase हिस्ट्री को बदलता है, इसलिए इसका उपयोग केवल स्थानीय कमिट पर किया जाता है जो अभी तक रिमोट रिपॉजिटरी में पुश नहीं किए गए हैं।
कमिट रद्द करने के दो दृष्टिकोण हैं। git revert एक नया कमिट बनाता है जो पिछले वाले के परिवर्तनों को रद्द करता है — एक सुरक्षित तरीका जो हिस्ट्री को संरक्षित करता है। git reset कमिट को हिस्ट्री से हटाता है — खतरनाक यदि कमिट पहले ही पुश किए जा चुके हैं। टीम डेवलपमेंट में, प्रकाशित कमिट को रद्द करने के लिए केवल git revert का उपयोग किया जाता है।
अक्सर पूछे जाने वाले प्रश्न
Git में कमिट करने का क्या मतलब है?
कमिट करने का मतलब Git में चेंजेज़ के लिए एक सेव पॉइंट बनाना है। कमिट प्रोजेक्ट हिस्ट्री में फ़ाइलों की वर्तमान स्थिति को इस विवरण के साथ रिकॉर्ड करता है कि क्या बदला गया और क्यों। प्रत्येक कमिट में एक अद्वितीय पहचानकर्ता (SHA-1 हैश) होता है और यह परिवर्तनों की अटूट श्रृंखला का हिस्सा है।
Git में कितनी बार कमिट करना चाहिए?
प्रत्येक तार्किक रूप से पूर्ण परिवर्तन के बाद कमिट करने की सिफारिश की जाती है, भले ही वह छोटा हो। इष्टतम आवृत्ति प्रति कार्य या फिक्स 1 कमिट है। हर 5 मिनट में कमिट नहीं करना चाहिए, लेकिन बिना एक भी कमिट के कई दिनों तक चेंजेज़ जमा नहीं करने चाहिए।
परमाणु कमिट क्या है?
परमाणु कमिट में एक तार्किक परिवर्तन होता है — एक कार्य, एक बगफिक्स या एक नई कार्यक्षमता। यह एक कमिट में विभिन्न परिवर्तनों को मिश्रित नहीं करता। परमाणु कमिट के लाभ: रोलबैक की सरलता, स्पष्ट हिस्ट्री और आसान कोड रिव्यू।
Git में कमिट कैसे रद्द करें?
प्रकाशित कमिट को रद्द करने के लिए, git revert <commit-hash> का उपयोग करें — यह एक नया कमिट बनाता है जो परिवर्तनों को रद्द करता है। स्थानीय कमिट के लिए, आप git reset HEAD~1 का उपयोग कर सकते हैं, लेकिन केवल तभी जब कमिट अभी तक पुश नहीं हुआ है। git revert टीम वर्क के लिए सुरक्षित तरीका है।
क्या पहले से बनाए गए कमिट को बदला जा सकता है?
हाँ, रिमोट रिपॉजिटरी में पुश करने से पहले। अंतिम कमिट को बदलने के लिए git commit --amend या कई कमिट को बदलने के लिए git rebase -i का उपयोग करें। पुश करने के बाद, हिस्ट्री बदलने की अनुशंसा नहीं की जाती — इससे अन्य डेवलपर्स को समस्या हो सकती है यदि उन्होंने पहले ही अपने चेंजेज़ पुश कर दिए हैं।
निष्कर्ष
- कमिट करना — किए गए संशोधनों के विवरण के साथ Git में चेंजेज़ सेव करना
- परमाणुकता — एक कमिट = एक तार्किक परिवर्तन
- संदेश — Conventional Commits का उपयोग करें: प्रकार(क्षेत्र): विवरण
- सत्यापन — कोड को कमिट से पहले कंपाइल और टेस्ट पास करना चाहिए
- सुरक्षा — रहस्य कमिट न करें, .gitignore का उपयोग करें
- संशोधन — अंतिम कमिट के लिए amend, कई के लिए rebase -i
- रद्द करना — प्रकाशित के लिए git revert, स्थानीय के लिए git reset
हम एक मोबाइल एप्लिकेशन टर्नकी विकसित करेंगे
IT Sectr 2017 से स्टार्टअप और व्यवसायों के लिए iOS और Android एप्लिकेशन बनाता है। हम आपको सलाह देंगे और सर्वोत्तम समाधान प्रस्तावित करेंगे।
यह भी पढ़ें