गिट-सबट्री - क्लाउड में ऑनलाइन

कार्यक्रम:

नाम

गिट-सबट्री - सबट्री को एक साथ मिलाएं और रिपॉजिटरी को सबट्री में विभाजित करें

SYNOPSIS

Git सबट्री -पी जोड़ें
Git सबट्री -पी जोड़ें
Git सबट्री खींचो -पी
Git सबट्री धक्का -पी
Git सबट्री मर्ज -पी
Git सबट्री विभाजन -पी [विकल्प] [ ]

वर्णन

उपवृक्ष उपपरियोजनाओं को मुख्य परियोजना की उपनिर्देशिका में शामिल करने की अनुमति देते हैं,
वैकल्पिक रूप से उपप्रोजेक्ट का संपूर्ण इतिहास शामिल है।

उदाहरण के लिए, आप किसी लाइब्रेरी के स्रोत कोड को अपनी उपनिर्देशिका के रूप में शामिल कर सकते हैं
आवेदन.

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

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

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

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

कमानों

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

मर्ज
तक हाल के परिवर्तनों को मर्ज करें में उपवृक्ष. सामान्य की तरह Git
मर्ज, यह आपके अपने स्थानीय परिवर्तनों को नहीं हटाता है; यह बस उन परिवर्तनों को विलीन कर देता है
नवीनतम . साथ --स्क्वाश, केवल एक कमिट बनाता है जिसमें सभी शामिल हैं
संपूर्ण इतिहास में विलीन होने के बजाय परिवर्तन।

आप उपयोग करते हैं --स्क्वाश, मर्ज की दिशा हमेशा आगे की ओर नहीं होनी चाहिए; तुम कर सकते हो
उदाहरण के लिए, v2.5 से v2.4 तक समय में पीछे जाने के लिए इस कमांड का उपयोग करें। यदि आपका विलय
एक संघर्ष का परिचय देता है, आप इसे सामान्य तरीकों से हल कर सकते हैं।

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

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

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

सफलतापूर्वक विभाजित होने के बाद, एक एकल कमिट आईडी को stdout पर प्रिंट किया जाता है। यह
नव निर्मित पेड़ के HEAD से मेल खाता है, जिसे आप हालांकि हेरफेर कर सकते हैं
आप चाहते हैं।

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

ध्यान दें कि यदि आप उपयोग करते हैं --स्क्वाश जब आप विलय करते हैं, तो आपको आमतौर पर बस नहीं होना चाहिए -- पुनः शामिल हों
जब तुम अलग हो जाओगे.

विकल्प

-क्यू, --शांत
stderr पर अनावश्यक आउटपुट संदेशों को रोकें।

-डी, --डीबग
stderr पर और भी अधिक अनावश्यक आउटपुट संदेश उत्पन्न करें।

-पी , --उपसर्ग=
रिपॉजिटरी में उस सबट्री के लिए पथ निर्दिष्ट करें जिसे आप हेरफेर करना चाहते हैं। इस विकल्प
सभी आदेशों के लिए अनिवार्य है।

-एम , --संदेश=
यह विकल्प केवल जोड़ने, मर्ज करने और खींचने (अनिश्चित) के लिए मान्य है। उल्लिखित करना के रूप में
मर्ज कमिट के लिए कमिट संदेश।

विकल्प के लिए जोड़ें, मर्ज, धकेलना, खींचने

--स्क्वाश
यह विकल्प केवल ऐड, मर्ज और पुल कमांड के लिए मान्य है।

सबट्री प्रोजेक्ट से संपूर्ण इतिहास को मर्ज करने के बजाय, केवल एक ही उत्पादन करें
प्रतिबद्ध करें जिसमें वे सभी अंतर शामिल हों जिन्हें आप मर्ज करना चाहते हैं, और फिर उस नए को मर्ज करें
अपने प्रोजेक्ट में प्रतिबद्ध हों.

इस विकल्प का उपयोग करने से लॉग अव्यवस्था को कम करने में मदद मिलती है। लोग हर बदलाव को कम ही देखना चाहते हैं
यह उनके द्वारा उपयोग की जा रही लाइब्रेरी के v1.0 और v1.1 के बीच हुआ, क्योंकि इनमें से कोई भी नहीं
अंतरिम संस्करण कभी भी उनके एप्लिकेशन में शामिल किए गए थे।

का प्रयोग --स्क्वाश जब एक ही उपप्रोजेक्ट में एकाधिक शामिल किया जाता है तो समस्याओं से बचने में भी मदद मिलती है
एक ही प्रोजेक्ट में कई बार, या हटा दिया जाता है और फिर से जोड़ा जाता है। ऐसे में ऐसा नहीं होता
वैसे भी इतिहास को संयोजित करना समझ में आता है, क्योंकि यह स्पष्ट नहीं है कि इतिहास का कौन सा हिस्सा है
इतिहास किस उपवृक्ष का है.

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

