क्या कोई गिट में उपयोग की जाने वाली सामग्री ट्रैकिंग और अन्य एससीएम

Question

में उपयोग की जाने वाली फ़ाइल ट्रैकिंग के बीच भेद को समझा सकता है, मैं अब कुछ समय के लिए गिट का उपयोग कर रहा हूं और वर्कफ़्लो में सुविधाओं और लचीलापन से प्यार करता हूं। जल्दी और अक्सर प्रतिबद्ध करने की क्षमता मेरे लिए एक बड़ा सौदा है और वास्तव में काम करने के मेरे तरीके में फिट बैठता है।

गिट की एक विशेषता मैंने कई बार उल्लेख किया है लेकिन अभी तक मेरा सिर नहीं मिला है यह तथ्य है कि यह फ़ाइल इतिहास के बजाय सामग्री को ट्रैक करता है जो माना जाता है कि फ़ाइलों को नाम बदलने और फ़ाइलों को बेहतर तरीके से स्थानांतरित करने से संबंधित है।

क्या कोई यह समझा सकता है कि यह क्यों है? मैंने एसवीएन की तुलना में इस संबंध में विशेष कुछ भी नहीं देखा है। मैं क्या खो रहा हूँ?

Answer 1

Git भंडार three pieces of data separately:

• सामग्री ब्लॉब में संग्रहीत किया जाता वस्तुओं
• इतिहास में संग्रहीत किया जाता है वस्तुओं के लिए प्रतिबद्ध
• संरचना पेड़ में संग्रहीत किया जाता वस्तुओं

इस का एक परिणाम यह है कि है यदि आपके पास कई फ़ाइलों में एक ही डेटा है, तो गिट को केवल इसे एक बार स्टोर करना होगा, क्योंकि संरचना (जिसमें निर्देशिकाएं और फ़ाइलें शामिल हैं) केवल एक सामग्री ऑब्जेक्ट को इंगित करना है।

इसी प्रकार, यदि कोई फ़ाइल संस्करण से संस्करण में नहीं बदलती है, तो गिट को केवल उस फ़ाइल को एक बार स्टोर करना होगा। एकाधिक इतिहास वस्तुएं एक ही सामग्री को इंगित करती हैं।

उपयोगकर्ता के कुछ दृश्य लाभ यह है कि git blame is very good at seeing code move across files विशेष रूप से यदि आप इसे git blame -C के साथ वास्तविक कठिन दिखने के लिए कहते हैं। यह भी कुछ है कि गिट इतना कॉम्पैक्ट और तेज़ क्यों है, संरचना बहुत सरल है, चलने के लिए बहुत सस्ता है और खुद को दोहराना नहीं है।

डाउनसाइड्स में से एक यह है कि गिट फ़ाइल प्रतियों और नामों को संग्रहीत नहीं करता है, यह अनुमान लगाता है, और कभी-कभी यह गलत होता है।

This blog entry एक अच्छी तरह से पचाने वाली लेकिन अभी भी विस्तृत चर्चा प्रदान करता है कि कौन सी सामग्री ट्रैकिंग गिट खरीदती है। यदि आप और जानना चाहते हैं, तो आप watch Linus' Google Tech Talk on Git या read the transcript कर सकते हैं।

Answer 2

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

इस दृष्टिकोण को एक अवधारणात्मक सरल भंडार प्रारूप का लाभ है। यह महत्वपूर्ण है क्योंकि आपका भंडार आपका इतिहास है, और इतिहास को सबसे सरल प्रारूप में संरक्षित किया जाना चाहिए।

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

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