गिट में आने से पहले मुझे मंच क्यों चाहिए?

Question

मैं संस्करण नियंत्रण के लिए नया हूं और मैं समझता हूं कि "काम करना" अनिवार्य रूप से बैकअप बना रहा है जबकि आप जिस काम पर काम कर रहे हैं उसके नए 'वर्तमान' संस्करण को अपडेट करते समय।

जो मुझे समझ में नहीं आता है वह व्यावहारिक परिप्रेक्ष्य से क्या है। क्या कुछ ऐसा नाम है जो केवल नाम में मौजूद है या क्या यह एक उद्देश्य प्रदान करता है? जब आप प्रतिबद्ध करते हैं, तो यह सबकुछ करने जा रहा है, है ना?

संपादित करें: मुझे लगता है कि मैं शब्दावली को भ्रमित कर सकता हूं। एक 'मंचित' फ़ाइल एक 'ट्रैक' फ़ाइल के समान ही है?

Answer 1

जब आप प्रतिबद्ध करते हैं तो यह केवल सूचकांक ("मंचित" फ़ाइलों में परिवर्तन करने जा रहा है)। इसके लिए कई उपयोग हैं, लेकिन सबसे स्पष्ट है कि अपने काम करने वाले परिवर्तनों को छोटे, स्वयं निहित टुकड़ों में विभाजित करना है। जब आप एक सुविधा लागू कर रहे थे तो शायद आपने एक बग तय किया था। आप git add बस उस फ़ाइल (या git add -p फ़ाइल का केवल एक हिस्सा जोड़ने के लिए कर सकते हैं!) और फिर बाकी सब कुछ करने से पहले उस बगफिक्स को प्रतिबद्ध करें। यदि आप git commit -a का उपयोग कर रहे हैं तो आप प्रतिबद्धता से ठीक पहले सब कुछ के add को मजबूर कर रहे हैं। यदि आप स्टेजिंग फाइलों का लाभ लेना चाहते हैं तो -a का उपयोग न करें।

आप चरणबद्ध फ़ाइलों को --cached के साथ कई आदेशों के साथ मध्यवर्ती कार्यशील प्रति के रूप में भी देख सकते हैं। उदाहरण के लिए, git diff --cached आपको दिखाएगा कि चरण HEAD से अलग कैसे है ताकि आप देख सकें कि आप अपने अन्य कामकाजी परिवर्तनों में मिश्रण किए बिना क्या कर रहे हैं।

Answer 2

• स्टेजिंग क्षेत्र नियंत्रण को कम करने के लिए नियंत्रण देता है। बस कोड में एक तार्किक परिवर्तन करें, बदली गई फ़ाइलों को स्टेजिंग क्षेत्र में जोड़ें और अंत में यदि परिवर्तन खराब हैं तो पिछली प्रतिबद्धता के लिए चेकआउट करें या अन्यथा परिवर्तन करें। यह कार्य को छोटे कार्यों में विभाजित करने और छोटे करने के लिए लचीलापन देता है परिवर्तन। स्टेजिंग क्षेत्र के साथ छोटे कार्यों में ध्यान केंद्रित करना आसान है।
• यह आपको ब्रेक लेने और ब्रेक लेने से पहले आपने कितना काम किया है, इस बारे में भूलने की पेशकश भी प्रदान की है। मान लीजिए कि आपको एक तार्किक परिवर्तन करने के लिए तीन फाइलों को बदलने की जरूरत है और आपने पहली फ़ाइल बदल दी है और जब तक आप अन्य परिवर्तन करना शुरू नहीं करते हैं, तब तक एक लंबे ब्रेक की आवश्यकता होती है। इस समय आप प्रतिबद्ध नहीं हो सकते हैं और आप ट्रैक करना चाहते हैं कि आप किन फाइलों के साथ काम कर रहे हैं ताकि वापस आने के बाद आपको यह याद रखने की आवश्यकता नहीं है कि कितना काम किया गया है। तो फ़ाइल को स्टेजिंग क्षेत्र में जोड़ें और यह आपके काम को बचाएगा। जब आप वापस आते हैं तो बस "गिट diff --staged" करें और जांचें कि आपने कौन सी फाइलें बदली हैं और कहां और अन्य परिवर्तन करना शुरू करें।

Answer 3

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