चाहे आप उपयोग करें या नहीं --स्क्वाश, आपके स्थानीय भंडार में किए गए परिवर्तन बरकरार रहेंगे
और बाद में विभाजित किया जा सकता है और उपप्रोजेक्ट को अपस्ट्रीम भेजा जा सकता है।

विकल्प के लिए विभाजित करें

--एनोटेट=
यह विकल्प केवल स्प्लिट कमांड के लिए मान्य है।

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

जब भी आप विभाजित हों, आपको उसी का उपयोग करने की आवश्यकता है , अन्यथा आपके पास नहीं है
गारंटी दें कि नया पुनः निर्मित इतिहास पुराने के समान होगा। वो होगा
विलय को सही ढंग से काम करने से रोकें। git सबट्री इसे वैसे भी काम करने का प्रयास करता है,
खासकर यदि आप --rejoin का उपयोग करते हैं, लेकिन यह हमेशा प्रभावी नहीं हो सकता है।

-बी , --शाखा=
यह विकल्प केवल स्प्लिट कमांड के लिए मान्य है।

सिंथेटिक इतिहास तैयार करने के बाद, एक नई शाखा बनाएं जिसे कहा जाता है वह
नया इतिहास समाहित है. यह तत्काल ऊपर की ओर धकेलने के लिए उपयुक्त है।
पहले से मौजूद नहीं होना चाहिए.

--अनदेखा-जोड़ें
यह विकल्प केवल स्प्लिट कमांड के लिए मान्य है।

आप उपयोग करते हैं -- पुनः शामिल हों, git सबट्री अपने इतिहास पुनर्निर्माण को अनुकूलित करने का प्रयास करता है
पिछले के बाद से केवल नए कमिट जेनरेट करें -- पुनः शामिल हों. --अनदेखा-जुड़ें इसे अक्षम करता है
व्यवहार, उसे पूरे इतिहास को पुनर्जीवित करने के लिए मजबूर करता है। एक बड़े प्रोजेक्ट में, यह हो सकता है
एक लंबा समय लगेगा।

--onto=
यह विकल्प केवल स्प्लिट कमांड के लिए मान्य है।

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

अगर आपने इस्तेमाल किया Git सबट्री जोड़ना, आपको इस विकल्प की कभी आवश्यकता नहीं होनी चाहिए।

-- पुनः शामिल हों
यह विकल्प केवल स्प्लिट कमांड के लिए मान्य है।

विभाजन के बाद, नव निर्मित सिंथेटिक इतिहास को वापस अपने मुख्य में मर्ज करें
परियोजना। इस तरह, भविष्य के विभाजन इतिहास के केवल उस हिस्से को खोज सकते हैं जो रहा है
सबसे हालिया --rejoin के बाद से जोड़ा गया।

यदि आपका स्प्लिट कमिट अंत में अपस्ट्रीम सबप्रोजेक्ट में विलय हो जाता है, और फिर आप चाहते हैं
नवीनतम अपस्ट्रीम संस्करण प्राप्त करें, इससे गिट के मर्ज एल्गोरिदम को और अधिक अनुमति मिल जाएगी
समझदारी से संघर्षों से बचें (क्योंकि यह जानता है कि ये सिंथेटिक प्रतिबद्धताएँ पहले से ही इसका हिस्सा हैं
अपस्ट्रीम रिपॉजिटरी का)।

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

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

उदाहरण 1. जोड़ें कमान

आइए मान लें कि आपके पास एक स्थानीय रिपॉजिटरी है जिसमें आप एक बाहरी रिपॉजिटरी जोड़ना चाहेंगे
विक्रेता पुस्तकालय को. इस मामले में हम git-subtree रिपॉजिटरी को उपनिर्देशिका के रूप में जोड़ेंगे
आपके पहले से मौजूद गिट-एक्सटेंशन रिपॉजिटरी में ~/गिट-एक्सटेंशन/:

$ git सबट्री जोड़ें --prefix=git-subtree --squash \
git://github.com/apenwarr/git-subtree.git मास्टर

मास्टर एक वैध रिमोट रेफरी होना आवश्यक है और यह एक अलग शाखा का नाम हो सकता है

आप --स्क्वैश ध्वज को हटा सकते हैं, लेकिन ऐसा करने से प्रतिबद्धताओं की संख्या बढ़ जाएगी
आपके स्थानीय भंडार में शामिल है।

