🛄 👘 👩🏻‍🎤 कैसे और क्यों पेड़ों को चोरी करने के लिए 👨🏿‍🏭 👤 🚣🏽

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

सामग्री

सैद्धांतिक भाग। कमिट्स और पेड़ों के बारे में
कमिट-ट्री
व्यावहारिक भाग
1. एक अन्य शाखा के साथ सिंक्रनाइज़ेशन
2. दो शाखाओं की तुलना
3. शाखा उलट
4. आंशिक उल्टा
5. कृत्रिम मर्ज
6a। मर्ज के माध्यम से रिबेस विधि - विवरण
6b। मर्ज - स्क्रिप्ट के माध्यम से रीबेस विधि
7. उपनाम
निष्कर्ष

सैद्धांतिक भाग। कमिट्स और पेड़ों के बारे में

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

git cat-file -p 5e45ecb

 tree 8640790949c12690fc71f9abadd7b57ec0539376 parent 930741d1f5fd2a78258aa1999bb4be897ba3d015 author Mark Tareshawty <tareby...@github.com> 1542718283 -0500 committer Mark Tareshawty <tareby...@github.com> 1542718283 -0500 gpgsig -----BEGIN PGP SIGNATURE----- ... -----END PGP SIGNATURE----- Fix scoping so that we don't break the naming convention

ये कुछ पंक्तियाँ प्रतिबद्ध की संपूर्ण सामग्री हैं:

पेड़ - एक विशिष्ट परियोजना राज्य के लिए एक कड़ी
जनक - माता-पिता की प्रतिबद्धता के लिए लिंक
लेखक - मूल प्रतिबद्ध + तारीख के लेखक
कमिट - इस प्रतिबद्ध + तारीख के निर्माता
gpgsig - डिजिटल हस्ताक्षर (यदि उपलब्ध हो)
संदेश - प्रतिबद्ध पाठ

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

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

पेड़ की सामग्री देखें

यह किसी अन्य वस्तु (कमिट / ट्री / ब्लॉब) के लिए ठीक उसी तरह से किया जा सकता है, और यह पहले कुछ अद्वितीय हैश वर्णों को लेने के लिए पर्याप्त है: 8640790949c12690fc71f9abadd7b57ec539376 -> 8640790।

 git cat-file -p 8640790

 100644 blob 7ab08294a46f158c51460be3e7df6a190e15023b .env.example 100644 blob 0a1a4d1ad9ff3f35b67678ca893811e91b423af5 .gemset 040000 tree 033aa38ce0eab11fe229067c14ccce95e2b8b601 .github 100644 blob ca49bb7ffa6273b0be4ce7ba1accba456032fb11 .gitignore 100644 blob c99d2e7396e14ac072c63ec8419d9b8fede28d86 .rspec 100644 blob 65e77a2f59f635a8f24eb4714e8e43745c5c0eb9 .rubocop.yml 100644 blob 8e8299dcc068356889b365e23c948b92c6dfcd78 .ruby-version 100644 blob 19028f9885948aca2ba61f9d062e9dc21c21ad03 .stylelintrc.json 100644 blob 2f7a032fbc3f4f7195bfd91cb33889a684b572b9 .travis.yml 100644 blob 121615722a6c206a9fe24b9a1c9b647662a460d2 ARCHITECTURE.md 100644 blob 898195daeea0bbf8c5930deeaf1020ba8abab34a Gemfile 100644 blob de7ca707f9fe9172db941b65cdacaba7e024fc06 Gemfile.lock 100644 blob e6ff62fefd071b1a8ca279bae94ddbc4dd17b7a3 Gruntfile.js 100644 blob 0cac5b30fb32d36cce2aeb7d936be7b6207d68c7 MIT-LICENSE.txt 100644 blob c2c566e8cc3d440d3ee8041b79cded416db28136 Procfile 100644 blob d1fb2f575380e1e093a4d82e3f19e51f0b99a0a1 Procfile.dev 100644 blob 3a88e138f10fa65bd2cfe1a1d3292348205508b5 README.md 100644 blob 5366e6e073cc426518894cc379d3a07cf3c9cfb3 Rakefile 100644 blob e6d3d2d3e9d5122c5f75bbeee8ed0917ad38c131 app.json 040000 tree 94f83cf03bd6f1cf14672034877b14604744b7a2 app 040000 tree d4d859e82564250b4c4f2047de21e089e7555475 bin 100644 blob 1f71007621f17334fd6f2dd71c87b7a16867119c config.ru 040000 tree 9e8e4bf5ec44541aefff544672b94ca8a9d07bbf config 040000 tree 31b8d0e1fa2bb789dbd6319e04fc9f115952cf2a db 040000 tree 38e7a13e0e772c2a13e46d2007e239f679045bee doc 040000 tree a6e35ded8b35837660cf786e637912377f845515 lib 040000 tree d564d0bc3dd917926892c55e3706cc116d5b165e log 100644 blob 843523565ddee5e00f580d9c4e37fc2478fdaecc package-lock.json 100644 blob 791ee833ad316d75b1d2c83a64a3053fc952d254 package.json 040000 tree 4645317c52675d9889f89b26f4dd4d2ae1d8cbad public 040000 tree 31d3f8ae4a4ffe62787134642743ed32a35dbae2 resources 040000 tree 807ffa29868ef9c25ddb4b4126a4bb7f1b041bf0 script 040000 tree 4c3bf9a7f3679ba059b0f1c214a500d197546462 spec 040000 tree 136c8174412345531a9542cafef25ce558d2664f test 040000 tree e6524eafe066819e4181bc56c503320548d8009b vendor

