git - लिनुस टॉर्वाल्ड्स का क्या मतलब है जब वह कहता है कि गेट "कभी भी नहीं" एक फ़ाइल को ट्रैक करता है?




version-control (4)

"git फाइलों को ट्रैक नहीं करता है" मूल रूप से इसका मतलब है कि git के कमिट्स में एक फाइल ट्री स्नैपशॉट होता है जो पेड़ में एक पथ को "blob" से जोड़ता है और कमिट के इतिहास को ट्रैक करने वाला एक कमिट ग्राफ होता है । "Git log" और "git blame" जैसी कमांड के द्वारा बाकी सब को फिर से बनाया गया है। यह पुनर्निर्माण विभिन्न विकल्पों के माध्यम से बताया जा सकता है कि फ़ाइल-आधारित परिवर्तनों के लिए कितना कठिन होना चाहिए। डिफ़ॉल्ट हेयुरेटिक्स यह निर्धारित कर सकते हैं कि एक बूँद परिवर्तन के बिना फ़ाइल ट्री में कब परिवर्तन होता है, या जब एक फ़ाइल पहले से एक अलग बूँद के साथ जुड़ा हुआ है। संपीड़न तंत्र Git का उपयोग बूँद / फ़ाइल सीमाओं के बारे में पूरी तरह से परवाह नहीं करता है। यदि सामग्री कहीं पहले से है, तो यह विभिन्न बूँदें को संबद्ध किए बिना भंडार विकास को छोटा बनाए रखेगा।

अब वह भंडार है। Git में एक वर्किंग ट्री भी होता है और इस वर्किंग ट्री में ट्रैक और अनट्रैक फाइल्स होती हैं। केवल ट्रैक की गई फ़ाइलों को इंडेक्स (स्टेजिंग एरिया? कैश?) में रिकॉर्ड किया जाता है और केवल वहीं ट्रैक किया जाता है जो इसे रिपॉजिटरी में बनाता है।

सूचकांक फ़ाइल-उन्मुख है और इसमें हेरफेर करने के लिए कुछ फ़ाइल-उन्मुख कमांड हैं। लेकिन रिपॉजिटरी में जो समाप्त होता है, वह सिर्फ फाइल ट्री स्नैपशॉट और संबद्ध ब्लॉब डेटा और कमिट के पूर्वजों के रूप में होता है।

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

यह तोड़फोड़ जैसी प्रणालियों के साथ अलग है जो इतिहास को फिर से संगठित करने के बजाय रिकॉर्ड करता है । यदि यह रिकॉर्ड पर नहीं है, तो आपको इसके बारे में सुनने को नहीं मिलता है।

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

2007 में Google पर अपने टेक टॉक के दौरान गित ने कितनी फाइलों को संभाल सकते हैं, यह पूछे जाने पर लिनुस टॉर्वाल्ड्स का हवाला देते हुए कहा:

... Git आपकी सामग्री को ट्रैक करता है। यह कभी भी एक फ़ाइल को ट्रैक नहीं करता है। आप Git में फ़ाइल ट्रैक नहीं कर सकते। आप क्या कर सकते हैं आप एक ऐसी परियोजना को ट्रैक कर सकते हैं जिसमें एक एकल फ़ाइल है, लेकिन अगर आपकी परियोजना में एक ही फ़ाइल है, तो सुनिश्चित करें कि आप ऐसा कर सकते हैं और कर सकते हैं, लेकिन यदि आप 10,000 फ़ाइलों को ट्रैक करते हैं, तो गिट कभी भी उन्हें व्यक्तिगत फ़ाइलों के रूप में नहीं देख सकते हैं। Git पूरी सामग्री के रूप में सब कुछ सोचता है। Git का सारा इतिहास पूरी परियोजना के इतिहास पर आधारित है ...