आप एक ही कामकाजी निर्देशिका में कई विशेषताओं/बग पर काम कर सकते हैं और अभी भी सार्थक कामकाज तैयार कर सकते हैं। एक ही कामकाजी निर्देशिका होने जिसमें हमारे सभी सक्रिय कार्य शामिल हैं, यह भी बहुत सुविधाजनक है। (यह एक स्टेजिंग क्षेत्र के बिना किया जा सकता है, जब तक कि परिवर्तन कभी भी फ़ाइल को ओवरलैप न करें। और आपके पास मैन्युअल रूप से ट्रैकिंग करने की अतिरिक्त ज़िम्मेदारी भी है)

आप यहां और अधिक उदाहरण पा सकते हैं: Uses of Index

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

Answer 4

यदि आप गिटूब पर अपने भंडार में लॉग फ़ाइल को बनाए रखने की कल्पना करते हैं तो गिट कमांड add और commit के उपयोग को समझना आसान है।

---------------- Day 1 -------------------- 
Message: Completed Task A 
Index of files changed: File1, File2 

Message: Completed Task B 
Index of files changed: File2, File3 
------------------------------------------- 

---------------- Day 2 -------------------- 
Message: Corrected typos 
Index of files changed: File3, File1 
------------------------------------------- 
... 
... 
...and so on 

मैं आमतौर पर एक git pull अनुरोध के साथ मेरा दिन शुरू करने और एक git push अनुरोध के साथ इसे समाप्त: की तरह एक ठेठ परियोजना की मेरे लिए लॉग फ़ाइल लग सकता है। तो एक दिन के रिकॉर्ड के अंदर सब कुछ उनके बीच क्या होता है उससे मेल खाता है। प्रत्येक दिन के दौरान, एक या अधिक तार्किक कार्य हैं जो मैं पूरा करता हूं जिसके लिए कुछ फ़ाइलों को बदलने की आवश्यकता होती है। उस कार्य के दौरान संपादित की गई फ़ाइलों को एक अनुक्रमणिका में सूचीबद्ध किया गया है।

इनमें से प्रत्येक उप कार्य (कार्य ए और कार्य बी) व्यक्तिगत कार्य करता है। git add कमांड 'फ़ाइलों के सूचकांक' सूची में फ़ाइलों को जोड़ता है। इस प्रक्रिया को स्टेजिंग भी कहा जाता है। git commit कमांड रिकॉर्ड/कस्टम संदेश के साथ परिवर्तन और संबंधित इंडेक्स सूची को अंतिम रूप देता है।

याद रखें कि आप अभी भी केवल अपने भंडार की स्थानीय प्रति बदल रहे हैं, न कि गिथब पर। इसके बाद, केवल जब आप 'गिट पुश' करते हैं तो इन सभी रिकॉर्ड किए गए परिवर्तनों के साथ-साथ प्रत्येक प्रतिबद्धता के लिए आपकी अनुक्रमणिका फ़ाइलों के साथ, मुख्य भंडार (गीथब पर) पर लॉग ऑन करें।

उदाहरण के लिए, कि काल्पनिक लॉग फ़ाइल में दूसरी प्रविष्टि प्राप्त करने के लिए, मैंने किया होता:

git pull 
# Make changes to these files 
git add File3 File4 
# Verify changes, run tests etc.. 
git commit -m 'Corrected typos' 
git push 

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

Answer 5

स्टेजिंग का एक व्यावहारिक उद्देश्य फ़ाइल प्रतिबद्धताओं का तार्किक पृथक्करण है।

स्टेजिंग आपको फ़ाइलों/कार्यशील निर्देशिका में संपादन जारी रखने की अनुमति देता है, और जब आप सोचते हैं कि भागों में काम करना है, तो आप तर्कसंगत असंबंधित संपादन के लिए अलग-अलग चरणों का उपयोग कर सकते हैं।

मान लें कि आपके पास 4 फ़ाइलें fileA.html, fileB.html, fileC.html और fileD.html हैं। आप सभी 4 फाइलों में बदलाव करते हैं और प्रतिबद्ध करने के लिए तैयार हैं लेकिन fileA.html और fileB.html में परिवर्तन तर्कसंगत रूप से संबंधित हैं (उदाहरण के लिए, दोनों फाइलों में एक ही नई सुविधा कार्यान्वयन) जबकि fileC.html और fileD.html में परिवर्तन अलग-अलग और तार्किक रूप से फ़ाइलों से संबंधित नहीं हैं। आप पहले fileA.html और fileB.html फ़ाइलें ले सकते हैं और उन्हें प्रतिबद्ध कर सकते हैं।

git add fileA.html 
git add fileB.html 
git commit -m "Implemented new feature XYZ" 

फिर अगले चरण में आप शेष दो फ़ाइलों में परिवर्तन करते हैं और परिवर्तन करते हैं।

git add fileC.html 
git add fileD.html 
git commit -m "Implemented another feature EFG"