संशोधन संख्याओं के बजाय git हैश का उपयोग क्यों करता है?

Question

मैं हमेशा सोचता था कि git रिवीजन नंबरों पर हैश क्यों पसंद करता है। (मेरी राय में) संदर्भित करने के लिए संशोधन संख्या बहुत स्पष्ट और आसान है: किसी के बारे में यह कहने में अंतर है कि संशोधन 1200 पर एक नज़र डालें या 92ba93e करें! (सिर्फ एक उदाहरण देने के लिए)।

तो, क्या इस डिजाइन का कोई कारण है?

Comments

आप "v1.0" के साथ एक कमेंट टैग कर सकते हैं और फिर उस टैग के द्वारा कमिट का उल्लेख कर सकते हैं। देखें git-scm.com/book/en/v2/Git-Basics-Tagging

— माइकल ड्यूरेंट

Answer 1

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

Comments

आप बाज़ार के तरीके को देखना चाहते हैं - एक DVCS जो अभी भी संशोधन संख्या बनाए रखता है। केवल गारंटी यह है कि एक शाखा के भीतर संशोधन संख्याएं अद्वितीय हैं।

— krlmlr

@krlmlr Person 1: "Hey, <P2>, what was revision 12345 for?" P2: "Revision 12345 was commited by <P3>." P3: "I don't have a revision 12345..."- अगर मुझे सही से याद है, तो मर्क्यूरियल में भी इसी तरह की समस्या है। दूसरी ओर, यदि वे गिट का उपयोग कर रहे थे, तो वे सभी प्रत्येक वचन के लिए समान संदर्भ रखेंगे।

— इज़्काता

@ इज़काटा: P1: "Do you have revision with the GUID gdlmsnblngoijlafd-35345-fg?"... बाज़ार में अभी भी

— GUID हैं

@ इज़्का मर्क्यूरियल में एक जैसी समस्या नहीं है। वे हैश का उपयोग करते हैं, जैसे git। वे टाइपिंग में आसानी के लिए एक स्थानीय-केवल रिव नंबर प्रदान करते हैं।

— हैंक गे

git के साथ, हैश के पहले 5 अक्षर अक्सर पूर्ण पुनरीक्षण आईडी के लिए एक आशुलिपि का उपयोग करने के लिए अद्वितीय होते हैं।

— मेंडोटा

Answer 2

आपको वितरित सिस्टम में हैश की आवश्यकता होती है। मान लीजिए कि आप और एक सहयोगी दोनों एक ही भंडार पर काम कर रहे हैं और आप दोनों स्थानीय स्तर पर बदलाव करते हैं और फिर इसे आगे बढ़ाते हैं। किसको संशोधन संख्या १२०० मिलती है और कौन संशोधन संख्या १२०१ दी गई है, न ही पार्टी को एक दूसरे के बारे में कोई जानकारी है? एकमात्र यथार्थवादी तकनीकी समाधान एक ज्ञात पद्धति का उपयोग करके परिवर्तनों का एक हैश बनाना है और चीजों को उसी के आधार पर लिंक करना है।

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

Answer 3

डेटा अखंडता।

मैं वर्तमान जवाबों से सम्मानपूर्वक असहमत हूं। DVCS के लिए Hashes आवश्यक नहीं है, बाज़ार का रास्ता देखें । आप विश्व स्तर पर अद्वितीय पहचानकर्ता के साथ किसी भी अन्य प्रकार के साथ कर सकते हैं। हैश डेटा अखंडता की गारंटी के लिए एक उपाय है: वे हैश द्वारा संदर्भित वस्तु (प्रतिबद्ध, पेड़, ...) में निहित जानकारी के एक पाचन का प्रतिनिधित्व करते हैं। बिना हैश (यानी, प्रिमेज अटैक या टक्कर के हमले ) में बदलाव किए बिना सामग्री को बदलना मुश्किल माना जाता है, हालांकि यह असंभव है। (यदि आप वास्तव में इसमें हैं, तो मार्क स्टीवंस द्वारा 2011 के पेपर पर एक नज़र डालें )।

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

देखें अध्याय 9 अधिक जानकारी के लिए Git पुस्तक की।

Comments

