कमिट लूप

docs.scrimba.com

मान लीजिए आप पिछले बीस मिनट से weather-app पर काम कर रहे हैं। आपने src/index.js में एक वास्तविक बग ठीक किया, तापमान रूपांतरण गलत था, और जब आप वहां थे तो आपने styles.css को रीस्टाइल करना भी शुरू किया, लेकिन वह परिवर्तन अधूरा है और किसी और को दिखाने के लिए तैयार नहीं है। आप बग फिक्स को अभी अपने आप में एक चेकपॉइंट के रूप में सहेजना चाहते हैं, बिना अधूरी स्टाइलिंग को इसके साथ खींचे।

यह बिल्कुल वही है जिसके लिए कमिट लूप है। यदि आपने अभी तक एक रिपोजिटरी सेट अप नहीं की है, Your first repository git init और क्लोनिंग के बारे में बताता है। यहां से, यह अध्याय मानता है कि आपके पास एक खुला है।

तीन स्टॉप: वर्किंग डायरेक्टरी, स्टेजिंग एरिया, कमिट

Git में आप जो भी परिवर्तन करते हैं वह स्थायी इतिहास बनने से पहले तीन स्टॉप से गुजरता है। आपकी वर्किंग डायरेक्टरी वह प्रोजेक्ट है जैसा वह अभी डिस्क पर दिखता है, वह फाइलें जिन्हें आप सक्रिय रूप से संपादित कर रहे हैं। स्टेजिंग एरिया एक होल्डिंग स्पॉट है जहां आप वास्तव में जो परिवर्तन अगली बार सहेजना चाहते हैं उन्हें रखते हैं। एक कमिट स्वयं सहेजा गया स्नैपशॉट है, एक बार जब आप इसे लिख देते हैं, साथ ही इसे वर्णित करने वाला संदेश।

एक चाल के लिए सामान पैक करने की कल्पना करें। आपका पूरा घर वर्किंग डायरेक्टरी है: आपके पास जो कुछ भी है, जो भी स्थिति में हो। वह बॉक्स जो आपने पैक किए हैं और सामने के दरवाजे के पास टेप किए हैं वह स्टेजिंग एरिया है: केवल वह जो आपने जानबूझकर ले जाने के लिए चुना है। वह मूविंग ट्रक जो उन बॉक्स के साथ दूर जाता है वह कमिट है: यह एक रिकॉर्ड है कि उस पल बिल्कुल क्या चला गया, बाहर की ओर एक लेबल के साथ जो कहता है कि अंदर क्या है।

यहां वह मानसिक मॉडल एक वास्तविक टर्मिनल में दिख रहा है। weather-app में दोनों फाइलों को संपादित करने के बाद, git status वर्तमान स्थिति को कुछ भी बदले बिना पढ़ता है:

$ git status
On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   src/index.js
        modified:   styles.css

no changes added to commit (use "git add" to commit)

दोनों फाइलें "अनस्टेजड" के रूप में दिखाई देती हैं क्योंकि फाइल को संपादित करना केवल आपकी वर्किंग डायरेक्टरी को बदलता है। git add के साथ Git को इसे वहां रखने के लिए कहने तक कुछ भी स्टेजिंग एरिया में नहीं जाता है, जो अगला भाग है।

यह वह जगह है जहां स्टेजिंग एरिया के अस्तित्व का पूरा कारण स्पष्ट हो जाता है। स्टेजिंग एरिया आपको बिल्कुल यह चुनने देता है कि आपके कमिट में क्या जाता है, जो कुछ भी अभी भी आपकी वर्किंग डायरेक्टरी में संपादित बैठा है उससे स्वतंत्र। इसके बिना, एक चेकपॉइंट को सहेजना आपको एक बार में डिस्क पर हर परिवर्तन लेने के लिए मजबूर करेगा, तैयार हों या न हों।

