git चेरी-पिक का कहना है "... 38c74d एक मर्ज है, लेकिन कोई विकल्प नहीं दिया गया था"

Question

मैंने अपनी मास्टर ब्रांच में कुछ बदलाव किए हैं और उन अपस्ट्रीम को लाना चाहता हूं। जब मैं चेरी का चयन करता हूं, तो मैं fd9f578 पर अटक जाता हूं जहां गिट कहता है:

$ git cherry-pick fd9f578
fatal: Commit fd9f57850f6b94b7906e5bbe51a0d75bf638c74d is a merge but no -m option was given.

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

ये वे कमिट्स हैं, जिन्हें मैं ऊपर लाना चाहता हूं।

e7d4cff added some comments...
23e6d2a moved static strings...
44cc65a incorporated test ...
40b83d5 whoops delete whitspace...
24f8a50 implemented global.c...
43651c3 cleaned up ...
068b2fe cleaned up version.c ...
fd9f578 Merge branch 'master' of ssh://extgit/git/sessions_common
4172caa cleaned up comments in sessions.c ...

Answer 1

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

इसलिए, यदि किसी प्रतिबद्ध में दो या अधिक माता-पिता हैं, तो यह दो या अधिक भिन्नताओं का भी प्रतिनिधित्व करता है - कौन सा लागू किया जाना चाहिए?

आप चेरी लेने की कोशिश कर रहे हैं fd9f578, जो दो माता-पिता के साथ मर्ज था। इसलिए आपको चेरी-पिक कमांड को बताने की जरूरत है कि -mविकल्प के उपयोग से किसके खिलाफ अंतर की गणना की जानी चाहिए । उदाहरण के लिए, git cherry-pick -m 1 fd9f578मूल 1 को आधार के रूप में उपयोग करना।

मैं आपकी विशेष स्थिति के लिए निश्चित रूप से नहीं कह सकता, लेकिन git mergeइसके बजाय git cherry-pickआमतौर पर उपयोग करना उचित है। जब आप एक मर्ज कमिटमेंट को चेर करते हैं, तो यह उस पेरेंट में किए गए सभी बदलावों को ध्वस्त कर देता है, जिन्हें आपने -mउस एक कमिट में निर्दिष्ट नहीं किया था । आप उनके सारे इतिहास को खो देते हैं, और उनके सभी अलग-अलग रूपों में एक साथ चमकते हैं। तुम्हारा कॉल।

Comments

@wufoo आपको शायद इसके बारे में भी सीखना चाहिए git rebase- यह एक मर्ज की तरह है, लेकिन दो शाखाओं को एकीकृत करने के बजाय यह एक को दूसरे के ऊपर बैठने के लिए ट्रांसप्लांट करता है।

— बोरिएलिड

आप मूल संख्या कैसे जानते हैं?

— एंथ्रोपिक

@Anentropic 1 "पहला माता-पिता" है, 2 "दूसरा माता-पिता" है, और इसी तरह। आदेश वह है जिसमें वे कमिट में सूचीबद्ध हैं (जैसा कि देखा गया है git showऔर जैसे)।

— बोरेलिड

@lkraav आप git reset --hard HEAD@{1}अपनी गुमशुदगी को वापस पाने के लिए भी कर सकते हैं। git resetइतिहास में "पीछे की ओर" जाने के लिए प्रतिबंधित नहीं है। git checkout -b mybranch HEAD@{1}काम भी करेगा।

— बोरेलिड

चेतावनी: git mergeअनपेक्षित परिणाम हो सकते हैं। वह कमांड पैरेंट ब्रांच पर मौजूद अन्य सभी (पुराने) कमिट्स को जोड़ देगा। आमतौर पर लोग चेरी-पिक का चुनाव करते हैं क्योंकि वे नहीं चाहते कि दूसरा कमिट हो। सुनिश्चित करें कि आप दोहराएं कि आप केवल उन परिवर्तनों को लागू कर रहे हैं जो आप चाहते हैं!

— के वी वी

Answer 2

-m मूल संख्या का मतलब है।

Git doc से:

आमतौर पर आप किसी मर्ज को चुन नहीं सकते क्योंकि आप नहीं जानते कि मर्ज के किस तरफ को मेनलाइन माना जाए। यह विकल्प मेनलाइन की मूल संख्या (1 से शुरू) निर्दिष्ट करता है और चेरी-पिक को निर्दिष्ट माता-पिता के सापेक्ष परिवर्तन को फिर से शुरू करने की अनुमति देता है।

उदाहरण के लिए, यदि आपका प्रतिबद्ध पेड़ नीचे की तरह है:

- A - D - E - F -   master
   \     /
    B - C           branch one

तब git cherry-pick Eआपके सामने आई समस्या का उत्पादन करेगा।

git cherry-pick E -m 1का अर्थ है उपयोग करना D-E, जबकि git cherry-pick E -m 2उपयोग करना B-C-E।

Answer 3

@ बोरेलिड का उत्तर सही है, लेकिन मान लीजिए कि आप एक शाखा के सटीक विलय इतिहास को संरक्षित करने के बारे में परवाह नहीं करते हैं और बस इसके एक रैखिक संस्करण को चेरी-पिक करना चाहते हैं। यह करने का एक आसान और सुरक्षित तरीका है:

प्रारंभिक स्थिति: आप शाखा पर हैं X, और आप कमिट्स को चेरी-पिक करना चाहते हैं Y..Z।

