git - एक गिट रिबेस को पूर्ववत करना
rebase git-rebase (10)
क्या कोई जानता है कि गिट रिबेस को आसानी से पूर्ववत कैसे किया जाए?
दिमाग में आने का एकमात्र तरीका मैन्युअल रूप से जाना है:
- गिट चेकआउट माता-पिता दोनों शाखाओं को चेकआउट करें
- फिर वहां से एक अस्थायी शाखा बनाएं
- चेरी-सब हाथ से काम करता है
- उस शाखा को प्रतिस्थापित करें जिसमें मैंने मैन्युअल रूप से बनाई गई शाखा द्वारा पुन: प्रयास किया था
मेरी वर्तमान स्थिति में यह काम करेगा क्योंकि मैं आसानी से दोनों शाखाओं से काम करता हूं (एक मेरी चीज थी, दूसरा मेरा सहयोगी सामान था)।
हालांकि मेरा दृष्टिकोण मुझे उपोक्त और त्रुटि-प्रवण के रूप में मारता है (मान लीजिए कि मैंने अपनी खुद की शाखाओं में से 2 के साथ पुनर्विचार किया था)।
कोई विचार?
स्पष्टीकरण: मैं एक रिबेस के बारे में बात कर रहा हूं जिसके दौरान कामों का एक गुच्छा फिर से चलाया गया था। न केवल एक।
@ एलन और @ ज़ीरिन के समाधान के बाद, मेरी इच्छा है कि मैं बस एक टिप्पणी कर सकता हूं लेकिन मुझे पर्याप्त प्रतिष्ठा नहीं है, इसलिए मैंने निम्न आदेश का उपयोग किया है:
git rebase -i --abort ( git rebase -i --abort i ) मुझे बस git rebase --abort ( बिना -i के ) करना था।
एक ही समय में -i और --abort दोनों का उपयोग करके गिट को मुझे उपयोग / विकल्पों की एक सूची दिखाने का कारण बनता है।
तो इस समाधान के साथ मेरी पिछली और वर्तमान शाखा स्थिति है:
[email protected] /my/project/environment (branch-123|REBASE-i)
$ git rebase --abort
[email protected] /my/project/environment (branch-123)
$
अपनी पुरानी नोक की लटकती प्रतिबद्ध वस्तु को शाखा को रीसेट करना निश्चित रूप से सबसे अच्छा समाधान है, क्योंकि यह किसी भी प्रयास के बिना पिछले राज्य को पुनर्स्थापित करता है। लेकिन अगर आप ऐसा करते हैं जो खो जाते हैं (f.ex. क्योंकि आप इस दौरान अपने भंडार को कचरा इकट्ठा करते हैं, या यह एक नया क्लोन है), तो आप हमेशा शाखा को फिर से दबा सकते हैं। इसकी कुंजी --onto स्विच है।
आइए मान लें कि आपके पास एक विषय शाखा कल्पनात्मक रूप से topic कहा जाता topic , जिसने master की नोक 0deadbeef प्रतिबद्धता के बाद master को 0deadbeef था। कुछ समय पर topic शाखा पर, आपने git rebase master किया था। अब आप इसे पूर्ववत करना चाहते हैं। ऐसे:
git rebase --onto 0deadbeef master topic
यह उन सभी topic पर काम करेगा जो master पर नहीं हैं और उन्हें 0deadbeef शीर्ष पर फिर से 0deadbeef ।
--onto साथ, आप अपने इतिहास को किसी भी आकार में बहुत अधिक आकार में पुनर्व्यवस्थित कर सकते हैं।
मज़े करो। :-)
कई प्रतिबद्धताओं के लिए, याद रखें कि कोई प्रतिबद्धता उस प्रतिबद्धता के लिए अग्रणी सभी इतिहास का संदर्भ देती है। तो चार्ल्स के जवाब में, "पुरानी प्रतिबद्धता" को "पुराने कामों में से नवीनतम" के रूप में पढ़ें। यदि आप उस प्रतिबद्धता पर रीसेट करते हैं, तो उस प्रतिबद्धता तक पहुंचने वाला सभी इतिहास फिर से दिखाई देगा। यह वही करना चाहिए जो आप चाहते हैं।
चार्ल्स का जवाब काम करता है, लेकिन आप यह करना चाहते हैं:
git rebase --abort
reset बाद साफ करने के लिए।
अन्यथा, आपको संदेश मिल सकता है " Interactive rebase already started "।
मुझे आश्चर्य है कि अभी तक कोई भी इसका उल्लेख नहीं करता है। ORIG_HEAD पुराने राज्य को ORIG_HEAD रूप में छोड़ देता है, ताकि आप ORIG_HEAD अंतिम ORIG_HEAD को वापस कर सकें:
git reset --hard ORIG_HEAD
मैं वास्तव में शाखा पर बैकअप टैग डालता हूं इससे पहले कि मैं कोई नॉनट्रिविअल ऑपरेशन करता हूं (अधिकांश रिबेज छोटे होते हैं, लेकिन अगर ऐसा कहीं भी जटिल लगता है तो मैं ऐसा करूँगा)।
फिर, पुनर्स्थापित करना git reset --hard BACKUP रूप में आसान है।
यदि आप गिट रिबेस के भीतर कुछ गड़बड़ करते हैं, उदाहरण के लिए git rebase --abort , जबकि आपके पास git rebase --abort फाइलें हैं, तो वे खो जाएंगे और git reflog मदद नहीं करेगा। यह मेरे साथ हुआ और आपको यहां बॉक्स के बाहर सोचने की आवश्यकता होगी। यदि आप मेरे जैसे भाग्यशाली हैं और इंटेलिजे वेबस्टॉर्म का उपयोग करते हैं तो आप right-click->local history कर सकते हैं और अपनी फ़ाइल / फ़ोल्डरों की पिछली स्थिति पर वापस जा सकते हैं इससे कोई फर्क नहीं पड़ता कि आपने संस्करण सॉफ्टवेयर के साथ क्या गलतियों की है। एक और असफलता चलाना हमेशा अच्छा होता है।
यदि आपने रिबेस को पूरा नहीं किया है और इसके बीच में, निम्न कार्य करता है:
git rebase --abort
रद्द करने के लिए, आप निम्न आदेश दर्ज कर सकते हैं:
git -c core.quotepath=false rebase --abort
सबसे आसान तरीका शाखा के सिर प्रतिबद्धता को ढूंढना होगा क्योंकि यह reflog में रिबेस शुरू होने से ठीक पहले था ...
git reflog
और वर्तमान शाखा को रीसेट करने के लिए (सामान्य चेतावनी के साथ --hard विकल्प के साथ रीसेट करने से पहले पूरी तरह से सुनिश्चित होने के बारे में)।
मान लीजिए कि रेफ लॉग में पुरानी प्रतिबद्धता [email protected]{5} थी:
git reset --hard [email protected]{5}
विंडोज़ में, आपको संदर्भ उद्धृत करने की आवश्यकता हो सकती है:
git reset --hard "[email protected]{5}"
आप केवल git log [email protected]{5} ( विंडोज़: git log "[email protected]{5}" ) करके उम्मीदवार के पुराने सिर का इतिहास देख सकते हैं।
यदि आपने प्रति शाखा रीफ्लॉग को अक्षम नहीं किया है, तो आपको अंतिम सिर पर git reflog [email protected]{1} करने से पहले शाखा प्रमुख को अलग करने के लिए git reflog [email protected]{1} रूप में git reflog [email protected]{1} करने में सक्षम होना चाहिए। मैं इसे दोबारा जांचूंगा, हालांकि मैंने हाल ही में यह सत्यापित नहीं किया है।
डिफ़ॉल्ट रूप से, सभी रीफ्लॉग गैर-नंगे भंडारों के लिए सक्रिय होते हैं:
[core]
logAllRefUpdates = true
