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


283

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

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

(प्रतिलेख यहाँ ।)

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

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


20
reddit.com/r/git/comments/5xmrkv/what_is_a_snapshot_in_git - "जहां आप इस समय हैं, मुझे संदेह है कि यह महसूस करना अधिक महत्वपूर्ण है कि Git उपयोगकर्ताओं के बीच फ़ाइलों को प्रस्तुत करता है और यह उनके साथ आंतरिक रूप से कैसे व्यवहार करता है ।" जैसा कि उपयोगकर्ता को प्रस्तुत किया गया है, एक स्नैपशॉट में पूरी फाइलें होती हैं, न कि केवल भिन्न होती हैं। लेकिन आंतरिक रूप से, हां, Git पैकफाइल्स को उत्पन्न करने के लिए भिन्नता का उपयोग करता है जो कुशलता से स्टोर करता है। " (यह तेज विपरीत है, उदा। तोड़फोड़।)
user2864740

5
Git फ़ाइलों को ट्रैक नहीं करता है, यह बदलावों को ट्रैक करता है । अधिकांश संस्करण नियंत्रण प्रणालियां फाइलों को ट्रैक करती हैं। उदाहरण के तौर पर कि यह कैसे / क्यों मायने रखता है, एक खाली निर्देशिका में जांच करने की कोशिश करें (स्पोलियर: आप नहीं कर सकते, क्योंकि यह एक "खाली" बदलाव है)।
इलियट फ्रिस्क

12
@ElliottFrisch यह सही नहीं है। आपका विवरण उदाहरण के लिए करीब है जैसे कि डार्क्स क्या करता है। Git स्नैपशॉट्स को बदलता है, न कि चेंजेस को।
melpomene

4
मुझे लगता है कि उनका मतलब है कि Git किसी फ़ाइल को सीधे ट्रैक नहीं करता है। एक फ़ाइल में उसका नाम और सामग्री शामिल है। Git सामग्री को बूँद के रूप में ट्रैक करता है। केवल एक बूँद को देखते हुए, आप यह नहीं बता सकते हैं कि इसका संबंधित फ़ाइल नाम क्या है। यह अलग-अलग रास्तों के तहत अलग-अलग नामों वाली कई फाइलों की सामग्री हो सकती है। एक पथ नाम और एक बूँद के बीच के बंधन को एक वृक्ष वस्तु में वर्णित किया गया है।
एलपीकेके

3
संबंधित: रान्डल शवार्ट्ज ' लिनुस की चर्चा के लिए अनुवर्ती (एक Google टेक बात भी) - "... वास्तव में क्या गित है ... लिनुस ने कहा कि क्या गित नहीं है"।
पीटर मोर्टेंसन

जवाबों:


316

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

दूसरी ओर, Git पूरे प्रोजेक्ट की स्थिति का स्नैपशॉट लेता है। फ़ाइलों को ट्रैक और स्वतंत्र रूप से संस्करणित नहीं किया जाता है; रिपॉजिटरी में एक संशोधन पूरे प्रोजेक्ट की स्थिति को संदर्भित करता है, न कि एक फ़ाइल को।

जब Git किसी फ़ाइल को ट्रैक करने के लिए संदर्भित करता है, तो इसका मतलब बस यह है कि इसे परियोजना के इतिहास में शामिल किया जाना है। लिनस की बात गीट संदर्भ में फाइलों को ट्रैक करने की बात नहीं कर रही थी, बल्कि सीवीएस और आरसीएस मॉडल के विपरीत गिट में इस्तेमाल किए गए स्नैपशॉट आधारित मॉडल के साथ थी।


4
आप यह जोड़ सकते हैं कि यही कारण है कि सीवीएस और तोड़फोड़ में, आप $Id$एक फ़ाइल में टैग का उपयोग कर सकते हैं । वही गिट में काम नहीं करता है, क्योंकि डिजाइन अलग है।
जेरिट

58
और सामग्री एक फ़ाइल के लिए बाध्य नहीं है जैसा कि आप उम्मीद करेंगे। एक फ़ाइल के कोड का 80% दूसरे में ले जाने का प्रयास करें। Git स्वचालित रूप से एक फ़ाइल चाल + 20% परिवर्तन का पता लगाता है, तब भी जब आप मौजूदा फ़ाइलों में कोड को चारों ओर ले जाते हैं।
एलो

13
@allo उस के साइड-इफ़ेक्ट के रूप में, git एक काम कर सकता है जो दूसरे नहीं कर सकते: जब दो फ़ाइलों को मर्ज किया जाता है और आप "git blame -C" का उपयोग करते हैं, तो git दोनों हिस्टरी को नीचे देख सकता है। फ़ाइल-आधारित ट्रैकिंग में, आपको चुनना होगा कि कौन सी मूल फ़ाइल असली मूल है, और अन्य पंक्तियाँ सभी ब्रांड-नई दिखाई देती हैं।
इजाकाता

