मैं कुछ कार्यों को हल करने के लिए व्यंजनों को साझा करना चाहता हूं जो कभी-कभी गिट के साथ काम करते समय उत्पन्न होते हैं, और जो "सीधे तौर पर बिल्कुल स्पष्ट नहीं हैं।"

पहले तो मैंने इस तरह के और व्यंजनों को संचित करने का सोचा, लेकिन हर चीज का अपना समय होता है। मुझे लगता है कि अगर कोई लाभ होता है, तो यह संभव है और थोड़ा-थोड़ा करके ...

इसलिए ...

कम से कम दर्द के साथ पुरानी शाखाओं को मिलाएं

प्रस्तावना। एक मुख्य शाखा ( master ) है, जो नई सुविधाओं और सुधारों को सक्रिय रूप से लागू करती है; एक समानांतर feature शाखा है, जिसमें डेवलपर्स अपने निर्वाण में थोड़ी देर के लिए रवाना हुए, और फिर अचानक पता चला कि वे अब एक महीने के लिए मास्टर के साथ नहीं थे, और "माथे पर" (सिर से सिर) विलय पहले से ही nontrivial था।

(हां, यह एक आदर्श दुनिया के बारे में नहीं है जहां सब कुछ सही है, अपराध अनुपस्थित है, बच्चे हमेशा आज्ञाकारी होते हैं और यहां तक कि अपनी मां के साथ हाथ से सख्ती से सड़क पार करते हैं, ध्यान से चारों ओर देख रहे हैं)।

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

कथानक। तथ्य यह है कि गिट में आप कुंजी के साथ अंतिम प्रतिबद्ध को संपादित कर सकते हैं - --amend जानते हैं। चाल यह है कि यह "अंतिम प्रतिबद्ध" कहीं भी स्थित हो सकता है और इसमें कुछ भी हो सकता है। उदाहरण के लिए, यह केवल "रैखिक शाखा के लिए अंतिम प्रतिबद्ध" नहीं हो सकता है, जहां वे टाइपो को ठीक करना भूल गए, लेकिन सामान्य या "ऑक्टोपस" मर्ज से भी प्रतिबद्ध हैं। --amend सिर्फ प्रस्तावित परिवर्तनों पर रोल --amend और पेड़ में परिवर्तित --amend "एम्बेड" करेगा, जैसे कि यह वास्तव में ईमानदार विलय और संघर्षों के समाधान के परिणामस्वरूप दिखाई दिया था। संक्षेप में, git merge और git commit --amend " git commit --amend प्लेस" ("ट्री में यह git commit --amend यहां होगा") और कमिट की सामग्री को पूरी तरह से अलग करने की अनुमति देता है।

एक स्वच्छ इतिहास के साथ एक जटिल मर्ज कमिट का मूल विचार सरल है: पहले हम एक "एक जगह बनाते हैं" एक स्वच्छ मर्ज कमिट (सामग्री की परवाह किए बिना) बनाकर, फिर हम इसे --amend साथ फिर से --amend , जिससे सामग्री "सही" बन जाती है।

"एक जगह गोली मारो।" यह एक विलय की रणनीति निर्धारित करके करना आसान है जो संघर्ष समाधान के बारे में अनावश्यक प्रश्न नहीं पूछेगा।
```
 git checkout feature git merge master -s ours 
```
अरे हाँ। विलय से पहले यह आवश्यक था कि फीचर हेड से "बैकअप" शाखा बनाई जाए। सब के बाद, कुछ भी वास्तव में विलय नहीं हुआ है ... लेकिन इसे 2 वें पैराग्राफ होने दें, न कि 0 वें। सामान्य तौर पर, हम गैर-मर्ज किए गए फ़ीचर पर स्विच करते हैं, और अब ईमानदारी से मर्ज करते हैं। किसी भी तरह से संभव है, किसी भी "गंदे हैक के बावजूद।" मेरा व्यक्तिगत तरीका आखिरी विलय के क्षण से मास्टर शाखा को देखना है और संभावित समस्या का मूल्यांकन करता है (उदाहरण के लिए: एक जगह में एक टाइपो को सही करना - एक समस्या नहीं है। बड़े पैमाने पर (कई फाइलें) उन्होंने एक इकाई का नाम बदल दिया - एक समस्या एक, आदि)। समस्या से हम नई शाखाएँ बनाते हैं (मैं सरलता से करता हूं - मास्टर 1, मास्टर 2, मास्टर 3, आदि)। और फिर हम शाखा द्वारा शाखा का विलय करते हैं, पुराने से ताजा और सही संघर्षों की ओर बढ़ते हैं (जो आमतौर पर इस दृष्टिकोण के साथ स्व-स्पष्ट होते हैं)। अन्य तरीकों का सुझाव दें (मैं एक जादूगर नहीं हूं; मैं सिर्फ सीख रहा हूं; मुझे रचनात्मक टिप्पणियों पर खुशी होगी!)। अंत में, खर्च (हो सकता है) विशुद्ध रूप से नियमित संचालन पर कुछ घंटे (जो कनिष्ठ को सौंपा जा सकता है, क्योंकि इस दृष्टिकोण के साथ कोई जटिल संघर्ष नहीं है), हमें कोड की अंतिम स्थिति मिलती है: विज़ार्ड के सभी नवाचारों / फिक्स को सफलतापूर्वक सुविधा शाखा में पोर्ट किया गया था, सभी प्रासंगिक परीक्षण इस कोड पर चला गया, आदि। एक सफल कोड होना चाहिए।
"सफलता की कहानी" को फिर से लिखना। प्रतिबद्ध होने के नाते, जहां "सब कुछ किया जाता है", निम्नलिखित चलाएं:

 git tag mp git checkout mp git reset feature git checkout feature git tag -d mp

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