यह एक सुरक्षा उपाय नहीं है, क्योंकि हैश को एक संशोधित प्रतिबद्ध के लिए आसानी से फिर से गणना की जा सकती है। यह केवल अखंडता के लिए उपयोग किया जाता है, गणना की गई हैश के खिलाफ सामग्री को सत्यापित करने के लिए - गिट में SHA-1 के उपयोग पर लिनुस टोरवाल्ड्स की इस टिप्पणी को देखें ।

— ली

@Lee: अगर चक का भंडार रिप्लेसमेंट हैश के संदर्भ में है कि ऐलिस और बॉब से अलग है, तो यह गारंटी है कि चक में भी अलग सामग्री है। दूसरी ओर, चक के लिए विभिन्न सामग्रियों के साथ एक रिपॉजिटरी तैयार करना बहुत मुश्किल है जो समान रूप से उनके संशोधन हैश को देखता है।

— krlmlr

@ ली: आपकी लिंक छूट गई। चलो इसे "डेटा अखंडता" कहते हैं ...

— krlmlr

सही उत्तर होना चाहिए

— SuperUberDuper

Answer 4

आम आदमी के शब्दों में:

• Hashes लगभग सार्वभौमिक रूप से अद्वितीय होने का इरादा है । इसकी गारंटी नहीं है, लेकिन यह बेहद कम संभावना है कि एक ही SHA विभिन्न सामग्रियों के लिए उत्पन्न हो। किसी दिए गए प्रोजेक्ट के लिए व्यावहारिक रूप में आप इसे अद्वितीय मान सकते हैं।
• संशोधन संख्या के साथ आपको विशेष रूप से 1200 संशोधन करने के लिए एक नाम स्थान का उपयोग करना होगा।
• गिट वितरित और / या केंद्रीकृत दोनों काम कर सकता है। तो आपको रिवीजन नंबर कैसे सही और अनोखे लगे?
• इसके अलावा संशोधन संख्याओं का उपयोग करने से यह गलत धारणा बन जाएगी कि नए संशोधनों में अधिक संख्याएँ होनी चाहिए, और यह ब्रांचिंग, विलय, रीबासिंग आदि के कारण सही नहीं होगा।
• आपके पास हमेशा कमिट करने के लिए टैग लगाने का विकल्प होता है।

Comments

अद्वितीय होने की गारंटी नहीं है, बस अविश्वसनीय रूप से अद्वितीय होने की संभावना है। :)

— dsw88

@ mustang2009cobra यह सच है।

— ट्यूलेंस कोरडोवा

यह संभव है कि मेरा परिवर्तन स्वीकार नहीं किया गया है क्योंकि हैश अपरिवर्तित है। यह बहुत अधिक संभावना है कि दो उल्काएं मेरे कंप्यूटर और कंप्यूटर को एक ही सेकंड में रिपॉजिटरी के साथ, कंप्यूटर को नष्ट करने और सभी को शामिल करने वाले को मारते हैं।

— gnasher729

Answer 5

गणितीय शब्दों में:

• एक कुल आदेश Git के प्रतिबद्ध अधिक monotonally संस्करण संख्या को बढ़ाने के लिए की आवश्यकता होगी।
• Git के कमिट्स एक निर्देशित, एसाइक्लिक ग्राफ (DAG) बनाते हैं जो केवल आंशिक रूप से / topologically के लिए आदेशित किया जा सकता है ।

Answer 6

वितरित VCS के लिए हैश अद्वितीय समाधान नहीं है। लेकिन जब एक वितरित प्रणाली के साथ सौदा किया जाता है, तो केवल घटनाओं का आंशिक क्रम दर्ज किया जा सकता है। (वीसीएस के लिए, घटना एक प्रतिबद्ध हो सकती है।) यही कारण है कि एक नीरस रूप से बढ़ती संशोधन संख्या बनाए रखना असंभव है। आमतौर पर हम ऐसे आंशिक आदेश वाले संबंध को रिकॉर्ड करने के लिए वेक्टर घड़ी (या वेक्टर टाइमस्टैम्प) की तरह कुछ अपनाते हैं । यह बाज़ार में उपयोग किया जाने वाला समाधान है ।

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