1
@allo, इज़काता - और यह क्वेरी इकाई है जो क्वेरी टाइम पर रेपो सामग्री (संदर्भित पेड़ों और ब्लॉब्स के बीच प्रतिबद्धताओं और मतभेदों) का विश्लेषण करके यह सब काम करती है, बजाय इसके कि उचित इकाई को निर्दिष्ट करने या संश्लेषित करने के लिए कमिटिंग इकाई और उसके मानव उपयोगकर्ता की आवश्यकता होती है। प्रतिबद्ध समय पर यह जानकारी - और न ही रेपो टूल डेवलपर इस क्षमता को डिजाइन और कार्यान्वित करने के लिए और उपकरण तैनात होने से पहले संबंधित मेटाडेटा स्कीमा। टॉर्वाल्ड्स ने तर्क दिया कि इस तरह के विश्लेषण केवल समय के साथ बेहतर हो जाएंगे, और दिन के बाद से हर गिट रेपो के सभी इतिहास को फायदा होगा।
जेरेमी

1
@ यालो यप, और इस तथ्य को घर करने के लिए कि फ़ाइल स्तर पर काम नहीं करता है, आपको एक बार में एक फ़ाइल में सभी परिवर्तनों को करने की आवश्यकता नहीं है; आप फ़ाइल के अन्य परिवर्तनों को कमिट के बाहर मनमाने ढंग से कर सकते हैं। बेशक इसके लिए यूआई लगभग उतना सरल नहीं है, लेकिन अधिकांश ऐसा नहीं करते हैं, लेकिन इसका उपयोग शायद ही कभी होता है।
एल्विन थॉम्पसन

103

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

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

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

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

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

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

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

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

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


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

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

@torek मुझे फ़ाइल इतिहास अनुरोध का जवाब देने के बारे में आपके विवरण के बारे में संदेह है, लेकिन मुझे लगता है कि यह अपने स्वयं के उचित प्रश्न का हकदार है: stackoverflow.com/questions/55616349/…
Simón Ramírez Amaya

@torek आपकी पुस्तक के लिंक के लिए धन्यवाद, मैंने इसके जैसा कुछ और नहीं देखा है।
gnarledRoot

17

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


12

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

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

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

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

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

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


7

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

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

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

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


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

मैंने आपके द्वारा जुड़े प्रश्न के पहले कुछ उत्तरों को स्किम कर दिया है और उनमें से सभी का उपयोग करते हैं git logया उस के शीर्ष पर बनाए गए कुछ प्रोग्राम (या कुछ अन्य जो एक ही चीज़ करते हैं)। लेकिन यहां तक ​​कि अगर बहुत सारे अलग-अलग तरीके थे, जैसा कि जोह कहते हैं कि यह शाखा इतिहास दिखाने के लिए भी सही है। (यह भी git log -p <file>बनाया गया है और ठीक यही करता है)
Voo

क्या आप सुनिश्चित हैं कि SVN आंतरिक रूप से प्रति फ़ाइल परिवर्तन बदलता है? मैंने पहले से ही कुछ समय में इसका इस्तेमाल नहीं किया है, लेकिन मुझे प्रोजेक्ट फ़ाइल संरचना के प्रतिबिंब के बजाय, संस्करण आईडी जैसी फ़ाइलों का नाम याद है।
अर्तुर बियासीडोस्की

3

ट्रैकिंग "सामग्री", संयोग से, वह है जिसके कारण खाली निर्देशिकाओं को ट्रैक नहीं किया जाता है।
इसीलिए, यदि आप किसी फ़ोल्डर की अंतिम फ़ाइल को rit करते हैं, तो फ़ोल्डर स्वयं डिलीट हो जाता है

यह हमेशा मामला नहीं था, और केवल Git 1.4 (मई 2006) ने लागू किया कि 443f833 प्रतिबद्ध "ट्रैकिंग सामग्री" नीति :

git स्टेटस: खाली निर्देशिकाओं को छोड़ें, और सभी अनटैक की गई फ़ाइलों को दिखाने के लिए -u जोड़ें

डिफ़ॉल्ट रूप से, हम --others --directoryउनकी सामग्री के बिना निर्बाध निर्देशिका (उपयोगकर्ता का ध्यान पाने के लिए) का उपयोग करने के लिए (अव्यवस्थित आउटपुट के लिए) दिखाते हैं।
खाली निर्देशिका दिखाने का कोई मतलब नहीं है, इसलिए --no-empty-directoryजब हम ऐसा करते हैं तो गुजरते हैं ।

देते हुए -u(या --untracked) इस अनुपयोगी को निष्क्रिय कर देता है ताकि उपयोगकर्ता को सभी अनटैक की गई फाइलें मिल सकें।

