गिट के दो-चरणीय प्रतिबद्ध प्रक्रिया (मंचन) से क्या लाभ है?

Question

मैं सीख रहा हूँ और मैंने देखा है कि यह एक दो कदम प्रतिबद्ध प्रक्रिया है:

1. git add <files>
2. git commit

पहला चरण स्थानों को "स्टेजिंग क्षेत्र" या "इंडेक्स" कहा जाता है।

मुझे इसमें दिलचस्पी है कि यह डिजाइन निर्णय क्यों किया जाता है, और इसके लाभ क्या हैं?

इसके अलावा, एक गिट उपयोगकर्ता के रूप में आप ऐसा करते हैं या सिर्फ उपयोग करते हैं git commit -a?

मैं यह पूछता हूं क्योंकि मैं bzr (बाज़ार) से आया हूं जिसमें यह सुविधा नहीं है।

Comments

पूछने के लिए +1। मैं कछुआ एसवीएन का उपयोग करता हूं, जिसमें समान दृष्टिकोण है और मुझे कभी भी समझ नहीं आया कि क्यों।

— डीपीडी

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

— क्युरेलासा

मैंने पाया कि यह लिंक यहाँ वर्णित अधिकांश बातों को संक्षेप में प्रस्तुत करता है और मंचन की आवश्यकता को उचित ठहराने के लिए कुछ और उपयोग मामलों को जोड़ता है।

— विवेके

यह प्रश्न वास्तव में पहले से ही उत्तर दिया गया है, लेकिन यहाँ एक अच्छी व्याख्या भी है: stackoverflow.com/questions/4878358/…

— guitar_freak

मत भूलना git statusऔर संभवतः git push। गिट के बारे में सभी प्रचार के लिए, (और GitHub साझाकरण कोड अद्भुत है) भागों बहुत कष्टप्रद हैं

— user949300

Answer 1

अलग-अलग कामों में विभाजन कार्य। आपने कई बार सिंगल-लाइन फिक्स लिखने के लिए एक फ़ाइल खोली है, लेकिन उसी समय आपने देखा कि स्वरूपण गलत था, कुछ दस्तावेज़ीकरण में सुधार किया जा सकता था, या कुछ अन्य असंबंधित फिक्स। अन्य आरसीएस के साथ आपको यह लिखना होगा कि इसे नीचे करें या इसे मेमोरी में रखें, आपके द्वारा आए फिक्स को खत्म करें, इसके लिए प्रतिबद्ध करें, और फिर अन्य सामान को ठीक करने के लिए वापस लौटें (या असंबंधित सामान के साथ बॉल-ऑफ-कीड कमिट बनाएं) । Git के साथ आप बस एक ही बार में सब ठीक कर देते हैं, और स्टेज + सिंगल लाइन को अलग से, के साथ git add -iया कमिट करते हैं git-gui।

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

Comments

एक DVCS (bzr) से आ रहा है जिसमें यह सुविधा नहीं है, जो बहुत कुछ लगता है जैसे मैं वर्तमान में अपने संपादक के "पूर्ववत" बफ़र्स, "रिवर्ट <फ़ाइल>" कमांड और सेलेक्ट कमिट्स (" प्रतिबद्ध <फ़ाइल> ")। इस सुविधा की तरह लगता है और अधिक व्यवस्थित होने की क्षमता है।

— thomasrutter

"अन्य आरसीएस" के बारे में, यह जरूरी नहीं कि सच है। वास्तव में, आप पैच का उपयोग करके मर्क्यूरियल में उन्हीं कार्यात्मकताओं को प्राप्त कर सकते हैं ।

— लुसियो पावा

@ l0b0, आपके दूसरे बिंदु के बारे में। यदि केवल एक ही स्टेज कमिट था, तो आप सीधे बदलाव कर सकते थे (जो आप git ऐड के साथ उपयोग करते हैं) सीधे एक कमिट के रूप में। अगर आपको पता चला कि आपने कुछ गलत किया है, तो आपने कमिट को डिलीट कर दिया होगा, और कमिट करने से पहले आप वापस आ गए। मंचन अवधारणा के साथ, आप बस ऐसा नहीं कर रहे हैं, लेकिन अधिक जटिलता जोड़ रहे हैं?

— अल्फा_989

आपका पहला बिंदु समझ में आता है, हालाँकि मैंने अभी तक इसका उपयोग नहीं किया है। सैद्धांतिक रूप से आप git add -iएक सिंगल स्टेज कमिटमेंट के साथ ऐसा क्यों नहीं कर सकते ? आप बस एक ही फीचर से संबंधित फाइलों (या फाइलों के भीतर की पंक्तियों) का एक गुच्छा लेंगे, और एक कमिट करेंगे। फिर आप वापस आकर दूसरी विशेषता से संबंधित एक दूसरी प्रतिबद्धता करेंगे ..

— अल्फा_989