अंत में, जब सब कुछ तैयार हो जाता है, हम अपनी सही प्रतिबद्धता को आरक्षित स्थान में दर्ज करते हैं:

 git commit --amend

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

अपडेट: अधिक संक्षिप्त तरीका

इस प्रकाशन के तीन महीने बाद, लेख " कैपिटल के द्वारा पेड़ों को कैसे और क्यों चुराना है "

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

हम किसी भी उपलब्ध तरीकों का उपयोग करके विलय के साथ तुरंत शुरू करते हैं (जैसा कि ऊपर पैरा 2 में है)। जुए की मध्यवर्ती कहानी और हैक अभी भी अप्रासंगिक हैं। और फिर, क्लेम 3 के बजाय, मर्ज कमिट के प्रतिस्थापन के साथ, हम आर्टिफिशियल मर्ज बनाते हैं, जैसा कि लेख में है:

 git tag mp git checkout feature git merge --ff $(git commit-tree mp^{tree} -m "merged branch 'master' into 'feature'" -p feature -p master) git tag -d mp

यहां सभी जादू एक चरण में तीसरे आदेश (गिट कम-ट्री) द्वारा किया जाता है।

इतिहास को ध्यान में रखते हुए फ़ाइल का हिस्सा चुनें

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

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

कथानक। कुछ कष्टप्रद बढ़त प्रभावों के साथ, यह किया जा सकता है। निश्चितता के लिए, एक file.txt फ़ाइल है, जिसमें से मैं file2.txt में एक भाग को हाइलाइट करना चाहता file2.txt । (और अभी भी कहानी रखते हैं, हाँ)। इस स्निपेट को चलाएं:

 f=file.txt; f1=file1.txt; f2=file2.txt cp $f $f2 git add $f2 git mv $f $f1 git commit -m"split $f step 1, converted to $f1 and $f2"

नतीजतन, हम फाइल को प्राप्त करते हैं file1.txt और file2.txt । वे दोनों बिल्कुल एक ही कहानी है (असली; मूल फ़ाइल की तरह)। हां, मूल file.txt का नाम file.txt पड़ा; यह "थोड़ा कष्टप्रद" बढ़त प्रभाव है। दुर्भाग्य से, मुझे कहानी को बचाने का कोई तरीका नहीं मिला, लेकिन स्रोत फ़ाइल का नाम नहीं बदलने के लिए (यदि कोई भी मुझे बता सकता है!)। हालाँकि, सब कुछ सहन करेगा; अब कोई भी एक अलग कमिट में फाइल का नाम बदलने की जहमत नहीं उठाता:

 git mv $f1 $f git commit -m"split finish, rename $f1 to $f"

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

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

अद्यतन: लिस्सोव से व्यंजनों की एक जोड़ी

इतिहास रिपॉजिटरी भाग को अलग करें

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

महत्वपूर्ण! सभी आंदोलनों को git mv साथ किया जाना चाहिए, अन्यथा गिट इतिहास खो सकता है।

हम बाहर ले:

 git filter-branch --prune-empty --subdirectory-filter "{directory}" [branch]

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

 git remote set-url origin {another_repository_url}` git checkout move_from_Repo_1

यदि दूसरा भंडार साफ है, तो आप सीधे मास्टर के पास जा सकते हैं। खैर, धक्का:

 git push -u move_from_Repo_1

संपूर्ण स्निपेट (आसान कॉपी-पेस्ट के लिए):

 directory="directory_to_extract"; newurl="another_repository_url" git filter-branch --prune-empty --subdirectory-filter "$directory" git remote set-url origin "$newurl" git checkout move_from_Repo_1 git push -u move_from_Repo_1

दो रिपोजिटरी को एक साथ मिलाएं

मान लीजिए कि आपने 2 गुना अधिक किया और brunches move_from_Repo_1 और move_from_Repo_2 , और प्रत्येक में आपने git mv का उपयोग करके फ़ाइलों को स्थानांतरित कर दिया जहां वे मर्ज के बाद होना चाहिए। अब इसे नियंत्रित करना है:

 br1="move_from_Repo_1"; br2="move_from_Repo_2" git checkout master git merge origin/$br1 --allow-unrelated-histories git merge origin/$br2 --allow-unrelated-histories git push

पूरी चाल-चलन-असंबद्ध-इतिहास है। नतीजतन, हमें सभी परिवर्तनों के पूर्ण इतिहास के साथ एक भंडार मिलता है।

चाल के एक जोड़े को कभी-कभी गिट के साथ काम करने की आवश्यकता होती है

कम से कम दर्द के साथ पुरानी शाखाओं को मिलाएं

इतिहास को ध्यान में रखते हुए फ़ाइल का हिस्सा चुनें

इतिहास रिपॉजिटरी भाग को अलग करें

दो रिपोजिटरी को एक साथ मिलाएं

More articles: