🐎 🐷 🐗 गिट इंटर्नल्स: डेटा स्टोरेज और मर्ज 👉 🕴🏻 🤖

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

लेख के बारे में

सामग्री मुख्य रूप से पाठकों के लिए लक्षित है जो एक नियमित उपयोगकर्ता के रूप में गिट के साथ काम करने में सक्षम हैं और जो इसके साथ काम करने की मूल अवधारणाओं को जानते हैं। शायद लेख में संस्करण नियंत्रण प्रणालियों के डेवलपर्स के लिए कुछ नया नहीं होगा जो शाखाओं के आसान निर्माण और उनके विश्वसनीय विलय का समर्थन करते हैं। सभी जानकारी खुले स्रोतों से ली गई है, जिसमें Git स्रोतों (2d242fb3fc19fc9ba046accdd9210be8b9913f64) शामिल हैं।

डेटा संग्रहण: ऑब्जेक्ट

जानकारी प्रो Git के अंतिम अध्याय पर आधारित है।

गिट में, भंडारण इकाई एक वस्तु है, जो कि 40-वर्ण हैश sha1 द्वारा विशिष्ट रूप से निर्धारित की जाती है। Git वस्तुओं में लगभग सब कुछ संग्रहीत करता है: कमिट, फ़ाइल सामग्री, उनका पदानुक्रम। सबसे पहले, ऑब्जेक्ट .गित / ऑब्जेक्ट्स फ़ोल्डर में साधारण फाइलें हैं, और गिट gc को .pack फ़ाइलों में पैक किया जाता है, जिसे नीचे वर्णित किया जाएगा। डिस्क स्थान को बचाने के लिए, सभी वस्तुओं की सामग्री को अतिरिक्त रूप से zlib का उपयोग करके संपीड़ित किया जाता है।

आप टाइप करके ऑब्जेक्ट का पता लगा सकते हैं

 git cat-file -t .   : 
 
 BLOB ( ). 
    BLOB       .  :   ,     . 
 
  ,   BLOB    ,   ,   . ,        100 000       ,       : 
 
 $ git init Initialized empty Git repository in test/.git/ $ for((i=0;i<=100000;i++)); do echo $i; done >test.txt $ ls -lh 575K test.txt $ git add test.txt $ git commit -m "First commit" [master (root-commit) b3061d2] First commit 1 file changed, 100001 insertions(+) create mode 100644 test.txt $ find .git/objects -type f | xargs ls -lh 204K .git/objects/97/578648a76227f183339438512ad99a383b48cc #   ... $ echo 10001 >> test.txt $ git commit -m "Added another line" test.txt [master 0361e3c] Added another line 1 file changed, 1 insertion(+) # Git ,   1  $ find .git/objects -type f | xargs ls -lh 204K .git/objects/59/e434385635dccf949e66353f7a74a077357438 #   204K .git/objects/97/578648a76227f183339438512ad99a383b48cc #    ...  git cat-file -t .   : 
 
 BLOB ( ). 
    BLOB       .  :   ,     . 
 
  ,   BLOB    ,   ,   . ,        100 000       ,       : 
 
 $ git init Initialized empty Git repository in test/.git/ $ for((i=0;i<=100000;i++)); do echo $i; done >test.txt $ ls -lh 575K test.txt $ git add test.txt $ git commit -m "First commit" [master (root-commit) b3061d2] First commit 1 file changed, 100001 insertions(+) create mode 100644 test.txt $ find .git/objects -type f | xargs ls -lh 204K .git/objects/97/578648a76227f183339438512ad99a383b48cc #   ... $ echo 10001 >> test.txt $ git commit -m "Added another line" test.txt [master 0361e3c] Added another line 1 file changed, 1 insertion(+) # Git ,   1  $ find .git/objects -type f | xargs ls -lh 204K .git/objects/59/e434385635dccf949e66353f7a74a077357438 #   204K .git/objects/97/578648a76227f183339438512ad99a383b48cc #    ... 
 git cat-file -t .   : 
 
 BLOB ( ). 
    BLOB       .  :   ,     . 
 
  ,   BLOB    ,   ,   . ,        100 000       ,       : 
 
 $ git init Initialized empty Git repository in test/.git/ $ for((i=0;i<=100000;i++)); do echo $i; done >test.txt $ ls -lh 575K test.txt $ git add test.txt $ git commit -m "First commit" [master (root-commit) b3061d2] First commit 1 file changed, 100001 insertions(+) create mode 100644 test.txt $ find .git/objects -type f | xargs ls -lh 204K .git/objects/97/578648a76227f183339438512ad99a383b48cc #   ... $ echo 10001 >> test.txt $ git commit -m "Added another line" test.txt [master 0361e3c] Added another line 1 file changed, 1 insertion(+) # Git ,   1  $ find .git/objects -type f | xargs ls -lh 204K .git/objects/59/e434385635dccf949e66353f7a74a077357438 #   204K .git/objects/97/578648a76227f183339438512ad99a383b48cc #    ...

इसके अलावा, संपूर्ण ऑब्जेक्ट्स को संग्रहीत करने से आपको संघर्ष समाधान के साथ शाखाओं के विश्वसनीय विलय करने की अनुमति मिलती है। लेकिन उस पर और बाद में।

ट्री (FS पदानुक्रम)

ऑब्जेक्ट टाइप ट्री (अंग्रेजी ट्री ) को रिकॉर्ड की एक सूची में संग्रहीत किया जाता है जो फ़ाइल सिस्टम के पदानुक्रम से मेल खाती है। एक प्रविष्टि इस प्रकार है:

 < > < > <sha1 > < >

Git फ़ाइल अनुमतियों में केवल बहुत सीमित मान हो सकते हैं:

040000 - निर्देशिका;
100644 - नियमित फ़ाइल;
100755 - निष्पादन अधिकारों के साथ फाइल;
120000 एक प्रतीकात्मक कड़ी है।

ऑब्जेक्ट का प्रकार क्रमशः फ़ाइल और डायरेक्टरी के लिए एक BLOB या ट्री है। यही है, फ़ाइल सिस्टम की पूरी पदानुक्रम को रूट डायरेक्टरी के लिए टाइप ट्री के ऑब्जेक्ट में स्टोर किया जाता है, क्योंकि एक पेड़ के अंदर अन्य पेड़ों के लिंक हो सकते हैं।

कमिट

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

यदि प्रतिबद्ध एक सरल मर्ज है ( git merge < > ), तो इसके 2 माता-पिता होंगे: वर्तमान HEAD और < > द्वारा इंगित की गई प्रतिबद्धता। Git ऑक्टोपस मर्ज रणनीति का भी समर्थन करता है, जिसमें यह दो से अधिक शाखाओं को मिला सकता है। ऐसे कामों के लिए, माता-पिता की संख्या दो से अधिक होगी।

 $ git cat-file -p 0361e3c6d16fb3bbbcac8faa4e673667ea6fe20b tree ce9f2ced0ebb4346676879c7b12b92628378477f parent b3061d23da6f1a62dbc8f97b2a06e10e1aee2afa author Yuriy Nasretdinov <...> 1354450065 +0400 committer Yuriy Nasretdinov <...> 1354450065 +0400 Added another line

फ़ाइलें पैक करें

अगर Git ने वास्तव में सभी वस्तुओं को एक संपूर्ण (यद्यपि संपीड़ित) के रूप में संग्रहीत किया है, तो .it फ़ोल्डर फ़ाइलों का एक विशाल सेट होगा, और एक कार्य प्रतिलिपि की तुलना में उनमें से बहुत कुछ होगा। फिर भी, ऐसा नहीं होता है, लेकिन रहस्यमय पैक-फाइलें दिखाई देती हैं जिसमें ऑब्जेक्ट पैक किए जाते हैं। अजीब तरह से पर्याप्त है, इंटरनेट पर इस बारे में बहुत कम जानकारी है कि गिट इन फ़ाइलों में डेटा कैसे संग्रहीत करता है, इसलिए यहां लिनुस टोरवाल्ड्स के एक ईमेल का एक अंश है, जो इन रहस्यमय फाइलों के बारे में कुछ स्पष्टीकरण देता है (स्रोत: gcc.gnu.org/ml/gcc /2007-12/msg00165.html ):