यह वास्तव में सबसे महत्वपूर्ण विशेषता है कि गिट कैसे काम करता है, प्रतिबद्ध पहचानकर्ता वास्तव में इसकी सामग्री का एक हैश है। ठीक उसी तरह जैसे उसमें (पेड़, बूँद) में अंकित वस्तुओं का हैश।

अब देखते हैं कि हम क्या करते हैं

 git commit -m "Fixed bug"

यह कमांड एक नई प्रतिबद्ध बनाता है जो निम्नलिखित को कैप्चर करता है:

स्टेजिंग प्रोजेक्ट की स्थिति (एक नई ट्री ऑब्जेक्ट और इसके हैश के रूप में सहेजी गई)
वर्तमान (मूल) प्रतिबद्ध के लिए लिंक
लेखक + कमिट + दो तारीखें
पाठ करें

यह सभी सहेजे गए, हैशेड और एक नई प्रतिबद्ध वस्तु प्राप्त की है। और टीम स्वचालित रूप से वर्तमान शाखा सूचक को उठाती है।

शब्दावली के बारे में थोड़ा सा

जैसा कि हम पहले से ही जानते हैं, पेड़ एक ऐसी वस्तु है जिसमें अतीत में एक निश्चित बिंदु पर परियोजना की स्थिति शामिल होती है - जब इस पेड़ के साथ एक प्रतिबद्ध बनाया गया था।

वर्किंग फोल्डर को वर्किंग ट्री / वर्किंग कॉपी / वर्किंग डायरेक्टरी कहा जाता है, जो काफी तार्किक है।

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

कमिट-ट्री

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

उसकी चुनौती को देखो

 git commit-tree 4c835c2 -m "Fixed bug" -p a8fc5e3

 d9aded78bf57ca906322e26883644f5f36cfdca5

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

व्यावहारिक भाग

इस आदेश का उपयोग करने के उदाहरणों को निम्नलिखित सरल भंडार में प्रदर्शित किया जाता है।

इसकी तीन शाखाएँ हैं:

मास्टर - मुख्य शाखा
अल्फा - वह शाखा जिस पर हम काम करते हैं और करते हैं
बीटा - एक शाखा जो पहले मास्टर में रोक दी गई थी

सभी क्रियाएं स्थानीय रूप से दोहराना आसान हैं, इसके लिए यह रिपॉजिटरी को क्लोन करने के लिए पर्याप्त है, अल्फा शाखा पर प्राप्त करें और फिर उदाहरणों से कमांड निष्पादित करें। यह प्रारंभिक अवस्था सभी उदाहरणों के लिए सामान्य है।

 git clone https://github.com/capslocky/git-commit-tree-example.git cd ./git-commit-tree-example/ git checkout alpha

खिड़कियों के नीचे

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

 "C:\Program Files\Git\git-bash.exe" --cd="D:\path\project"

1. एक अन्य शाखा के साथ सिंक्रनाइज़ेशन

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

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

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

