गिट - एक गिट प्रतिबद्ध आईडी क्या है?

Question

विशिष्ट रूप से काम करने के लिए उत्पन्न गिट प्रतिबद्ध आईडी कैसे हैं?

उदाहरण: 521747298a3790fde1710f3aa2d03b55020575aa

यह कैसे काम करता है? क्या वे प्रत्येक परियोजना के लिए केवल अद्वितीय हैं? या दुनिया भर में गिट भंडार के लिए?

Answer 1

एक गिट प्रतिबद्ध आईडी प्रतिबद्धता के बारे में हर महत्वपूर्ण बात के SHA-1 hash है। मैं उन सभी को सूचीबद्ध नहीं कर रहा हूं, लेकिन यहां महत्वपूर्ण हैं ...

• सामग्री, यह सब सिर्फ भिन्न नहीं है।
• प्रतिबद्ध तिथि।
• कमिटर का नाम और ईमेल पता।
• लॉग संदेश।
• पिछली प्रतिबद्धताओं की आईडी।

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

दूसरा, कोई भी अपनी आईडी देखकर तुरंत तुलना कर सकता है। यह गिट के नेटवर्क प्रोटोकॉल को बहुत ही कुशल बनाता है। यह देखने के लिए कि क्या वे समान हैं, दो कामों की तुलना करना चाहते हैं? पूरे diff को भेजने की ज़रूरत नहीं है, बस आईडी भेजें।

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

origin 
A - B - C - D - E [master] 

A - B [origin/master] 

git fetch origin के लिए नेटवर्क बातचीत कुछ इस तरह ...

• local अरे मूल, क्या शाखाओं आप की क्या ज़रूरत है चला जाता है?
• origin मैं ई
• local मैं ई की जरूरत नहीं है पर गुरु है, मैं बी पर अपने गुरु
• origin बी तुम कहते हो? मेरे पास बी है और यह ई का पूर्वज है। यह जांचता है। मुझे आपको सी, डी और ई

यही कारण है कि जब आप रीबेज के साथ एक प्रतिबद्धता को फिर से लिखते हैं, तो इसे बदलने के बाद सब कुछ। यहां एक उदाहरण दिया गया है।

A - B - C - D - E - F - G [master] 

मान लीजिए कि आप लॉग संदेश को थोड़ा सा बदलने के लिए डी को फिर से लिखते हैं। अब डी अब डी नहीं हो सकता है, इसे एक नई प्रतिबद्धता में कॉपी किया जाना है जिसे हम डी 1 कहते हैं।

A - B - C - D - E - F - G [master] 
     \ 
      D1 

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

A - B - C - D - E - F - G [master] 
     \ 
      D1 - E1 

और एफ से एफ 1 और जी से जी 1 के साथ।

A - B - C - D - E - F - G 
     \ 
      D1 - E1 - F1 - G1 [master] 

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

Answer 2

आप देख सकते हैं कि वास्तव में क्या

git cat-file commit HEAD 

चलाकर एक आईडी के लिए प्रतिबद्ध बनाने में चला जाता है यह तुम्हें कुछ दे देंगे

tree 07e239f2f3d8adc12566eaf66e0ad670f36202b5 
parent 543a4849f7201da7bed297b279b7b1e9a086a255 
author Justin Howard <justin.howard@example.com> 1426631449 -0700 
committer Justin Howard <justin.howard@example.com> 1426631471 -0700 

My commit message 

की तरह यह आप देता है:

1. की जांच योग पेड़ सामग्री
2. अभिभावक आईडी आईडी (यदि यह एक विलय है, टी यहाँ और अधिक माता-पिता हो जाएगा)
3. टाइमस्टैम्प
4. टाइमस्टैम्प
5. साथ प्रतिबद्ध प्रतिबद्ध संदेश की committer

Git यह सब लेता है और इसके बारे में एक SHA1 हैश करता है के साथ प्रतिबद्ध के लेखक। आप

(printf "commit %s\0" $(git cat-file commit HEAD | wc -c); git cat-file commit HEAD) | sha1sum 

चल रहा यह स्ट्रिंग commit एक अंतरिक्ष और cat-file पाठ ब्लॉब की बाइट गिनती के बाद मुद्रण द्वारा शुरू होता है द्वारा प्रतिबद्ध आईडी पुन: पेश कर सकते हैं। इसके बाद cat-file ब्लॉब उसके बाद एक शून्य बाइट जोड़ता है। तब यह सब sha1sum के माध्यम से चलाया जाता है।

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