इसके साथ, आप src/index.js में समाप्त बग फिक्स को स्टेज कर सकते हैं, अधूरे styles.css को छोड़ सकते हैं, और केवल उस हिस्से को कमिट कर सकते हैं जो वास्तव में पूरा है। यह एक विवरण, कि स्टेजिंग और आपकी वर्किंग डायरेक्टरी एक ही समय में विभिन्न चीजें पकड़ सकते हैं, पहले हफ्ते में लगभग सभी को भ्रमित करता है। एक बार जब यह क्लिक हो जाता है, तो Git के बाकी दैनिक वर्कफ़्लो बहुत अधिक समझदारी में आता है।

दिन-प्रतिदिन के काम में, हर add और हर commit से पहले git status को एक नियमित कदम बनाएं, भले ही कुछ गलत महसूस न हो। इसकी कोई कीमत नहीं है, यह कभी आपके प्रोजेक्ट को नहीं बदलता, और यह आपके इरादे से अधिक कमिट करने की आम गलती को रोकता है। स्थिति की जांच करने, स्टेजिंग, फिर कमिट करने से पहले फिर से स्थिति की जांच करने की आदत डालें: इसमें कुछ सेकंड लगते हैं और इसका मतलब है कि आपके कमिट पर संदेश हमेशा वास्तव में इसमें क्या गया इससे मेल खाता है।

स्टेजिंग एरिया एक वास्तविक फाइल है, जिसे इंडेक्स कहा जाता है, आपकी रिपोजिटरी के अंदर .git/index पर बैठा है। हर बार जब आप git add चलाते हैं, Git उस फाइल को अपडेट करता है कि किस फाइल का कौन सा संस्करण स्टेज किया गया है। जब आप git commit चलाते हैं, Git केवल उससे नई कमिट बनाता है जो इंडेक्स कहता है, बिना अपनी वर्किंग डायरेक्टरी को फिर से देखे। यह पूरी तरह वह तंत्र है जो आपने अभी git status में एक पल पहले देखा: डिस्क पर दो फाइलें संपादित, लेकिन इंडेक्स उनमें से किसी को ट्रैक नहीं कर रहा है, इसलिए अगली कमिट वर्तमान में कुछ भी नहीं होगी।

JunoGit के तीन क्षेत्र आपकी वर्किंग डायरेक्टरी आपकी फाइलें हैं जैसा वे अभी हैं। स्टेजिंग एरिया वह जगह है जहां आप वास्तव में जो परिवर्तन अगली बार सहेजना चाहते हैं उन्हें रखते हैं, और एक कमिट सहेजा गया स्नैपशॉट है जब आप इसे लिखते हैं। फाइल को संपादित करना कभी भी इसे अपने आप स्टेज नहीं करता, आप git add के साथ क्या जाता है यह चुनते हैं, और यह वही है जो आपको एक समाप्त परिवर्तन को सहेजने देता है जबकि एक अधूरा परिवर्तन छोड़ देता है।

JunoGit के तीन क्षेत्र वर्किंग डायरेक्टरी, स्टेजिंग एरिया, कमिट: संपादन पहले में रहते हैं, git add बिल्कुल वह जो आप चुनते हैं उसे दूसरे में ले जाता है, और git commit दूसरे को एक स्थायी स्नैपशॉट के रूप में सहेजता है। जब आप स्टेज करने से पहले और फिर से कमिट करने से पहले git status चलाएं, यह निःशुल्क है और यह आपकी कमिटों को वह रखता है जो आप सहेजना चाहते हैं।

JunoGit के तीन क्षेत्र स्टेजिंग एरिया एक वास्तविक फाइल है, .git/index पर इंडेक्स, और git commit इंडेक्स से अपना स्नैपशॉट बनाता है, कभी भी सीधे आपकी वर्किंग डायरेक्टरी से नहीं। यह है कि दो संपादित फाइलें दोनों ही अनस्टेजड के रूप में क्यों दिखाई दे सकती हैं: इंडेक्स को किसी के बारे में अभी तक नहीं बताया गया है। इस तरह इंडेक्स को समझना हर स्टेजिंग कमांड को जादू से कम और एक फाइल को पढ़ने और लिखने जैसा अधिक महसूस कराता है।