सबसे पहले, बीटा शाखा द्वारा इंगित की गई हैश का पता लगाएं:

 git rev-parse origin/beta

 280c30ff81a574f8dd41721726cf60b22fb2eced

280c30f - बस पहले कुछ अक्षर लें

अब git कैट-फाइल के माध्यम से कमिट की सामग्री प्रदर्शित करके इसके पेड़ का हैश खोजें:

 git cat-file -p 280c30f

 tree 3c1afe75f54518dbd82ea7a4e3c4ff50389a573a <--- parent 560b449675513bc8f8f4d6cda56a922d4e36917a author Baur <atanov...@gmail.com> 1540619512 +0600 committer Baur <atanov...@gmail.com> 1540619512 +0600 Added info about windows

3 सी 1 कैफे 7 - यह वह पेड़ है जिसकी हमें ज़रूरत है

और अब हम इस पेड़ की ओर इशारा करते हुए एक कमिट बनाएंगे, और माता-पिता की ओर से हम वर्तमान कमिट को इंगित करेंगे:

 git commit-tree 3c1afe7 -m "Synced with branch 'beta'" -p HEAD

 eb804d403d4ec0dbeee36aa09da706052a7cc687

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

 git cat-file -p xxxxxxx

 tree 3c1afe75f54518dbd82ea7a4e3c4ff50389a573a <--- parent 64fafc79e8f6d22f5226490daa5023062299fd6c author Peter <peter...@gmail.com> 1545230299 +0600 committer Peter <peter...@gmail.com> 1545230299 +0600 Synced with branch 'beta'

महान, यह मूल / बीटा शाखा पर प्रतिबद्ध के रूप में एक ही पेड़ है। और चूंकि यह प्रतिबद्ध वर्तमान शाखा का प्रत्यक्ष वंशज है, इसलिए इसे शाखा में शामिल करने के लिए, बस फास्ट-फॉरवर्ड मर्ज करें

 git merge --ff xxxxxxx

 Updating 64fafc7..xxxxxxx Fast-forward Azure.txt | 3 --- Bill.txt | 6 +----- Linus.txt | 15 +++++++++++++++ 3 files changed, 16 insertions(+), 8 deletions(-)

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

2. दो शाखाओं की तुलना

उद्देश्य:
बीटा शाखा के साथ अल्फा शाखा की तुलना करें।

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

तो, पहले, अल्फा शाखा को उसकी मूल स्थिति में लौटाएं

 git reset --hard origin/alpha

चलो वर्तमान पर एक अस्थायी शाखा बनाएं और उस पर खड़े हों

 git checkout -b temp

और हम पिछले उदाहरण के समान ही करने के लिए शेष हैं। लेकिन इस बार हम एक पंक्ति में मिलेंगे। ऐसा करने के लिए, हम प्रतिबद्ध ट्री मूल / बीटा ^ {ट्री} या उसी 280c30f ^ / ट्री} तक पहुंचने के लिए विशेष सिंटैक्स का उपयोग करते हैं।

 git merge --ff $(git commit-tree origin/beta^{tree} -m "Diff with branch 'beta'" -p HEAD)

हो गया, अनिवार्य रूप से हम दो शाखाओं के बीच एक प्रतिबद्ध अंतर के रूप में भौतिक थे

 git show

 git diff alpha origin/beta

बेशक, हम रिपॉजिटरी में किन्हीं दो कमिट्स (स्टेट्स) के लिए ऐसी "तुलनात्मक" कमिटमेंट बना सकते हैं।

3. शाखा उलट

उद्देश्य:
पिछले कुछ हिट रोल।

चलो अल्फा शाखा पर वापस जाते हैं और अस्थायी शाखा हटाते हैं

 git checkout alpha git branch -D temp

मान लीजिए कि हमें अल्फा ब्रांच पर अंतिम दो कमिट्स को रोल करने की आवश्यकता है। ऐसा करने के दो क्लासिक तरीके हैं:

रन जीट दो बार - प्रति कमिट
git रीसेट, यानी शाखा स्थिति रीसेट करें

लेकिन आप इसे तीसरे तरीके से कर सकते हैं:

 git merge --ff $(git commit-tree 7a714bf^{tree} -m "Reverted to commit 7a714bf" -p HEAD)

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

