Cherry-pick — यह क्या है, तंत्र और Git में अनुप्रयोग

Cherry-pick क्या है?

Cherry-pick एक Git कमांड है जो निर्दिष्ट कमिट से परिवर्तनों की प्रतिलिपि बनाता है और उन्हें वर्तमान ब्रांच में एक नए कमिट के रूप में लागू करता है। नाम “चेरी चुनने” के रूपक से आया है: डेवलपर केवल उन कमिट का चयन करता है जिनकी उसे आवश्यकता है, बाकी को अनदेखा करता है।

Merge के विपरीत, cherry-pick मर्ज कमिट नहीं बनाता है और ब्रांचों के पूर्ण विलय की आवश्यकता नहीं होती है। Rebase के विपरीत, cherry-pick कमिट की श्रृंखला को स्थानांतरित नहीं करता है — केवल निर्दिष्ट कमिट को। यह cherry-pick को फिक्स के लक्षित स्थानांतरण के लिए एक आदर्श उपकरण बनाता है।

Atlassian, 2025 के अनुसार, cherry-pick का उपयोग 47% टीमों द्वारा किया जाता है जो एक साथ कई रिलीज़ ब्रांचों के साथ काम करती हैं। Cherry-pick विशेष रूप से मोबाइल डेवलपमेंट में मांग में है, जहां एक साथ एप्लिकेशन के कई संस्करण (LTS रिलीज़) समर्थित होते हैं और उनके बीच फिक्स स्थानांतरित करने की आवश्यकता होती है।

स्थानांतरण तंत्र

Cherry-pick निष्पादित करते समय, Git निर्दिष्ट कमिट और उसके पैरेंट के बीच diff की गणना करता है, फिर इस diff को वर्तमान ब्रांच पर लागू करता है। यदि परिवर्तन बिना विरोध के लागू हो जाते हैं — Git उसी संदेश के साथ लेकिन नए SHA के साथ एक नया कमिट बनाता है। यदि विरोध है — cherry-pick मैन्युअल समाधान के लिए रुक जाता है।

Cherry-pick कैसे काम करता है

सिंटैक्स cherry-pick सरल है: स्थानांतरित करने के लिए कमिट का हैश निर्दिष्ट करें। Git परिवर्तनों को वर्तमान ब्रांच में एक नए कमिट के रूप में कॉपी करता है। एक बार में कई कमिट और पूरी रेंज का स्थानांतरण समर्थित है।

# एक कमिट को वर्तमान ब्रांच में स्थानांतरित करें
git cherry-pick a1b2c3d4

# एकाधिक कमिट स्थानांतरित करें
git cherry-pick a1b2c3d4 e5f6g7h8

# कमिट की रेंज स्थानांतरित करें (a1b2 से f9e8 तक, a1b2 को छोड़कर)
git cherry-pick a1b2c3d4..f9e8d7c6

Cherry-pick निष्पादित करने के बाद, वर्तमान ब्रांच को स्रोत से परिवर्तनों के साथ एक नया कमिट मिलता है। कमिट संदेश डिफ़ॉल्ट रूप से स्रोत से कॉपी किया जाता है, लेकिन -n फ्लैग (कमिट न बनाएं) या --edit (संदेश संपादित करें) के साथ संशोधित किया जा सकता है।

फिक्स स्थानांतरित करने का उदाहरण

एक सामान्य परिदृश्य पर विचार करें: develop में एक महत्वपूर्ण बग पाया और ठीक किया गया है, जो रिलीज़ ब्रांच release/v2.0 में भी मौजूद है। पूरे develop को रिलीज़ ब्रांच में मर्ज किए बिना केवल इस फिक्स को स्थानांतरित करने की आवश्यकता है।

# Develop में फिक्स के साथ कमिट हैश खोजें
git log --oneline develop
# a1b2c3d fix: null check in payment processing

# रिलीज़ ब्रांच पर स्विच करें
git checkout release/v2.0

# फिक्स लागू करें
git cherry-pick a1b2c3d4

# यदि विरोध हो — हल करें और जारी रखें
git add src/payment/PaymentProcessor.kt
git cherry-pick --continue

-x फ्लैग कमिट संदेश में मूल SHA के लिए एक संदर्भ जोड़ता है: “(cherry picked from commit a1b2c3d4)”। यह ट्रैक करना आसान बनाता है कि कमिट कहाँ से स्थानांतरित किया गया था। अस्थायी ड्राफ्ट को छोड़कर सभी परिदृश्यों में -x का उपयोग करने की अनुशंसा की जाती है।

विरोधों के साथ काम करना