छिपा हुआ पाठ

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

अन्य एससीएम में, एक डेल्टा-चेन आमतौर पर तय की जाती है। यह "आगे" हो सकता है
या "पीछे की ओर", और यह थोड़ा सा विकसित हो सकता है क्योंकि आप भंडार के साथ काम करते हैं,
लेकिन आम तौर पर यह कुछ के रूप में प्रतिनिधित्व एक एकल फ़ाइल में परिवर्तन की एक श्रृंखला है
एकल SCM इकाई का प्रकार। सीवीएस में, यह स्पष्ट रूप से *, वी फ़ाइल, और बहुत कुछ है
अन्य प्रणालियों के बजाय समान चीजें करते हैं।

गिट डेल्टा-चेन भी करते हैं, लेकिन यह उन्हें बहुत अधिक "शिथिल" करता है। वहाँ
कोई निश्चित इकाई नहीं है। डेल्टा किसी भी अन्य यादृच्छिक संस्करण के खिलाफ उत्पन्न होते हैं
यह एक अच्छा डेल्टा उम्मीदवार बनने के लिए है
सफल उत्तराधिकारी), और पूरी तरह से कठिन समूहन नियम नहीं हैं।

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

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

संक्षेप में, पैक फाइलों में, वस्तुओं को समानता (उदाहरण के लिए, प्रकार और आकार) द्वारा वर्गीकृत किया जाता है, जिसके बाद उन्हें "चेन" के रूप में सहेजा जाता है। श्रृंखला का पहला तत्व ऑब्जेक्ट का नवीनतम संस्करण है, और अगला एक पिछले एक के लिए एक अंतर है। ऑब्जेक्ट के नवीनतम संस्करणों को सबसे अधिक अनुरोधित माना जाता है, इसलिए वे श्रृंखला में उच्च संग्रहीत होते हैं।

इस प्रकार, गिट अभी भी स्टोर अलग है, लेकिन केवल प्रत्यक्ष डेटा भंडारण के स्तर पर। किसी भी एपीआई स्तर के दृष्टिकोण से, Git पूरे ऑब्जेक्ट पर काम करता है, जो आपको विभिन्न मर्ज रणनीतियों को लागू करने और आसानी से संघर्षों को हल करने की अनुमति देता है।

इतिहास का भंडारण

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

इसके अलावा, जैसा कि आपने देखा होगा, Git फ़ाइलों का नाम बदलने के बारे में जानकारी संग्रहीत नहीं करता है। यदि आपको यह समझने की आवश्यकता है कि फ़ाइल का नाम बदला गया है या नहीं, Git इसमें संग्रहीत वस्तुओं की सामग्री का विश्लेषण करता है और, कुछ (कस्टम) सहिष्णुता के साथ, यह मानता है कि फ़ाइल का नाम बदल दिया गया है।

विलय : तीन-तरफा विलय ( संकल्प रणनीति)

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

Diff3 एनालॉग का उपयोग करने के अलावा (Git में प्रयुक्त विशिष्ट कार्यान्वयन LibXDiff है), Git मक्खी पर फ़ाइल नाम बदलने की गणना भी करता है और इस जानकारी का उपयोग पेड़ की वस्तुओं को मर्ज करने के लिए करता है। विलय पदानुक्रमों को मर्ज करने वाली फ़ाइलों की तुलना में मौलिक रूप से कुछ भी जटिल नहीं है, लेकिन यह बहुत सारे विभिन्न प्रकार के संघर्षों को उत्पन्न करता है।

कैसे एक साधारण मामले में Git त्रिपक्षीय विलय का एक छोटा चित्रण करता है ( मैन गेट -मर्ज से लिया गया):

मान लीजिए कि हमारे पास ऐसी कहानी है और वर्तमान शाखा मास्टर है:
  A---B---C topic / D---E---F---G master 
फिर git मर्ज विषय, विषय के लिए किए गए परिवर्तनों को तब से दोहराएगा जब कहानी ने forked (कमिट E) किया और एक नई कमिट H बनाई जिसमें दो माता-पिता और एक प्रतिबद्ध संदेश होगा जो उपयोगकर्ता प्रदान करेगा।
  A---B---C topic / \ D---E---F---G---H master 

फिर भी, विषय और मास्टर शाखाओं में विकास जारी रखा जा सकता है, और फिर विलय अब इतना सरल नहीं लगेगा: हमारे पास एक से अधिक प्रतिबद्ध हो सकते हैं जो एक "सामान्य पूर्वज" की परिभाषा फिट बैठता है:

  A---B---C---K---L---M topic / \ D---E---F---G---H---N---O---P master

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

रिज़ॉल्यूशन रणनीति का उपयोग करके मर्ज करने के लिए , Git एक सामान्य पूर्वज के रूप में E को ले जाएगा और M और P को दो नए संस्करणों के रूप में लागू करेगा। यदि प्रतिबद्ध सी में कोई संघर्ष था, तो परस्पर विरोधी परिवर्तन को जीआईटी रिवर्ट के साथ वापस रोल किया जा सकता है (उदाहरण के लिए, यह प्रतिबद्ध के में किया गया था), तो अंतिम राज्य एम में अब संघर्ष नहीं होगा, और विलय होने पर कोई संघर्ष नहीं होगा।

'पुनरावर्ती' रणनीति द्वारा बनाया गया विलय

इस तरह एक कहानी की कल्पना करो:

  A---B---C---K---L---M topic / \ / D---E---F---G---H---N---O---P master

अब हमें मास्टर शाखा में रहते हुए git मर्ज विषय को निष्पादित करने की आवश्यकता है। हम ई को एक सामान्य पूर्वज के रूप में प्रतिबद्ध करना चुन सकते हैं, लेकिन एक पुनरावर्ती रणनीति के साथ गिट अन्यथा करते हैं। इंटरनेट पर आप एक अच्छा लेख पा सकते हैं जो इस रणनीति का पर्याप्त विवरण देता है: codicesoftware.blogspot.com/2011/09/merge-recursive-strategy.html । लेख एक एल्गोरिथ्म का वर्णन करता है जो निम्नलिखित को उबालता है:

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

इस ऑपरेशन का परिणाम एक आभासी प्रतिबद्धता होगी, जो सही क्रम में सभी आम पूर्वजों की "सन्निहित" स्थिति है - संघर्ष समाधान भी इस प्रतिबद्ध में गिर जाएगा, और अधिक हालिया प्रतिबद्धताओं में पूर्वता लेना। जब हमें एक सामान्य पूर्वज मिला, तो ऊपर वर्णित त्रिपक्षीय विलय का प्रदर्शन किया जाता है।

मर्ज- recursive.c से अंश:

 int merge_recursive(...) { <...> if (!ca) { ca = get_merge_bases(h1, h2, 1); ca = reverse_commit_list(ca); } <...> merged_common_ancestors = pop_commit(&ca); <...> for (iter = ca; iter; iter = iter->next) { <...> merge_recursive(o, merged_common_ancestors, iter->item, NULL, &merged_common_ancestors); <…> } <...> clean = merge_trees(o, h1->tree, h2->tree, merged_common_ancestors->tree, &mrtree); <...> return clean; }

निम्न स्तर की कमिट

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

git Rev-parse <revision>

यह आदेश बहुत सरल है: यह निर्दिष्ट संशोधन के लिए प्रतिबद्ध हैश लौटाता है। उदाहरण के लिए, git Rev-parse HEAD, HEAD द्वारा इंगित किए गए प्रतिबद्ध हैश लौटाएगा।

git रि-लिस्ट <प्रतिबद्ध> ...

कमांड निर्दिष्ट अनुरोध के लिए कमिट के हैश को सूचीबद्ध करता है और इसे git log तेजी से विकल्प के रूप में इस्तेमाल किया जा सकता है। उदाहरण के लिए, git rev-list branch ^origin/branch ^origin/master आउटपुट शाखा शाखा से आने वाले सभी कमिट्स का उत्पादन करेगा जो अभी तक चलाया नहीं गया है (बशर्ते कि मूल / शाखा और मूल / मास्टर ताजा हो, उदाहरण के लिए, git fetch पहले किया गया था) ।