इसके अलावा, यदि आपको शाखा की मूल स्थिति वापस करने की आवश्यकता है, तो यह उसी तरह से किया जा सकता है

 git merge --ff $(git commit-tree 64fafc7^{tree} -m "Reverted back to commit 64fafc7" -p HEAD)

एक ही समय में, ये दो आवागमन शाखा के इतिहास में बने रहेंगे, जिसके अनुसार यह देखा जाएगा कि यह लुढ़का हुआ था और वापस लौटा।

4. आंशिक उल्टा

उद्देश्य:
पिछले कुछ कमिट्स में कुछ फ़ाइलों में परिवर्तन वापस करें।

फिर से, अल्फा शाखा को उसकी मूल स्थिति में लौटाएं

 git reset --hard origin/alpha

अल्फा ब्रांच में 3 कमिट होते हैं, जिनमें से प्रत्येक में बिल टू टेक्स्ट फ़ाइल में बदलाव किए जाते हैं, अंतिम प्रतिबद्ध में, Azure.txt फ़ाइल भी जोड़ी जाती है। मान लीजिए कि हमें बिल टू में पिछले 2 कमिट्स के लिए बिल को वापस लाने की जरूरत है, बिना किसी दूसरी फाइल को टच किए।

सबसे पहले, सभी फ़ाइलों को वापस रोल करें 2 वापस आते हैं

 git merge --ff $(git commit-tree 7a714bf^{tree} -m "any text" -p HEAD)

अगला, शाखा को पिछली प्रतिबद्ध पर लौटाएं, लेकिन डिस्क पर प्रोजेक्ट की स्थिति को छूने के बिना

 git reset HEAD~1

और अब यह आवश्यक फ़ाइलों और प्रतिबद्ध zasteydit करने के लिए पर्याप्त है, और अन्य परिवर्तनों को त्याग दिया जा सकता है।

 git add Bill.txt git commit -m "Reverted file Bill.txt to 7a714bf" git reset --hard HEAD

5. कृत्रिम मर्ज

उद्देश्य:
पूर्व निर्धारित परिणाम प्राप्त करते हुए, एक शाखा को दूसरे में बदलें।

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

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

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

 git cat-file -p 7229df8

 tree 3c1afe75f54518dbd82ea7a4e3c4ff50389a573a parent fd54ab7dde87593b9892b6d1ffbf1afd39ba6f9e parent 280c30ff81a574f8dd41721726cf60b22fb2eced author Baur <atanov...@gmail.com> 1540619579 +0600 committer Baur <atanov...@gmail.com> 1540619592 +0600 Merge branch 'beta' into 'master'

वर्तमान अल्फा शाखा को रीसेट करें और मास्टर पर जाएं

 git reset --hard origin/alpha git checkout master

और अब एक ही टीम है, लेकिन दो माता-पिता के साथ है

 git merge --ff $(git commit-tree alpha^{tree} -m "Merge 'alpha' into 'master', but take 'alpha' tree" -p HEAD -p alpha)

हो गया, हमने मास्टर में अल्फा शाखा का मंचन किया, और हमें अस्थायी कोड को हटाने और विरोध को हल करने की आवश्यकता नहीं थी, क्योंकि इस मामले में हमें बस नवीनतम परिवर्तनों को फिर से लिखना पड़ा।

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

स्पॉइलर

आइए ध्यान दें कि कैसे बीटा शाखा को मास्टर में वापस गला दिया गया था। उस समय के दौरान जब इसमें दो कमिट दिखाई दिए, मास्टर शाखा में ही कोई नया कमिट नहीं था। इसका मतलब यह है कि मास्टर में मर्ज बीटा के साथ, किसी भी संघर्ष को एक साथ परिवर्तन के कारण बाहर रखा गया है।

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