परिवर्तन स्टेज करना: git add

git add एक परिवर्तन को आपकी वर्किंग डायरेक्टरी से स्टेजिंग एरिया में ले जाता है। उस फाइल की ओर इशारा करें जिसके परिवर्तन आप अगली कमिट में चाहते हैं:

$ git add src/index.js
$ git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   src/index.js

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   styles.css

src/index.js "कमिट के लिए तैयार परिवर्तन" में चला गया, बग फिक्स स्टेज किया गया है और तैयार है। styles.css अभी भी "अनस्टेजड" के तहत सूचीबद्ध है, बिल्कुल वह जगह जहां आप इसे चाहते हैं जबकि रीस्टाइल अधूरा है। git add styles.css भी चलाने से यह भी स्टेज हो जाएगा; git add . वर्तमान फोल्डर में हर बदली गई फाइल को एक बार में स्टेज करता है, जो सुविधाजनक है एक बार जब आप विश्वास करते हैं कि डिस्क पर सब कुछ वास्तव में जाने के लिए तैयार है।

कभी-कभी एक एकल फाइल में दोनों एक परिवर्तन है जो आप सहेजना चाहते हैं और एक जो आप नहीं चाहते, और उन्हें दो फाइलों में विभाजित करना व्यावहारिक नहीं है। git add -p <file> (--patch के लिए छोटा) फाइल के परिवर्तनों को छोटे टुकड़ों में, जिन्हें hunks कहते हैं, के माध्यम से चलता है, और आप को प्रत्येक पर निर्णय लेने के लिए कहता है:

