अंदर से GIT: परिचय (अनुवाद)

नमस्कार, हेब्र! मैं आपके लिए टॉमी गुणन द्वारा "कंप्यूटर वैज्ञानिकों के लिए गिट" लेख का अनुवाद प्रस्तुत करता हूं।

GIT इनसाइड आउट: एक परिचय

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

कौन रुचि रखेगा और संभवतः उपयोगी होगा: जो लोग हर दिन Git के साथ काम करते हैं (यानी, हर दूसरे, यदि पहले सॉफ़्टवेयर डेवलपर नहीं हैं), और जो इसके काम के तंत्र को बेहतर ढंग से समझना चाहते हैं।

नोट: लेख की बेहतर समझ के लिए, किसी को ऐसे जानवर के बारे में विचार करना चाहिए, जैसे कि एक निर्देशयुक्त चक्रीय ग्राफ (DAG) ।

वस्तु भंडारण

Git ऑब्जेक्ट रिपॉजिटरी है, मोटे तौर पर बोल, एक DAG जिसमें विभिन्न प्रकार की वस्तुएँ हैं। ऑब्जेक्ट्स को संपीड़ित रूप में संग्रहीत किया जाता है और SHA-1 हैश द्वारा पहचाना जाता है (यह फ़ाइल की सामग्री का एक हैश नहीं है जो ऑब्जेक्ट का प्रतिनिधित्व करता है, लेकिन Git में इसकी प्रस्तुति है)।

बूँद

बूँद एक साधारण वस्तु है, बस बाइट्स का एक संग्रह है। यह एक फ़ाइल, एक प्रतीकात्मक लिंक, या जो कुछ भी हो सकता है। शब्दार्थ वस्तु द्वारा निर्धारित होते हैं जो इस बूँद की ओर इशारा करते हैं।

ट्री (ट्री)

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

यदि कोई नोड DAG में किसी अन्य नोड को इंगित करता है , तो वे कहते हैं कि यह उस नोड पर निर्भर करता है, अर्थात्। इसके बिना अस्तित्व में नहीं रह सकते। कचरा संग्रह ( git gc कमांड) का उपयोग करके कोई भी अंक नहीं हटाया जा सकता है या git fsck --lost- मिली कमांड का उपयोग करके पुनर्स्थापित किया जा सकता है।

कमिट

कमेटी एक पेड़ का उल्लेख करती है, जिस समय कमिट बनाई गई थी, उस समय Git में फाइलों की स्थिति का प्रतिनिधित्व करता है। इसके अलावा, कमेटी अपने माता-पिता के लिए अन्य कमिट्स का उल्लेख कर सकती है:

• यदि प्रतिबद्ध में 1 से अधिक माता-पिता हैं, तो इसका मतलब है कि यह मर्ज ऑपरेशन (मर्ज) का वर्णन करता है
• यदि कमिट का कोई माता-पिता नहीं है, तो यह तथाकथित प्रारंभिक (प्रारंभिक) कमिट (यानी रिपॉजिटरी में पहला) है
• ऐसे मामले भी हो सकते हैं जब रिपॉजिटरी में 1 से अधिक प्रारंभिक समितियां हैं - इसका मतलब आमतौर पर दो अलग-अलग रिपॉजिटरी को मर्ज करना है

प्रतिबद्ध वस्तु का शरीर प्रतिबद्ध संदेश है ।

Refs (लिंक)

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

Git कमिट कमांड DAG में एक नया नोड जोड़ता है और एक बुकमार्क को वर्तमान शाखा के लिए स्थानांतरित करता है।

लिंक सिर / शाखा नाम स्थान में हैं , लेकिन सिर का हिस्सा छोड़ा जा सकता है।

HEAD लिंक अलग खड़ा है - यह एक नोड को इंगित नहीं करता है, लेकिन किसी अन्य लिंक के लिए - यह वर्तमान सक्रिय शाखा का एक संकेतक है।

रिमोट रेफ

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

टैग (टैग)

एक टैग एक डीएजी नोड और एक स्टिकर (दूसरे रंग) का एक संयोजन है। टैग प्रतिबद्ध करने के लिए इंगित करता है, और इसमें एक वैकल्पिक संदेश और GPG हस्ताक्षर शामिल हैं। एक स्टिकर (लिंक) टैग तक पहुंचने का एक सरल तरीका है, और नुकसान के मामले में, इसे git fsck --lost- मिली कमांड के साथ पुनर्स्थापित किया जा सकता है।

इस प्रकार, जीआईटी रिपॉजिटरी डीएजी और लिंक का एक संयोजन है।

कहानी

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

सबसे सरल भंडार। हमने बस एक ही कमिट के साथ रिमोट रिपॉजिटरी की नकल ( git क्लोन ) की।

यहाँ हमने दूरस्थ रिपॉजिटरी को पढ़ा ( git fetch ) किया और 1 नई प्रतिबद्धता प्राप्त की, लेकिन अभी तक इसे हमारी शाखा में विलय नहीं किया है।

यहां यह है कि git मर्ज के रिमोट / MYSERVER / मास्टर कमांड को चलाने के बाद क्या होता है। चूंकि मर्ज को तेजी से आगे बढ़ाया गया था (हमारी स्थानीय शाखा में कोई स्थानीय कमिट नहीं थे), निम्नलिखित हुआ: हमारी कार्य प्रतिलिपि की फाइलें बदल गईं, और सूचक को शाखा में भी स्थानांतरित किया गया।

स्थानीय रूप से कमिट करें और उसके बाद गिट लाएं । अब हमारे पास लोकल और रिमोट कमिटमेंट दोनों हैं। जाहिर है, आपको मर्ज की जरूरत है।

यह git मर्ज रीमोट / MYSERVER / मास्टर कमांड का परिणाम है। चूंकि हमारे पास एक स्थानीय प्रतिबद्धता थी, यह तेजी से आगे नहीं है, और डीएजी में विलय के लिए एक अलग प्रतिबद्धता बनाई गई है। सूचना - उसके पास 2 अभिभावक वचन हैं।

इसी तरह से हमारा पेड़ कई शाखाओं, दोनों शाखाओं (स्थानीय और दूरस्थ) + मर्ज में देखेगा। आप यह स्पष्ट रूप से देख सकते हैं कि कैसे GIT DAG हमारे कार्यों के पूरे इतिहास को कैप्चर करता है।

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

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

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

यहां बताया गया है कि यह कचरा संग्रहण (या दुर्गम की अनदेखी करने) के बाद कैसा दिखता है, और उस शाखा के शीर्ष पर एक नई प्रतिबद्धता का निर्माण करता है जिसे रिबास लागू किया गया था।

इसके अलावा, रिबास के साथ, आप एक ही समय में कई प्रतिबद्ध एस को स्थानांतरित कर सकते हैं।

वह सब है। मुझे उम्मीद है कि सामग्री उपयोगी होगी।