@thomasrutter, आपके कथन से, ऐसा लगता है कि आप सुझाव दे रहे हैं कि मंचन क्षेत्र "पूर्ववत अंक" बनाता है। लगातार-पूर्ववत के साथ VIM में, आप असीमित इतिहास को बहुत मज़बूती से प्राप्त कर सकते हैं। यह भी एक git-branchप्रकार के फैशन में स्वचालित रूप से ट्रैक किया जाता है ( jovicailic.org/2017/04/vim-persistent-undo )। इसके अलावा आपके पूर्ववत इतिहास को सामान्य मोड में जाने पर स्वचालित रूप से ट्रैक किया जाता है। तो यह "मैनुअल पूर्व अंक" बनाने के अपने मानसिक बोझ को कम करता है। आपके संपादकों "पूर्ववत्" बफ़र्स को पद्धति के रूप में उपयोग क्यों नहीं किया जा रहा है?

— अल्फा_989

Answer 2

मेरे लिए लाभों में से एक उत्तरोत्तर फाइलों को "जोड़ने" की क्षमता है। प्रत्येक फ़ाइल की समीक्षा करने से पहले। एक बार फ़ाइल की समीक्षा करने के बाद, मैं इसे जोड़ता हूं। जब मैं git statusया git diff, git मुझे केवल उन फ़ाइलों को दिखाता है जिन्हें संशोधित किया गया है और अभी तक जोड़ा नहीं गया है। जब मैंने सभी फाइलों की समीक्षा की है और उन्हें जोड़ा है, तो मैं प्रतिबद्ध कर सकता हूं।

तो हां, मुझे मंचन क्षेत्र बहुत मददगार लगता है।

और नहीं, मैं कभी उपयोग नहीं करता git commit -a। हालांकि, मैं अक्सर उपयोग करता हूं git add -u। इस तरह मैं अभी भी कल्पना कर सकता हूं कि क्या प्रतिबद्ध होना है।

Comments

ठीक ठीक। फायदा यह है कि आप जो कर रहे हैं, उस पर बहुत अधिक बारीक नियंत्रण है।

— जोश के

क्या होता है जब आप एक फ़ाइल को कई बार स्टेज करते हैं? क्या यह स्टेजिंग क्षेत्र में "मर्ज" हो जाता है?

— m4l490n

Answer 3

लाभ काफी सरल है: यह आपको पूर्ण नियंत्रण देता है कि आप किन फाइलों को कब करना चाहते हैं। उस मामले के लिए, आप यह git add -pनियंत्रित करने के लिए उपयोग कर सकते हैं कि आप कौन सी लाइनें कमिट करना चाहते हैं।

Comments

मुझे हमेशा आश्चर्य होता है कि यह कैसे करना है। काश कोई फ़ाइल होती .gitignorelinesतो आप व्यक्तिगत लाइनों के लिए स्थानीय परिवर्तन कर सकते थे जो कमिट हो सकते थे, और बरकरार रह सकते थे।

— एलेक्स ग्रे

@ReinHenrichs, उन फ़ाइलों के बारे में सोचें, जिन्हें प्रत्येक डेवलपर द्वारा बदलने की आवश्यकता है।

— इयान

@ यदि फ़ाइल का कुछ हिस्सा बार-बार बदलता है और साझा किया जाता है और फ़ाइल का हिस्सा अक्सर असंगत तरीकों से साझा किया जाता है, और साझा नहीं किया जाता है? इस गलत अवधारणा का समर्थन निश्चित रूप से एक विरोधी सुविधा की तरह लगता है।

— रीन हेनरिक

@ReinHenrichs, हाँ और यह बहुत आम है जब फ़ाइल में डेटाबेस सर्वर का नाम होता है और प्रत्येक देव का अपना डेटाबेस होता है।

— इयान

@ यदि आपकी समस्या वास्तव में है, तो आपके पास एक फ़ाइल है जिसे माना जाता है कि आवेदन के लिए कॉन्फ़िगरेशन में कुछ मशीन / देव विशिष्ट कॉन्फ़िगरेशन भी हैं। सभी कॉन्फ़िगरेशन सिस्टम मैं आपको कई फ़ाइलों में विभाजित करने की अनुमति देता हूं। इसलिए उदाहरण के लिए आपके पास आपका app.confवह सामान है जिसे आप साझा करना चाहते हैं, और फिर db.confजो आपने अभी .gitignore सूची में डाला है। समस्या सुलझ गयी। यदि आप कुछ मालिकाना का उपयोग कर रहे हैं तो आपको वास्तव में वहाँ कुछ सरल होने पर ध्यान देना चाहिए। या इसे प्री-बिल्ड इवेंट में प्रीप्रोसेसर के माध्यम से डालें। कई समाधान वहाँ।

— इतियाकापी

Answer 4

एक लाभ जो मुझे पसंद है वह है बदलाव के एक हिस्से को करने की क्षमता। यानी, git ऐड-ई का उपयोग करके। मैं कभी-कभी ऐसा नहीं करता, जैसा कि मुझे कभी-कभी करना चाहिए, और git ऐड-ई कमांड मुझे अपने परिवर्तनों को एक हद तक सुलझा लेने देता है।