विरोध की स्थिति में, cherry-pick merge की तरह व्यवहार करता है: Git रुक जाता है और विरोध वाली फ़ाइलों को चिह्नित करता है। डेवलपर विरोध को हल करता है, git add चलाता है और git cherry-pick --continue निष्पादित करता है। रद्द करने के लिए — git cherry-pick --abort। --strategy फ्लैग मर्ज रणनीति निर्दिष्ट करने की अनुमति देता है (उदाहरण के लिए, विकल्पों के साथ recursive)।

# Cherry-pick के दौरान विरोध का समाधान
# Git विरोध वाली फ़ाइलें दिखाता है
git status

# मैन्युअल रूप से हल करें, फिर:
git add allowed_file.kt
git cherry-pick --continue

# या cherry-pick रद्द करें:
git cherry-pick --abort

Cherry-pick कब उपयोग करें

Cherry-pick उन परिदृश्यों में इष्टतम है जहां पूरी ब्रांचों को मर्ज किए बिना परिवर्तनों के लक्षित स्थानांतरण की आवश्यकता होती है। आइए पांच मुख्य मामलों पर नज़र डालें जहां cherry-pick सबसे अच्छा विकल्प बन जाता है।

• Hotfix स्थानांतरण — develop में एक फिक्स पाया गया, लेकिन इसे रिलीज़ ब्रांच (release/v2.0) पर लागू करने की आवश्यकता है। Cherry-pick develop से अधूरी सुविधाओं को प्रभावित किए बिना केवल फिक्स कमिट स्थानांतरित करता है
• पुराने संस्करणों में बैकपोर्ट — वर्तमान संस्करण के लिए एक फिक्स को LTS रिलीज़ में स्थानांतरित करने की आवश्यकता है। पूरे वर्तमान कोडबेस को मर्ज करने के बजाय, cherry-pick केवल आवश्यक कमिट का चयन करता है
• गलत ब्रांच में कमिट को पूर्ववत करना — यदि कोई कमिट गलत ब्रांच में किया गया था, cherry-pick इसे सही ब्रांच में स्थानांतरित करता है, और मूल कमिट को वापस ले लिया जाता है
• दस्तावेज़ीकरण स्थानांतरण — README या कॉन्फ़िगरेशन फ़ाइलों में परिवर्तन जो सभी ब्रांचों में होने चाहिए, cherry-pick के माध्यम से स्थानांतरित करना सुविधाजनक है
• चयनात्मक अनुप्रयोग — प्रोटोटाइप ब्रांच से, पूरे प्रोटोटाइप को मुख्य डेवलपमेंट में स्थानांतरित किए बिना केवल एक सफल कमिट लेने की आवश्यकता है

मोबाइल डेवलपमेंट के लिए, एप्लिकेशन के कई संस्करणों का समर्थन करते समय cherry-pick महत्वपूर्ण रूप से आवश्यक है। उदाहरण के लिए, यदि Google Play पर पहले से प्रकाशित संस्करण 3.2 में एक बग पाया जाता है, और develop में संस्करण 4.0 के लिए कोड है — cherry-pick सभी ब्रेकिंग चेंजेस को मर्ज किए बिना v3.x ब्रांच में फिक्स स्थानांतरित करने की अनुमति देता है। यह विशेष रूप से उन परियोजनाओं के लिए प्रासंगिक है जहां विभिन्न API और निर्भरताओं के साथ एक साथ दो या अधिक प्रमुख संस्करण समर्थित होते हैं।

व्यावहारिक उदाहरण: एक मोबाइल एप्लिकेशन में Android 12 पर Google Sign-In के माध्यम से प्रमाणीकरण के दौरान क्रैश पाया गया। फिक्स develop में किया गया और कोड समीक्षा पास करता है। हालांकि, वर्तमान रिलीज़ ब्रांच v2.5 पहले से बीटा परीक्षण चरण में है। Develop से release/v2.5 में फिक्स कमिट का Cherry-pick आगामी रिलीज़ में फिक्स शामिल करने की अनुमति देता है, बिना उन अन्य परिवर्तनों को स्थानांतरित किए जो अभी तक रिलीज़ के लिए तैयार नहीं हैं।