1. git checkout -b tempZ Z
2. git rebase Y
3. git checkout -b newX X
4. git cherry-pick Y..tempZ
5. (वैकल्पिक) git branch -D tempZ

इसके tempZआधार पर एक शाखा बनाने के लिए क्या है Z, लेकिन Yआगे से रैखिक के इतिहास के साथ , और फिर चेरी-कि Xबुलाया की एक प्रति पर उठाओ newX। (यह म्यूट करने के बजाय एक नई शाखा पर ऐसा करना सुरक्षित है X।) बेशक चरण 4 में संघर्ष हो सकता है, जिसे आपको सामान्य तरीके से हल करना होगा ( उस संबंध में cherry-pickबहुत पसंद rebaseहै)। अंत में यह अस्थायी tempZशाखा को हटा देता है ।

यदि चरण 2 संदेश "वर्तमान शाखा अस्थायी आज तक है" देता है, तो Y..Zपहले से ही रैखिक था, इसलिए बस उस संदेश को अनदेखा करें और चरण 3 पर आगे बढ़ें।

फिर समीक्षा करें newXऔर देखें कि क्या आपने वही किया जो आप चाहते थे।

(ध्यान दें: यह git rebase Xशाखा पर होने पर एक साधारण के समान नहीं है Z, क्योंकि यह किसी भी तरह से रिश्ते पर निर्भर नहीं करता है ; Xऔर Yआम पूर्वजों के बीच कमिट हो सकता है और Yआप ऐसा नहीं चाहते हैं।)

Comments

git rebase Yकहते हैंCurrent branch tempZ is up to date

— बसिलेव्स

मुझे लगता है कि इसका मतलब है कि Y..Zपहले से ही रैखिक था। तो आप उस संदेश को नजरअंदाज कर सकते हैं और चरण 3 और 4 के साथ आगे बढ़ सकते हैं

— डेरा हॉपवुड

दिलचस्प विचार, मुझे यह पूरी तरह से सराहना करने के लिए कागज पर खींचना पड़ा कि क्या हो रहा है = D

— क्रिस

प्रतिभाशाली। पूरी रेंज के लिए git चेरी-पिक ने या तो शिकायत की कि -m विकल्प गायब था या यह प्रदान किया गया था। आपका समाधान सुनहरा था। (एक सुझाव: इसके बाद अस्थायी शाखा हटाएं)

— ओथियस

ये अद्भुत है! मैं चेरी पिक के साथ संघर्ष कर रहा हूँ और केवल यह समझ में आता है। मुझे उठाए गए पत्रों से थोड़ी परेशानी थी (कुछ शाखाएँ और कमिट्स बड़े अक्षर हैं और कुछ शाखाएँ कम हैं)

— pcarvalho

Answer 4

सरल। चेरी-कमिट्स उठाओ। मर्ज को चेरी-पिक न करें।

यहां स्वीकार किए गए उत्तर को फिर से लिखना है जो संभावित दृष्टिकोणों के फायदे / जोखिमों को स्पष्ट करता है:

आप चेरी fd9f578 लेने की कोशिश कर रहे हैं, जो दो माता-पिता के साथ मर्ज था।

चेरी-मर्ज लेने के बजाय, सबसे सरल बात यह है कि आप वास्तव में मर्ज की प्रत्येक शाखा से जो कमिटमेंट चाहते हैं, उसे चुन लें।

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

व्याख्या

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

यदि किसी कमिट में दो या अधिक माता-पिता होते हैं, जैसा कि मर्ज के मामले में होता है, तो वह कमिट भी दो या अधिक भिन्न का प्रतिनिधित्व करता है। त्रुटि अनिश्चितता के कारण होती है, जिस पर भिन्न को लागू होना चाहिए।

विकल्प

यदि आप यह निर्धारित करते हैं कि आपको संबंधित कमेंट्स को मर्ज करने की जरूरत है, तो आपके पास दो विकल्प हैं:

1. (अधिक जटिल और अस्पष्ट; इतिहास को भी छोड़ देता है) आप संकेत कर सकते हैं कि किस माता-पिता को आवेदन करना चाहिए।

   • -mऐसा करने के लिए विकल्प का उपयोग करें । उदाहरण के लिए, git cherry-pick -m 1 fd9f578आधार के रूप में मर्ज में सूचीबद्ध पहले माता-पिता का उपयोग करेगा।

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

2. (सरल और अधिक परिचित; इतिहास को संरक्षित करता है) आप git mergeइसके स्थान पर उपयोग कर सकते हैं git cherry-pick।

   • जैसा कि आम तौर पर होता है git merge, यह उस सभी कमिट को लागू करने का प्रयास करेगा जो उस शाखा पर मौजूद है जिसे आप मर्ज कर रहे हैं, और उन्हें अपने गिट लॉग में व्यक्तिगत रूप से सूचीबद्ध करें।

Answer 5

@Daira होपवुड विधि का सरलीकरण एक सिंगल कमेंट चुनने के लिए अच्छा है। कोई अस्थायी शाखाएँ चाहिए।

लेखक के मामले में:

• Z वांटेड कमिट (fd9f578) है
• Y इससे पहले प्रतिबद्ध है
• X वर्तमान कार्य शाखा

फिर करो:

git checkout Z   # move HEAD to wanted commit
git reset Y      # have Z as changes in working tree
git stash        # save Z in stash
git checkout X   # return to working branch
git stash pop    # apply Z to current branch
git commit -a    # do commit

Comments

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

— डेरा होपवुड