Mac पर, Terminal या किसी कोड एडिटर में प्रत्येक कॉन्फ्लिक्ट वाली फ़ाइल को संपादित करके, पूरी हो चुकी फ़ाइलों को git add से स्टेज करके, और git cherry-pick --continue चलाकर चेरी-पिक कॉन्फ्लिक्ट का समाधान करें। Git रुक जाता है क्योंकि यह किसी कमिट को साफ़-सुथरे ढंग से लागू नहीं कर सका; आपकी वर्तमान ब्रांच में अभी वह कमिट शामिल नहीं हुआ है। आगे बढ़ने से पहले प्रत्येक कॉन्फ्लिक्ट के दोनों पक्षों की समीक्षा करें, और यदि आप आगे न बढ़ने का निर्णय लेते हैं तो git cherry-pick --abort का उपयोग करें। Git का cherry-pick दस्तावेज़ इस रुके हुए मोड और इसे जारी रखने के विकल्पों का वर्णन करता है।

1. प्रोजेक्ट फ़ोल्डर में Terminal खोलें

Spotlight से या Finder के Applications > Utilities फ़ोल्डर से Terminal खोलें। Terminal में, cd और उसके पाथ का उपयोग करके रिपॉजिटरी फ़ोल्डर में जाएँ। स्पेस (spaces) वाले फ़ोल्डर पाथ के लिए, पाथ को कोट्स (quotes) में रखें, उदाहरण के लिए cd "/Users/sam/Work/My Project"। आप अंत में स्पेस लगाकर cd भी टाइप कर सकते हैं, Finder से प्रोजेक्ट फ़ोल्डर को Terminal विंडो में ड्रैग कर सकते हैं, और फिर Return दबा सकते हैं। Apple, Terminal को macOS के कमांड-लाइन इंटरफ़ेस के रूप में वर्णित करता है; डिफ़ॉल्ट zsh शेल का उपयोग करते समय इसका प्रॉम्प्ट अक्सर % पर समाप्त होता है। Apple की Terminal गाइड इसे खोलने और प्रॉम्प्ट को पहचानने का तरीका बताती है।

पुष्टि करें कि आप रिपॉजिटरी में हैं और फ़ाइलों में बदलाव करने से पहले देखें कि Git क्या रिपोर्ट करता है:

git status

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

2. कॉन्फ्लिक्ट का निरीक्षण करें और तय करें कि फ़ाइल में क्या होना चाहिए

अपने एडिटर में प्रत्येक कॉन्फ्लिक्ट वाली टेक्स्ट फ़ाइल खोलें। Git उन सेक्शनों के चारों ओर मार्कर जोड़ता है जिनका वह समाधान नहीं निकाल सका। एक सामान्य सेक्शन इस तरह दिखता है:

<<<<<<< HEAD
content on the current branch
=======
content from the commit being cherry-picked
>>>>>>> commit subject or identifier

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

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

3. समाधानों को स्टेज करें और उनकी समीक्षा करें

फ़ाइल को हल करने के बाद, Git को स्टेज करके बताएँ कि इसका कॉन्फ्लिक्ट सुलझ गया है। git status द्वारा दिखाए गए सटीक पाथ का उपयोग करें; जिन पाथ में स्पेस हों उन्हें कोट्स में रखें:

git add "Sources/Example File.swift"

प्रत्येक हल किए गए पाथ के लिए इसे दोहराएँ। git add फ़ाइल की वर्तमान सामग्री को स्टेज करता है, इसलिए यदि इसमें असंबद्ध संपादन हैं तो समीक्षा करें कि आप क्या स्टेज कर रहे हैं। Git का git-add मैन्युअल यह दस्तावेज़ित करता है कि यह फ़ाइल सामग्री को इंडेक्स में जोड़ता है, जो अगले कमिट के लिए उपयोग किया जाने वाला स्टेजिंग क्षेत्र है। Git add

जाँचें कि क्या कोई कॉन्फ्लिक्ट शेष है और स्टेज किए गए समाधान का निरीक्षण करें:

git status
git diff --cached

git status में अब अनसुलझे पाथ सूचीबद्ध नहीं होने चाहिए। स्टेज किए गए diff को पढ़ें और पुष्टि करें कि इच्छित बदलाव मौजूद हैं और कॉन्फ्लिक्ट मार्कर या अनजाने में किए गए संपादन अनुपस्थित हैं। git diff --cached स्टेज किए गए परिवर्तनों को दिखाता है; Git diff इस समीक्षा विकल्प का विवरण देता है। यदि आपको कोई गलती मिलती है, तो फ़ाइल को संपादित करें, उसे फिर से स्टेज करें, और diff की एक बार फिर समीक्षा करें।

4. चेरी-पिक जारी रखें

जब सभी कॉन्फ्लिक्ट हल हो जाएँ और स्टेज हो जाएँ, तो चलाएँ:

git cherry-pick --continue

Git रुकी हुई प्रक्रिया को फिर से शुरू करता है और, सफल होने पर, चेरी-पिक किए गए परिवर्तन को एक नए कमिट के रूप में रिकॉर्ड करता है। यदि Git कमिट संदेश के लिए कोई एडिटर खोलता है, तो उस एडिटर के सामान्य नियंत्रणों का उपयोग करके इसे सहेजें और बंद करें। फिर git status की जाँच करें और यदि आवश्यक हो तो नवीनतम कमिट की समीक्षा करें:

git status
git log -1 --oneline

चेरी-पिक किए गए कमिट के अनुक्रम (sequence) के लिए, --continue प्रक्रिया को आगे बढ़ाता है; बाद का कमिट भी कॉन्फ्लिक्ट के लिए रुक सकता है। उस कमिट के कॉन्फ्लिक्ट को भी उसी तरह हल और स्टेज करें। Git विफल चेरी-पिक को फिर से शुरू करने के लिए --continue और वर्तमान कमिट को छोड़ने के लिए --skip का विवरण देता है। --skip का उपयोग केवल तभी करें जब आप जानबूझकर उस कमिट के परिवर्तन को छोड़ना चाहते हों, न कि अनसुलझी फ़ाइलों के शॉर्टकट के रूप में। Git cherry-pick options

यदि आप इसके बजाय रोकना चाहते हैं

यदि आप निर्णय लेते हैं कि चेरी-पिक को आगे नहीं बढ़ना चाहिए, तो git cherry-pick --abort चलाएँ। Git इसे प्रक्रिया को रद्द करने और क्रम शुरू होने से पहले की स्थिति में लौटने के रूप में दस्तावेज़ित करता है। यदि शुरू करने से पहले आपके पास स्थानीय कार्य (local work) था, तो बाद में git status से इसकी जाँच करें; वर्तमान स्थिति को समझने के विकल्प के रूप में विनाशकारी रीसेट (destructive reset) कमांड का उपयोग न करें। Git cherry-pick

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

स्रोत