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

डिपेंडेंट कमिट्स को किस क्रम का उपयोग करना चाहिए?

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

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

Terminal में इतिहास का निरीक्षण करें

अपने Mac पर Terminal खोलें, रिपॉजिटरी फ़ोल्डर में जाएं, और अपनी वर्तमान स्थिति की जांच करें। उद्धृत पथ (quoted path) को अपनी रिपॉजिटरी के वास्तविक पथ से बदलें; कोट्स लगाने से फ़ोल्डर नामों में स्पेस की अनुमति मिलती है।

cd "/path/to/your/repository"
git status --short --branch
git log --graph --oneline --decorate --all

पहला कमांड Terminal की वर्किंग डायरेक्टरी को बदलता है। git status चेक-आउट की गई ब्रांच और किसी भी स्थानीय बदलाव को दिखाता है। ग्राफ़ व्यू आपको यह देखने में मदद करता है कि सोर्स ब्रांच पर कौन से कमिट हैं और उनका क्रम क्या है। macOS Terminal डिफ़ॉल्ट रूप से zsh का उपयोग करता है, और ऊपर दिए गए कमांड सामान्य शेल सिंटैक्स का उपयोग करते हैं जो वहां समर्थित है। Apple की Terminal गाइड

यदि आवश्यक ब्रांच एक रिमोट ट्रैकिंग ब्रांच है और इसकी नवीनतम स्थिति स्थानीय रूप से मौजूद नहीं है, तो निरीक्षण करने से पहले फ़ेच करें:

git fetch origin
git log --reverse --oneline origin/feature-name

origin/feature-name को वास्तविक रिमोट ब्रांच नाम से बदलें। रिवर्स विकल्प कमिट्स को सबसे पुराने से नए के क्रम में प्रदर्शित करता है। बड़े इतिहास के लिए, किसी ज्ञात सामान्य बेस के बाद के कमिट्स तक लॉग को सीमित करें, उदाहरण के लिए git log --reverse --oneline base-commit..origin/feature-name। परिणामी विषयों को पढ़ें, फिर git show COMMIT_ID के साथ उम्मीदवार परिवर्तनों का निरीक्षण करें। समीक्षा के लिए एक कमिट रेंज सुविधाजनक है, लेकिन यह न मान लें कि एक रेंज तर्क अपने आप में उस कस्टम निर्भरता क्रम की गारंटी देता है जिसकी आपको आवश्यकता है: स्पष्ट कमिट आईडी इच्छित क्रम को स्पष्ट बनाती हैं।

पूर्वापेक्षा क्रम में चेरी-पिक करें

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

git switch destination-branch
git status --short --branch
git cherry-pick a1b2c3 d4e5f6

Git दिए गए क्रम में प्रत्येक चयनित परिवर्तन के लिए एक नया कमिट बनाता है। आउटपुट की सावधानीपूर्वक जांच करें: यदि कोई बदलाव पहले से ही किसी अन्य रास्ते से शामिल किया गया था, या डेस्टिनेशन में विचलन (divergence) हुआ है, तो Git एक खाली परिवर्तन की रिपोर्ट कर सकता है या किसी विरोध (conflict) के कारण रुक सकता है। इसके बाद, git log --oneline -n 5 और git status के साथ परिणामी इतिहास और वर्किंग ट्री का निरीक्षण करें। परिणाम पर भरोसा करने से पहले प्रोजेक्ट की प्रासंगिक जांच चलाएं; एक साफ़ चेरी-पिक का मतलब केवल यह है कि Git ने परिवर्तनों को लागू कर दिया है, यह नहीं कि फ़ीचर उम्मीद के मुताबिक व्यवहार कर रहा है।

यदि किसी कमिट में विरोध (conflict) होता है

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

git add "path/to/resolved-file"
git cherry-pick --continue

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

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

स्रोत