नुकसान: शाखा ^ other_branch जैसे प्रश्नों के संबंध में, गलत परिणाम आने पर गलत तरीके से परिणाम प्रदर्शित कर सकते हैं। उदाहरण के लिए, यह बताता है कि मर्ज की तुलना में "भविष्य में हुआ" आउटपुट में छोड़ दिया जा सकता है।

git diff-index

एक काम की प्रतिलिपि और एक सूचकांक (.गित / सूचकांक) के बीच अंतर को दर्शाता है। इंडेक्स में, Git उन सभी फाइलों से कैशस्ट () कैश को स्टोर करता है, जिसके बारे में वह जानता है।

नुकसान: यदि आप फ़ाइलों को एक सर्वर से दूसरे में स्थानांतरित करते हैं (या एक फ़ोल्डर की प्रतिलिपि बनाते हैं), तो गिट डिफ-इंडेक्स बहुत सारे बदलाव दिखाएगा, हालांकि वे वास्तव में नहीं हैं। यह इस तथ्य के कारण है कि लगभग सभी lstat फ़ील्ड को। Init / index में संग्रहीत किया जाता है, जिसमें इनकोड भी शामिल है, और diff-index फ़ाइलों की सामग्री का विश्लेषण नहीं किया जाता है। इसलिए, आपको अतिरिक्त रूप से अपडेट-इंडेक्स की आवश्यकता होती है , या सामान्य गिट भिन्न का उपयोग करना चाहिए, जो यह स्वचालित रूप से करता है। .It / index के बारे में अधिक जानकारी: www.kernel.org/pub/software/scm/git/docs/v1.6.5/technical/ Govern-git.txt

git कैट-फाइल <ऑब्जेक्ट>

यह टीम पहले ही लेख में मिल चुकी है, लेकिन यह अभी भी फिर से ध्यान देने योग्य है। यह आपको कमिट और किसी अन्य Git ऑब्जेक्ट की सामग्री प्राप्त करने की अनुमति देता है।

git ls-tree <object>

ट्री ऑब्जेक्ट की सामग्री को स्वीकार्य रूप में प्रदर्शित करता है।

git ls- रिमोट <रिपोजिटरी>

निर्दिष्ट दूरस्थ भंडार से शाखाओं और टैग (प्रतिबद्ध हैश के साथ) के बारे में जानकारी सूचीबद्ध करता है।

GIT_SSH

यदि आपने स्क्रिप्ट्स लिखी हैं जो गिट पुल करती हैं , तो आप सबसे अधिक इस तथ्य का सामना कर चुके हैं कि एसएसएच दूरस्थ रिपॉजिटरी की "प्रामाणिकता" की पुष्टि करता है, और यह अंतःक्रियात्मक रूप से करता है। इस समस्या का समाधान इतना सुरुचिपूर्ण नहीं है, क्योंकि GIT_SSH निष्पादन योग्य फ़ाइल का पथ होना चाहिए (और SSH विकल्प नहीं):

 echo '#!/bin/sh exec ssh -o BatchMode=yes -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null \"\$@\"' >/tmp/gitssh; chmod +x /tmp/gitssh; #  git pull: GIT_SSH=/tmp/gitssh git pull …

निष्कर्ष

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

हमें उम्मीद है कि यह सामग्री आपके लिए दिलचस्प हो सकती है और यह समझना संभव है कि गिट इस तरह से काम करते हैं और अन्यथा नहीं। हमारा मानना है कि यह लेख Git के लिए विभिन्न इंटरफेस के डेवलपर्स के लिए भी उपयोगी होगा, जिससे "हुड के तहत" जो हो रहा है उसकी गहरी समझ हो सके।

यूरी नसरदीनोव, Badoo डेवलपर

गिट इंटर्नल्स: डेटा स्टोरेज और मर्ज