यह 8 साल बाद जनवरी 2011 में 8fe533 , Git v1.7.4 के साथ गूँज रहा था।

यह सामान्य UI दर्शन को ध्यान में रखते हुए है: गिट ट्रैक सामग्री, खाली निर्देशिका नहीं।

इस बीच, Git 1.4.3 (सितंबर 2006) के साथ, Git ने गैर-रिक्त फ़ोल्डर में अनट्रैक की गई सामग्री को सीमित करना शुरू कर दिया, जिसमें 2074cb0 शामिल है :

यह पूरी तरह से अनट्रेक्ड निर्देशिकाओं की सामग्री को सूचीबद्ध नहीं करना चाहिए, लेकिन केवल उस निर्देशिका का नाम (प्लस अनुगामी ' /') होना चाहिए।

ट्रैकिंग सामग्री वह है जो git दोष की अनुमति देती है, बहुत जल्दी (Git 1.4.4, Oct 2006, प्रतिबद्ध cee7f24 ) अधिक प्रदर्शन करने वाला है:

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

वह (ट्रैकिंग सामग्री) भी है जो Git API में Git ऐड डालती है , Git 1.5.0 के साथ (Dec 2006, कमिट 366bfcb )

'git add' को इंडेक्स में प्रथम श्रेणी का उपयोगकर्ता के अनुकूल इंटरफेस बनाते हैं

यह सूचकांक के बारे में बात किए बिना एक उचित मानसिक मॉडल का उपयोग करके सूचकांक की शक्ति को सामने लाता है।
उदाहरण के लिए देखें कि git-add man पेज से सभी तकनीकी चर्चा को कैसे हटा दिया गया है।

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

यही git add --interactiveसंभव है, उसी Git 1.5.0 के साथ ( 5cde71d प्रतिबद्ध )

चयन करने के बाद, इंडेक्स में चयनित रास्तों के लिए कार्यशील ट्री फ़ाइलों की सामग्री को स्टेज करने के लिए एक खाली लाइन के साथ उत्तर दें ।

यही कारण है कि, एक निर्देशिका से सभी सामग्रियों को पुन: प्राप्त करने के लिए, आपको -rविकल्प पारित करने की आवश्यकता है , न कि केवल निर्देशिका नाम के रूप में <path>(अभी भी जीआईटी 1.5.0, 9f95069 प्रतिबद्ध )।

फ़ाइल के बजाय फ़ाइल सामग्री को देखना वही है जो मर्ज परिदृश्य को 1de70db (Git v2.18.0-rc0, Apr. 2018) में वर्णित की अनुमति देता है।

नाम बदलने / विरोध जोड़ने के साथ निम्नलिखित मर्ज पर विचार करें:

  • पक्ष A: संशोधित foo, असंबंधित जोड़ेंbar
  • पक्ष B: नाम बदलें foo->bar(लेकिन मोड या सामग्री को संशोधित न करें)

इस स्थिति में, मूल फू, ए के फू और बी के तीन-तरफा मर्ज का barपरिणाम वांछित मोडनामे में barहोगा उसी मोड / सामग्री के साथ जो ए के लिए था foo
इस प्रकार, A में फ़ाइल के लिए सही मोड और सामग्री थी, और इसमें सही pathname मौजूद था (क्रमशः, bar)।

37b65ce , Git v2.21.0-rc0, Dec. 2018, हाल ही में टकराव संघर्ष प्रस्तावों में सुधार हुआ।
और प्रतिबद्ध bbafc9c फाइटर नाम बदलने / नाम बदलने (2to1) के लिए हैंडलिंग में सुधार करके, फ़ाइल सामग्री पर विचार करने के महत्व को दिखाता है :

  • फ़ाइलों को संग्रहीत करने के बजाय collide_path~HEADऔर collide_path~MERGE, फ़ाइलों को दो-तरफ़ा मर्ज किया गया और रिकॉर्ड किया गया है collide_path
  • अनुक्रम में नामांकित पक्ष पर मौजूद नामांकित फ़ाइल के संस्करण को रिकॉर्ड करने के बजाय (इस प्रकार बिना नाम के इतिहास के पक्ष में फ़ाइल में किए गए किसी भी परिवर्तन को अनदेखा करते हुए), हम नामांकित पर तीन-तरफ़ा सामग्री मर्ज करते हैं पथ, फिर स्टोर करें या तो चरण 2 या चरण 3 पर।
  • ध्यान दें कि चूंकि प्रत्येक नाम के लिए मर्ज की गई सामग्री में विरोध हो सकता है, और फिर हमें दो नामांकित फ़ाइलों को मर्ज करना होगा, हम नेस्टेड संघर्ष मार्करों के साथ समाप्त हो सकते हैं।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.