मोबाइल प्रोजेक्ट्स में cherry-pick का उपयोग करते समय, निर्भरताओं पर विचार करना महत्वपूर्ण है: यदि फिक्स उन फ़ाइलों को प्रभावित करता है जो रिलीज़ ब्रांच के विचलन बिंदु के बाद develop में बदल दी गई थीं, तो cherry-pick परिवर्तनों का अधूरा सेट ला सकता है। ऐसे मामलों में, यह सत्यापित करना आवश्यक है कि सभी संबंधित परिवर्तन भी स्थानांतरित किए गए हैं, अन्यथा एप्लिकेशन बिल्ड नहीं हो सकता या गलत तरीके से काम कर सकता है। साझा ब्रांच में परिवर्तन पुश करने से पहले हमेशा cherry-pick के बाद बिल्ड की जाँच करें।

Cherry-pick बनाम Merge बनाम Rebase

Git में परिवर्तनों को एकीकृत करने के तीन मुख्य उपकरण — merge, rebase और cherry-pick — विभिन्न कार्यों को हल करते हैं। चुनाव इस बात पर निर्भर करता है कि कितना परिवर्तन स्थानांतरित करने की आवश्यकता है और इतिहास कैसा दिखना चाहिए।

Merge — जब आपको दो ब्रांचों को पूरी तरह से मर्ज करने और शाखाकरण जानकारी संरक्षित करने की आवश्यकता हो। Rebase — जब आपको साफ इतिहास के साथ व्यक्तिगत ब्रांच को नवीनतम स्थिति में अपडेट करने की आवश्यकता हो। Cherry-pick — जब आपको केवल एक कमिट या कई चयनित कमिट की आवश्यकता हो।

व्यवहार में, ये उपकरण संयुक्त होते हैं: एक फीचर develop पर आवधिक rebase के साथ विकसित किया जाता है, फिर --no-ff merge के माध्यम से मर्ज किया जाता है, और जब किसी अन्य ब्रांच में फिक्स स्थानांतरित करने की आवश्यकता होती है, तो cherry-pick का उपयोग किया जाता है। प्रत्येक उपकरण अपने चरण में अपने कार्य को हल करता है।

Cherry-pick के जोखिम और सीमाएं

Cherry-pick एक उपयोगी लेकिन संभावित रूप से खतरनाक उपकरण है जब गलत या अत्यधिक उपयोग किया जाता है। मुख्य जोखिम कमिट डुप्लिकेशन, संदर्भ की हानि और बाद के मर्ज के दौरान विरोध से संबंधित हैं।

• कमिट डुप्लिकेशन — यदि वही कमिट बाद में merge के माध्यम से ब्रांच में आता है, Git परिवर्तनों में समान दूसरा कमिट बनाएगा। यह इतिहास को प्रदूषित करता है और git bisect को जटिल बनाता है
• संदर्भ की हानि — cherry-pick diff को स्थानांतरित करता है लेकिन पैरेंट कमिट और निर्भरताओं के बारे में जानकारी स्थानांतरित नहीं करता है। यदि cherry-pick ने कमिट B के बिना कमिट A लागू किया जिस पर A निर्भर था, तार्किक त्रुटियां हो सकती हैं
• मर्ज विरोध — cherry-pick के बाद, पूर्ण ब्रांच मर्ज के दौरान, Git एक ही परिवर्तनों को दो बार देख सकता है और ऐसे विरोध पैदा कर सकता है जो सामान्य मर्ज से बचे जा सकते थे
• ट्रेसेबिलिटी की कमी -x फ्लैग के बिना, यह जानना असंभव है कि एक कमिट दूसरी ब्रांच से स्थानांतरित किया गया था। परिवर्तन की उत्पत्ति की खोज करते समय, एक डेवलपर कमिट की उत्पत्ति का पता लगाने में घंटों बिता सकता है

जोखिम न्यूनीकरण के लिए सिफारिशें: मूल SHA को इंगित करने के लिए हमेशा -x फ्लैग का उपयोग करें, कमिट संदेश में cherry-pick के कारण का दस्तावेज़ीकरण करें, और जब संभव हो तो merge का उपयोग करें जब संदर्भ अनुमति देता है। यदि cherry-pick अधिक हो जाएं — ब्रांच पुनर्संरचना पर विचार करें।

Cherry-pick के लिए स्वचालित जाँच

CI पाइपलाइनों को cherry-pick को एक अलग परिदृश्य के रूप में मानना चाहिए। एक स्वचालित जाँच स्थापित करने की अनुशंसा की जाती है: जब कोई cherry-pick कमिट बनाया जाता है, CI सत्यापित करता है कि बदली गई फ़ाइलें अपेक्षित सेट से मेल खाती हैं और प्रभावित मॉड्यूल के लिए परीक्षण चलाता है। यह ब्रांचों के बीच परिवर्तन स्थानांतरित करते समय प्रतिगमन के जोखिम को कम करता है।