लेकिन यहाँ git मर्ज बीटा --no-ff कमांड का उपयोग करते हुए नो-फास्ट-फॉरवर्ड मर्ज किया गया था। यही है, हमने मर्ज कमिट के निर्माण को मजबूर किया, हालांकि यह आवश्यक नहीं था। और चूंकि भविष्य के विलय के लिए परियोजना की वांछित अंतिम स्थिति ज्ञात थी - यह एक बीटा ट्री है, जीआईटी ने इस पेड़ की लिंक को एक नई प्रतिबद्ध में कॉपी किया:

 git cat-file -p origin/beta

 tree 3c1afe75f54518dbd82ea7a4e3c4ff50389a573a <--- parent 560b449675513bc8f8f4d6cda56a922d4e36917a author Baur <atanov...@gmail.com> 1540619512 +0600 committer Baur <atanov...@gmail.com> 1540619512 +0600 Added info about windows

 git cat-file -p 7229df8

 tree 3c1afe75f54518dbd82ea7a4e3c4ff50389a573a <--- parent fd54ab7dde87593b9892b6d1ffbf1afd39ba6f9e parent 280c30ff81a574f8dd41721726cf60b22fb2eced author Baur <atanov...@gmail.com> 1540619579 +0600 committer Baur <atanov...@gmail.com> 1540619592 +0600 Merge branch 'beta' into 'master'

6a। मर्ज के माध्यम से रिबेस विधि - विवरण

उद्देश्य:
यह एक "भारी" रिबास शाखा बनाने के लिए आवश्यक है (विभिन्न कमिटों पर कई संघर्ष)।

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

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

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

यदि आप यह सुनिश्चित करना चाहते हैं, तो मैं स्पॉइलर के तहत तैयार टीमों की पेशकश करता हूं।

छिपा हुआ पाठ

शाखाओं को उनकी मूल स्थिति में लौटाएं

 git checkout master git reset --hard origin/master git checkout alpha git reset --hard origin/alpha

बनाएँ और अल्फा-रिबेस-संघर्ष की शाखा पर खड़े हों और मास्टर पर रीबेज़ करें

 git checkout -b alpha-rebase-conflicts git rebase master

एक प्रेत संघर्ष सहित विभिन्न कमिटों में संघर्ष होगा।

अब आइए मर्ज का प्रयास करें, अल्फा शाखा पर वापस जाएं और रिबास के लिए शाखा को हटा दें।

 git checkout alpha git branch -D alpha-rebase-conflicts

मास्टर पर जाएँ और मर्ज करें

 git checkout master git merge alpha

केवल एक साधारण संघर्ष होगा, हम इसे सही करते हैं और करते हैं

 git add Bill.txt git commit -m "Merge branch 'alpha' into 'master'"

मर्ज सफलतापूर्वक पूरा हुआ।

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

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

चलिए शुरू करते हैं। फिर से, दोनों शाखाओं को उनकी मूल स्थिति में लौटाएँ।

 git checkout master git reset --hard origin/master git checkout alpha git reset --hard origin/alpha

आइए एक अस्थायी शाखा अस्थायी बनाएं जिसमें हम विलय करेंगे।

 git checkout -b temp git merge origin/master

संघर्ष।

आइए हमेशा की तरह (किसी भी संपादक में) बिलटेक्स फ़ाइल में एक साधारण संघर्ष को हल करें।
ध्यान दें कि केवल एक ही संघर्ष है, और दो नहीं, जैसा कि रिबेस के साथ है।

 git add Bill.txt git commit -m "Merge branch 'origin/master' into 'temp'"

हम अल्फा शाखा में लौटते हैं, हमारे पक्ष में सभी संघर्षों के स्वत: समाधान के साथ एक रिबेस करते हैं, और अस्थायी शाखा को राज्य में लाते हैं, और स्वयं अस्थायी शाखा को हटाते हैं।

 git checkout alpha git rebase origin/master -X theirs git merge --ff $(git commit-tree temp^{tree} -m "Fix after rebase" -p HEAD) git branch -D temp

अंत में, मास्टर में खूबसूरती से मर्जिम अल्फा।

 git checkout master git merge alpha --no-ff --no-edit

ध्यान दें कि मास्टर, अल्फा और रिमोट टेम्प शाखा तीनों एक ही पेड़ की ओर इशारा करते हैं, हालांकि ये तीन अलग-अलग तरीके हैं।

इस विधि का विपक्ष:

प्रत्येक संघर्ष प्रतिबद्ध का कोई मैनुअल सुधार नहीं होता है - संघर्ष स्वचालित रूप से हल हो जाते हैं। इस तरह के एक मध्यवर्ती प्रतिबद्ध नहीं हो सकता है।
हर छूट पर अतिरिक्त (हमेशा नहीं) जोड़ा गया