$ git add -p src/index.js
@@ -12,7 +12,7 @@ function celsiusToFahrenheit(celsius) {
-  return celsius * (9 / 5 + 32)
+  return (celsius * 9) / 5 + 32
Stage this hunk [y,n,q,a,d,e,?]?

उस hunk को स्टेज करने के लिए y उत्तर दें, इसे बाद के लिए छोड़ने के लिए n, और रोकने के लिए q। यह आपको कमिट-आकार का नियंत्रण देता है एक एकल फाइल के अंदर भी, जो पहुंचने लायक है जब भी "इस फाइल का आधा पूरा है" आपकी स्थिति का वर्णन करता है।

git add एक बार में दो काम करता है, और दोनों को जानने से आप एक गड़बड़ी की व्याख्या करता है जो आप अंत में मारेंगे। पहला, यह फाइल की वर्तमान सामग्री को एक नए blob में लिखता है, एक ऑब्जेक्ट Git स्थायी रूप से संग्रहीत करता है, कमिट के समान तरीके से हैश द्वारा पहचाना गया, जो एक फाइल की सटीक सामग्री एक पल में रखता है। दूसरा, यह इंडेक्स को उस फाइल के लिए उस blob की ओर इशारा करने के लिए अपडेट करता है। add के बारे में कुछ भी उसके बाद फाइल को फिर से नहीं देखता है।

यह है कि अगर आप git add src/index.js करते हैं और फिर कमिट करने से पहले एक ही फाइल को संपादित करते रहते हैं, git status क्यों इसे स्टेजड और संशोधित दोनों दिखाता है: इंडेक्स अभी भी उस समय के blob की ओर इशारा करता है जब आपने add चलाया था, जबकि आपकी वर्किंग डायरेक्टरी आगे बढ़ गई है। git commit केवल स्टेजड blob को देखता है, इसलिए एक दूसरा git add वह है जो आप सहेजने से पहले नए संपादन में खींचता है।

Junoपरिवर्तन स्टेज करनाgit add <file> उस फाइल के वर्तमान परिवर्तनों को स्टेजिंग एरिया में ले जाता है, अगली कमिट के लिए तैयार। फाइलें जो आपने अभी तक जोड़ी नहीं हैं वह बाहर रहती हैं, इसलिए आप एक चीज को समाप्त कर सकते हैं और दूसरे को मध्य-संपादन में छोड़ सकते हैं। git add . एक बार में हर बदली गई फाइल को स्टेज करता है, एक बार सब कुछ वास्तव में तैयार होने के बाद सुविधाजनक।

Junoपरिवर्तन स्टेज करनाgit add <file> एक पूरी फाइल को स्टेज करता है, और git add -p <file> आपको इसे hunk by hunk स्टेज करने देता है जब केवल फाइल का हिस्सा तैयार हो। जब "इस फाइल का आधा पूरा है" सत्य हो तब वह दूसरा ही उपकरण है जो उठाना है।

Junoपरिवर्तन स्टेज करनाgit add आपकी फाइल की वर्तमान सामग्री को एक blob में लिखता है और इंडेक्स को इसकी ओर इशारा करता है, यह उसके बाद फाइल को नहीं देखता है। कमिट करने से पहले फाइल को फिर से संपादित करें और status इसे स्टेजड और संशोधित दोनों दिखाता है, क्योंकि इंडेक्स अभी भी पुराने blob को रखता है। नए संपादन को खींचने के लिए add को फिर से चलाएं। यह एक बार मेरे लिए पहली बार जब मैं इसे मारा तो दस मिनट की भ्रमण थी।

स्नैपशॉट सहेजना: git commit

एक बार स्टेजिंग एरिया में आप क्या चाहते हैं, git commit इसे एक स्थायी स्नैपशॉट के रूप में सहेजता है, -m फ्लैग के साथ (संदेश के लिए छोटा) विवरण प्रदान करते हुए जो इसके साथ जाता है:

$ git commit -m "Fix temperature conversion in Celsius-to-Fahrenheit formula"
[main 4f2a1c9] Fix temperature conversion in Celsius-to-Fahrenheit formula
 1 file changed, 1 insertion(+), 1 deletion(-)

केवल src/index.js चला गया, क्योंकि यह सब कुछ है जो आपने स्टेज किया। styles.css अभी भी आपकी वर्किंग डायरेक्टरी में संपादित बैठा है, अछूता, जब भी रीस्टाइल पूरा हो तब के लिए इंतजार कर रहा है। छोटी आईडी, 4f2a1c9, इस सटीक कमिट का नाम देता है, और History अध्याय इसी तरह एक प्रोजेक्ट की कमिट की पूरी सूची पढ़ने के बारे में बताता है।

कमिट संदेशों को अनिवार्य मूड में, एक निर्देश के रूप में लिखें। "तापमान रूपांतरण को ठीक करें" Git स्वयं उपयोग करने वाली शब्दावली से मेल खाता है ("यह कमिट होगी...") और उपकरणों में स्वच्छ रूप से पढ़ता है जो कमिट को एक पंक्ति प्रति सूचीबद्ध करते हैं। एक पंक्ति की फिक्स से अधिक कुछ के लिए, एक बॉडी जोड़ें जो व्याख्या करता है कि परिवर्तन की आवश्यकता क्यों थी। diff पहले से ही दिखाता है कि क्या बदला, इसलिए इसके पीछे के कारण के लिए बॉडी को बचाएं:

$ git commit -m "Fix temperature conversion in Celsius-to-Fahrenheit formula

The formula was applying operator precedence in the wrong order,
which rounded warm temperatures down by a degree in the UI."

यदि आप कमिट के तुरंत बाद एक टाइपो या एक मिस विवरण देखते हैं, git commit --amend अपनी सबसे हाल की कमिट को एक नई के साथ बदलता है बजाय ऊपर एक और जोड़ने के:

$ git commit --amend -m "Fix temperature conversion in Celsius-to-Fahrenheit formula"

केवल एक कमिट को संशोधित करें जो आपने कहीं भी साझा नहीं किया है। एक बार जब आप इसे पुश कर देते हैं (इसे प्रोजेक्ट की साझा प्रति में भेज देते हैं), संशोधन इतिहास को फिर से लिखता है जो अन्य लोगों के पास पहले से हो सकते हैं, और Undoing things उसके बाद एक कमिट को ठीक करने के सुरक्षित तरीके कवर करता है।

एक कमिट स्वयं तीन भागों के साथ एक छोटी सी चीज है: एक tree के लिए एक सूचक, लेखक और संदेश, और इसके मूल कमिट के लिए एक सूचक। tree आपके पूरे प्रोजेक्ट की डायरेक्टरी संरचना का एक स्नैपशॉट है उस पल में: हर फाइल और फोल्डर के लिए, यह एक नाम और या तो एक blob (फाइल की सामग्री) या दूसरे tree (एक सबफोल्डर) के लिए एक सूचक दर्ज करता है। git add चलाना एक बार में blobs लिखता है और इंडेक्स अपडेट करता है; git commit वह पल है Git वर्तमान इंडेक्स को एक पूर्ण tree में बदलता है और इसे एक कमिट ऑब्जेक्ट में लपेटता है।

दो फाइलें समान सामग्री के साथ बिल्कुल एक ही blob की ओर इशारा करती हैं, यहां तक कि विभिन्न फोल्डरों में बैठी हुई भी, इसलिए एक कमिट उन बाइटों को कभी दोहराता नहीं है। वह संरचना दो कमिट की तुलना को भी कुशल बनाती है: Git उनके दोनों tree को एक साथ घूमता है और केवल blobs को खोलता है जिनके सूचक वास्तव में अलग हैं, हर फाइल को छोड़ देता है जो समान रहा।

Junoकमिट सहेजनाgit commit -m "संदेश" वर्तमान में स्टेजड को जो भी है एक स्थायी स्नैपशॉट के रूप में सहेजता है, आप जो संदेश देते हैं उसके साथ। कुछ भी आपने स्टेज नहीं किया वह बाहर रहता है और संपादन योग्य रहता है। संदेश को संक्षिप्त रखें और स्पष्ट करें कि कमिट क्या करता है, भविष्य आप इसे उम्मीद से अधिक बार वापस पढ़ेंगे।

Junoकमिट सहेजना कमिट संदेशों को एक निर्देश के रूप में लिखें, "Fixed" के बजाय "Fix", और जब भी diff अकेला किसी को यह अनुमान लगाने के लिए छोड़ देता है कि आपने परिवर्तन क्यों किया तो एक बॉडी जोड़ें। git commit --amend आपकी अंतिम कमिट को एक नई के साथ बदलता है एक नई को ऊपर ढेर करने के बजाय, जो एक संदेश टाइपो के लिए परफेक्ट है, जब तक कि आपने उस कमिट को कहीं पुश नहीं किया है।

Junoकमिट सहेजना एक कमिट एक tree की ओर इशारा करता है, और एक tree नामों को blobs और आगे के trees में मैप करता है, प्रोजेक्ट का एक पूर्ण नेस्टेड स्नैपशॉट जो कमिट समय पर इंडेक्स ने जो किया उससे बना है। add blobs लिखता है और commit इंडेक्स को एक पूर्ण tree में बदल देता है, और समान सामग्री प्रोजेक्ट में कहीं भी दो बार संग्रहीत होने के बजाय एक blob साझा करता है। उस आकार को चित्रित करें और दो चीजें महसूस करना बंद करती हैं जादू: क्यों कुछ नहीं दोहराया जाता है, और क्यों दो कमिट की तुलना करने का मतलब है दो trees को एक साथ चलना प्रत्येक फाइल को फिर से पढ़ने के बजाय।