अब हमारे पास एक ~/गिट-एक्सटेंशन/गिट-सबट्री मास्टर से कोड युक्त निर्देशिका
हमारे git-एक्सटेंशन रिपॉजिटरी में git://github.com/apenwarr/git-subtree.git की शाखा।

उदाहरण 2. EXTRACT A सबट्री का उपयोग करते हुए प्रतिबद्ध, मर्ज और खींचने

आइए एक उदाहरण के रूप में गिट स्रोत कोड के लिए रिपॉजिटरी का उपयोग करें। सबसे पहले, अपनी स्वयं की प्रति प्राप्त करें
git.git रिपॉजिटरी का:

$ git क्लोन git://git.kernel.org/pub/scm/git/git.git test-git
$ सीडी टेस्ट-गिट

gitweb (कमिट 1130ef3) को कमिट 0a8f4f0 के रूप में git में विलय कर दिया गया था, जिसके बाद यह नहीं था
लंबे समय तक अलग रखा जाता है। लेकिन कल्पना कीजिए कि इसे अलग से बनाए रखा गया था, और हम चाहते थे
उस समय से गिटवेब में गिट के परिवर्तनों को निकालने के लिए, अपस्ट्रीम के साथ साझा करने के लिए। आप ऐसा कर सकते हैं
यह करो:

$ git सबट्री स्प्लिट --prefix=gitweb --annotate='(स्प्लिट) ' \
0a8f4f0^.. --onto=1130ef3 --पुनः जुड़ें \
--ब्रांच गिटवेब-नवीनतम
$ gitk gitweb-नवीनतम
$ गिट पुश [ईमेल संरक्षित]:whatever/gitweb.git gitweb-latest:मास्टर

(हम उपयोग करते हैं 0a8f4f0^.. क्योंकि इसका मतलब है "0a8f4f0 से वर्तमान तक सभी परिवर्तन
संस्करण, जिसमें 0a8f4f0 भी शामिल है।")

यदि गिटवेब को मूल रूप से उपयोग करके मर्ज किया गया था Git सबट्री जोड़ना (या पिछला विभाजन हुआ था
--rejoin निर्दिष्ट के साथ पहले ही किया जा चुका है) तो आप अपने सभी विभाजन इसके बिना कर सकते हैं
किसी भी अजीब प्रतिबद्ध आईडी को याद रखने के लिए:

$ git सबट्री स्प्लिट --prefix=gitweb --annotate='(split) ' --rejoin \
--ब्रांच gitweb-latest2

और आप अपस्ट्रीम प्रोजेक्ट से परिवर्तनों को उतनी ही आसानी से मर्ज कर सकते हैं:

$ git सबट्री पुल --prefix=gitweb \
[ईमेल संरक्षित]:whatever/gitweb.git मास्टर

या, उपयोग कर रहे हैं --स्क्वाश, आप वास्तव में gitweb के पुराने संस्करण को रिवाइंड कर सकते हैं:

$ गिट सबट्री मर्ज --उपसर्ग=गिटवेब --स्क्वैश गिटवेब-नवीनतम~10

फिर कुछ बदलाव करें:

$ दिनांक >gitweb/myfile
$ git, gitweb/myfile जोड़ें
$ git कमिट -m 'मेरीफ़ाइल बनाई गई'

और फिर तेजी से आगे बढ़ें:

$ गिट सबट्री मर्ज --उपसर्ग=गिटवेब --स्क्वैश गिटवेब-नवीनतम

और ध्यान दें कि आपका परिवर्तन अभी भी बरकरार है:

$ ls -l gitweb/myfile

और आप इसे विभाजित कर सकते हैं और मानक गिटवेब बनाम अपने परिवर्तनों को देख सकते हैं:

git लॉग gitweb-latest..$(git सबट्री स्प्लिट --prefix=gitweb)

उदाहरण 3. EXTRACT A सबट्री का उपयोग करते हुए शाखा

मान लीजिए कि आपके पास कई फ़ाइलों और उपनिर्देशिकाओं के साथ एक स्रोत निर्देशिका है, और आप ऐसा करना चाहते हैं
lib निर्देशिका को अपने स्वयं के git प्रोजेक्ट में निकालें। इसे करने का एक छोटा तरीका यहां दिया गया है:

सबसे पहले, आप जहां चाहें नई रिपॉजिटरी बनाएं:

$
$ git init --bare

अपनी मूल निर्देशिका में वापस जाएँ:

$ git सबट्री स्प्लिट --prefix=lib --annotate='(स्प्लिट)' -बी स्प्लिट

फिर नई शाखा को नए खाली भंडार पर धकेलें:

$ गिट पुश विभाजन: मास्टर

onworks.net सेवाओं का उपयोग करके ऑनलाइन git-subtree का उपयोग करें