पेशेवरों:

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

6b। मर्ज - स्क्रिप्ट के माध्यम से रीबेस विधि

स्क्रिप्ट यहां प्रकाशित की गई है: https://github.com/capslocky/git-rebase-via-merge

आइए इसके काम को हमारे उदाहरण पर देखें। फिर से, दोनों शाखाओं को उनकी मूल स्थिति में लौटाएँ

 git checkout master git reset --hard origin/master git checkout alpha git reset --hard origin/alpha

स्क्रिप्ट डाउनलोड करें और इसे निष्पादन योग्य बनाएं

 curl -L https://git.io/rebase-via-merge -o ~/git-rebase-via-merge.sh chmod +x ~/git-rebase-via-merge.sh

खिड़कियां

फ़ाइल यहाँ दिखाई देगी: C: \ Users \ user-name \ git-rebase-via-merge.sh

उस डिफ़ॉल्ट शाखा को बदलें जिसके लिए आपको रिबास करने की आवश्यकता है, हमारे मामले में हमें मूल / मास्टर की आवश्यकता है

 nano ~/git-rebase-via-merge.sh

 default_base_branch='origin/master'

चलिए एक अस्थायी शाखा भी बनाते हैं और खड़े होते हैं ताकि अल्फा शाखा को स्पर्श न किया जा सके

 git checkout -b alpha-rebase-test

और अब आप स्क्रिप्ट को चला सकते हैं (पारंपरिक गिट रीबेस मूल / मास्टर के बजाय)

 ~/git-rebase-via-merge.sh

स्क्रिप्ट परिणाम

 $ ~/git-rebase-via-merge.sh This script will perform rebase via merge. Current branch: alpha-rebase-test (64fafc7) Base branch: origin/master (9c6b60a) Continue (c) / Abort (a) c Auto-merging Bill.txt CONFLICT (content): Merge conflict in Bill.txt Automatic merge failed; fix conflicts and then commit the result. You have at least one merge conflict. Fix all conflicts in the following files, stage them up and type 'c': Bill.txt Continue (c) / Abort (a) c [detached HEAD 785d49e] Hidden temp commit to save result of merging 'origin/master' into 'alpha-rebase-test' as detached head. Merge succeeded on hidden commit: 785d49e Starting rebase automatically resolving any conflicts in favor of current branch. First, rewinding head to replay your work on top of it... Auto-merging Bill.txt [detached HEAD a680316] Added history of windows Author: Baur <atanov...@gmail.com> Date: Sat Oct 27 11:45:50 2018 +0600 1 file changed, 6 insertions(+), 3 deletions(-) Committed: 0001 Added history of windows Auto-merging Bill.txt [detached HEAD dcd34a8] Replaced history of windows Author: Baur <atanov...@gmail.com> Date: Sat Oct 27 11:55:42 2018 +0600 1 file changed, 4 insertions(+), 5 deletions(-) Committed: 0002 Replaced history of windows Auto-merging Bill.txt [detached HEAD 8d6d82c] Added file about Azure and info about Windows 10 Author: Baur <atanov...@gmail.com> Date: Sat Oct 27 12:06:27 2018 +0600 2 files changed, 5 insertions(+), 3 deletions(-) create mode 100644 Azure.txt Committed: 0003 Added file about Azure and info about Windows 10 All done. Restoring project state from hidden merge with single additional commit. Updating 8d6d82c..268b320 Fast-forward Bill.txt | 4 ++++ 1 file changed, 4 insertions(+) Done.

 ~/git-rebase-via-merge.sh origin/develop

, ours / theirs :

ours — (HEAD)
theirs — (, origin/develop)

rebase — .

7.

git .

 git config alias.copy '!git merge --ff $(git commit-tree ${1}^{tree} -p HEAD -m "Tree copy from ${1}")'

git copy xxx, xxx — .

 git copy xxx

 git merge --ff $(git commit-tree xxx^{tree} -p HEAD -m "Tree copy from xxx")

 git copy a8fc5e3

 git copy origin/beta

 git copy HEAD~3

git amend.

 git commit --amend -m "Just for test"

 git commit --amend

, , . , . — . , , . . " " " " . ( , devops), , .

कैसे और क्यों पेड़ों को चोरी करने के लिए