( here टेप

फिर भी, जब आप Git पुस्तक में गोता लगाते हैं, तो पहली बात जो आपको बताई जाती है वह यह है कि Git में एक फ़ाइल को ट्रैक या अनट्रैक किया जा सकता है। इसके अलावा, यह मुझे ऐसा लगता है जैसे पूरे गिट अनुभव को फ़ाइल संस्करण की ओर बढ़ाया जाता है। git diff या git status आउटपुट का उपयोग करते समय प्रति फ़ाइल आधार पर प्रस्तुत किया जाता है। git add का उपयोग करते समय आपको प्रति फ़ाइल के आधार पर चयन करने के लिए भी मिलता है। तुम भी एक फ़ाइल के आधार पर इतिहास की समीक्षा कर सकते हैं और तेजी से बिजली है।

इस कथन की व्याख्या कैसे की जानी चाहिए? फ़ाइल ट्रैकिंग के संदर्भ में, सीवीएस जैसे अन्य स्रोत नियंत्रण प्रणालियों से कैसे अलग है?


Git किसी फ़ाइल को सीधे ट्रैक नहीं करता है, लेकिन रिपॉजिटरी के स्नैपशॉट को ट्रैक करता है, और ये स्नैपशॉट फ़ाइलों से मिलकर होते हैं।

यहाँ इसे देखने का एक तरीका है।

अन्य संस्करण नियंत्रण प्रणालियों (SVN, Rational ClearCase) में, आप किसी फ़ाइल पर राइट क्लिक कर सकते हैं और उसका परिवर्तन इतिहास प्राप्त कर सकते हैं

Git में, कोई प्रत्यक्ष कमांड नहीं है जो ऐसा करता है। इस प्रश्न को देखें। आपको आश्चर्य होगा कि कितने अलग-अलग उत्तर हैं। कोई एक सरल उत्तर नहीं है क्योंकि Git बस किसी फ़ाइल को ट्रैक नहीं करता है , उस तरीके से नहीं जिस प्रकार SVN या ClearCase करता है।


भ्रामक बिट यहाँ है:

Git कभी भी उन्हें अलग-अलग फ़ाइलों के रूप में नहीं देखता है। Git पूरी सामग्री के रूप में सब कुछ सोचता है।

गिट अक्सर अपने रेपो में वस्तुओं के स्थान पर 160 बिट हैश का उपयोग करता है। फाइलों का एक पेड़ मूल रूप से प्रत्येक की सामग्री (प्लस कुछ मेटाडेटा) के साथ जुड़े नामों और हैश की एक सूची है।

लेकिन 160 बिट हैश विशिष्ट रूप से सामग्री (गिट डेटाबेस के ब्रह्मांड के भीतर) की पहचान करता है। तो सामग्री के रूप में हैश के साथ एक पेड़ अपने राज्य में सामग्री शामिल करता है

यदि आप किसी फ़ाइल की सामग्री की स्थिति बदलते हैं, तो उसका हैश बदल जाता है। लेकिन अगर इसका हैश बदलता है, तो फ़ाइल नाम की सामग्री से जुड़ा हैश भी बदल जाता है। जो बदले में "डायरेक्टरी ट्री" के हैश को बदलता है।

जब एक गिट डेटाबेस एक निर्देशिका ट्री को संग्रहीत करता है, तो उस निर्देशिका ट्री का अर्थ होता है और इसमें सभी उपनिर्देशिकाओं की सामग्री और उसमें सभी फाइलें शामिल होती हैं

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

यदि आपने ट्री को किसी फ़ाइल सिस्टम में अनुक्रमित किया है, तो सभी .it फ़ोल्डरों को हटा दिया है, और पेड़ को अपने डेटाबेस में वापस जोड़ने के लिए कहा है, आप डेटाबेस में कुछ भी नहीं जोड़ने के साथ समाप्त हो जाएंगे - तत्व पहले से ही होगा।

यह जिट ​​के हैश को एक संदर्भ के रूप में अपरिवर्तनीय डेटा के लिए सूचक के रूप में सोचने में मदद कर सकता है।

यदि आपने उसके चारों ओर एक एप्लिकेशन बनाया है, तो एक दस्तावेज़ पृष्ठों का एक गुच्छा होता है, जिसमें परतें होती हैं, जिसमें समूह होते हैं, जिनमें ऑब्जेक्ट होते हैं।

जब आप किसी ऑब्जेक्ट को बदलना चाहते हैं, तो आपको इसके लिए एक पूरी तरह से नया समूह बनाना होगा। यदि आप एक समूह बदलना चाहते हैं, तो आपको एक नई परत बनानी होगी, जिसमें एक नया पृष्ठ होना चाहिए, जिसे एक नए दस्तावेज़ की आवश्यकता है।

हर बार जब आप किसी एकल ऑब्जेक्ट को बदलते हैं, तो यह एक नया दस्तावेज़ बनाता है। पुराना दस्तावेज़ मौजूद है। नए और पुराने दस्तावेज़ अपनी अधिकांश सामग्री साझा करते हैं - उनके पास एक ही पृष्ठ (1 को छोड़कर) है। उस एक पृष्ठ में एक ही परतें हैं (1 को छोड़कर)। उस परत में समान समूह हैं (1 को छोड़कर)। उस समूह में समान वस्तुएं हैं (1 को छोड़कर)।

और उसी से मेरा तात्पर्य तार्किक रूप से एक प्रति से है, लेकिन कार्यान्वयन-वार यह उसी अपरिवर्तनीय वस्तु के लिए एक और संदर्भ गिना जाने वाला सूचक है।

एक git रेपो बहुत कुछ ऐसा है।

इसका मतलब यह है कि किसी दिए गए परिवर्तन में अपना प्रतिबद्ध संदेश (हैश कोड के रूप में) होता है, इसमें उसका कार्य वृक्ष होता है, और इसमें उसके मूल परिवर्तन होते हैं।

उन मूल परिवर्तनों में उनके मूल परिवर्तन शामिल हैं, सभी तरह से वापस।

गिट रेपो का वह हिस्सा जिसमें इतिहास होता है वह परिवर्तनों की श्रृंखला है। "निर्देशिका" पेड़ के ऊपर एक स्तर पर परिवर्तन की यह श्रृंखला - एक "निर्देशिका" पेड़ से, आप विशिष्ट रूप से एक परिवर्तन सेट और परिवर्तनों की श्रृंखला में नहीं जा सकते।

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

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

तो git एक "फ़ाइल इतिहास" को एक साथ पैचवर्क कर सकता है।

लेकिन यह फ़ाइल इतिहास "संपूर्ण परिवर्तन" के कुशल पार्सिंग से आता है, न कि फ़ाइल के एक संस्करण से दूसरे लिंक से।


मैं ब्रायन एम से सहमत हूं । कार्लसन का जवाब : फाइल-ओरिएंटेड और कम-ओरिएंटेड वर्जन कंट्रोल सिस्टम के बीच लाइनस वास्तव में अलग-थलग है। लेकिन मुझे लगता है कि इसके अलावा भी बहुत कुछ है।

मेरी पुस्तक में , जो कि रुकी हुई है और कभी समाप्त नहीं हो सकती है, मैंने संस्करण नियंत्रण प्रणालियों के लिए एक taxonomy साथ आने की कोशिश की। मेरे वर्गीकरण में इस बात के लिए कि हम यहां क्या रुचि रखते हैं, संस्करण नियंत्रण प्रणाली की परमाणुता है। देखें कि वर्तमान में पेज 22 क्या है। जब एक वीसीएस में फाइल-लेवल एटमॉसिटी होती है, तो वास्तव में प्रत्येक फाइल के लिए एक इतिहास होता है। VCS को फ़ाइल का नाम याद रखना चाहिए और प्रत्येक बिंदु पर उसके साथ क्या हुआ।

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

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

जब आप Git का उपयोग करके आपको एक फ़ाइल का इतिहास दिखाने के लिए कहें:

git log [--follow] [starting-point] [--] path/to/file

Git वास्तव में कर रहा है प्रतिबद्ध इतिहास घूम रहा है, जो एकमात्र इतिहास Git है, लेकिन आपको इनमें से कोई भी नहीं दिखा रहा है :

  • कमिट एक नॉन-मर्ज कमिट है, और
  • उस प्रतिबद्ध के माता-पिता के पास भी फाइल होती है, लेकिन माता-पिता की सामग्री में अंतर होता है, या प्रतिबद्ध के माता-पिता के पास फाइल बिल्कुल नहीं होती है

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






version-control