Cherry-pick: यह क्या है, इसे कैसे करें और Git कमांड्स

Git में cherry-pick क्या है

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

वाक्यविन्यास: git cherry-pick <commit-hash>। Git निर्दिष्ट कमिट के अपने पैरेंट के साथ अंतर (diff) का विश्लेषण करता है और उस अंतर को वर्तमान ब्रांच पर लागू करता है। यदि कई फ़ाइलें बदली जाती हैं, तो वे सभी एक साथ स्थानांतरित हो जाती हैं। कमांड रेंज भी स्वीकार करता है: git cherry-pick A..B — A से B तक के सभी कमिट, A को छोड़कर।

फ़्लैग क्षमताओं का विस्तार करते हैं: -n (--no-commit) कमिट बनाए बिना कार्यशील निर्देशिका और इंडेक्स में परिवर्तन लागू करता है — तब उपयोगी जब आपको कई कमिट के परिवर्तनों को एक में संयोजित करने की आवश्यकता होती है। -x फ़्लैग कमिट संदेश में एक पंक्ति (cherry picked from commit ...) जोड़ता है, जिससे इतिहास में परिवर्तनों की उत्पत्ति को ट्रैक करना आसान हो जाता है।

# हैश द्वारा एकल कमिट पर cherry-pick लगाएँ
git cherry-pick a1b2c3d

# कई कमिट पर cherry-pick लगाएँ (क्रमिक रूप से)
git cherry-pick a1b2c3d e4f5g6h i6j7k8l

# बिना auto-commit के cherry-pick लगाएँ
git cherry-pick -n a1b2c3d

# -x फ़्लैग मूल कमिट का संदर्भ जोड़ता है
git cherry-pick -x a1b2c3d

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

मुख्य परिदृश्य है रिलीज़ ब्रांचों के बीच सुधार स्थानांतरित करना। कल्पना करें: develop में एक गंभीर बग पाया और ठीक किया गया। रिलीज़ ब्रांच release/v2.1 पहले से अलग है और इसमें भी यह बग मौजूद है। पूरे develop को release में merge करने से बहुत सारा अधूरा कोड आएगा, जबकि एकल फिक्स कमिट पर cherry-pick लागू करना एक सुरक्षित और सटीक समाधान है।

दूसरा परिदृश्य है बाद में बहाली के साथ परिवर्तनों को पूर्ववत करना। यदि कोई कमिट git revert के माध्यम से पूर्ववत किया गया और बाद में पता चलता है कि पूर्ववत करना गलत था — पूर्ववत किए गए कमिट पर cherry-pick लागू करने से परिवर्तन बहाल हो जाते हैं। यह revert को पूर्ववत करने से अधिक सही है क्योंकि यह बार-बार विरोध पैदा नहीं करता है।

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

• बगफिक्स — अधूरे कोड के बिना develop से release में सुधार स्थानांतरित करना।
• Hotfix — hotfix ब्रांच से main और develop दोनों में एक साथ सुधार लागू करना।
• गलत revert को पूर्ववत करना — परिवर्तन बहाल करने के लिए पूर्ववत किए गए कमिट पर cherry-pick लागू करना।
• परीक्षण — एकीकरण परीक्षण के लिए विभिन्न ब्रांचों से चुनिंदा कमिट एकत्र करना।

Cherry-pick बनाम rebase और merge

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

एक और अंतर है लेखकत्व। Cherry-pick के दौरान, Git डिफ़ॉल्ट रूप से मूल कमिट के लेखक को बनाए रखता है, लेकिन committer वर्तमान उपयोगकर्ता बन जाता है। कमिट संदेश -x फ़्लैग के माध्यम से उत्पत्ति को ट्रैक कर सकता है। Rebase के दौरान, लेखक और committer दोनों नई हैश के साथ वर्तमान उपयोगकर्ता बन जाते हैं।

प्रदर्शन: एकल कमिट पर cherry-pick लगाना कई कमिट वाली दो ब्रांचों को merge करने से तेज़ है। लेकिन यदि आपको दर्जनों कमिट स्थानांतरित करने की आवश्यकता है, तो एक अस्थायी ब्रांच बनाना और rebase करना बेहतर है — यह अधिक कुशल होगा और दर्जनों हैश निर्दिष्ट करने की आवश्यकता नहीं होगी।

कई कमिट स्थानांतरित करना

कई कमिट को एक कमांड से स्थानांतरित किया जा सकता है: git cherry-pick A B C। Git निर्दिष्ट क्रम में कमिट को क्रमिक रूप से लागू करता है। यदि कोई कमिट विरोध का कारण बनता है, तो cherry-pick रुक जाता है, और डेवलपर को विरोध हल करना होगा, फिर git cherry-pick --continue के साथ जारी रखना होगा।

कमिट रेंज: git cherry-pick A..B (A के बाद B तक के सभी कमिट, A को छोड़कर) और git cherry-pick A^..B (A से B तक के सभी कमिट)। रेंज तब सुविधाजनक होती हैं जब आपको पैरेंट संबंध के बिना एक ब्रांच से सभी कमिट स्थानांतरित करने की आवश्यकता होती है — उदाहरण के लिए, पुरानी ब्रांच से नई ब्रांच में एक पूर्ण फ़ीचर स्थानांतरित करते समय।

--strategy फ़्लैग यह निर्धारित करता है कि Git परिवर्तन कैसे लागू करेगा। डिफ़ॉल्ट रूप से recursive रणनीति का उपयोग किया जाता है, लेकिन आप विरोध पक्ष को स्वचालित रूप से चुनने के लिए ours या theirs निर्दिष्ट कर सकते हैं। --mainline फ़्लैग merge कमिट पर cherry-pick लगाते समय उपयोग किया जाता है — यह पैरेंट नंबर (1 या 2) निर्दिष्ट करता है जिसके सापेक्ष diff की गणना की जाती है।

# Cherry-pick कमिट रेंज
git cherry-pick develop~5..develop~2

# Merge कमिट पर cherry-pick लगाएँ (पैरेंट निर्दिष्ट करें)
git cherry-pick -m 1 m9n0o1p

# theirs रणनीति का उपयोग करें
git cherry-pick --strategy=recursive \
  --strategy-option=theirs a1b2c3d

# विरोध समाधान के बाद जारी रखें
git cherry-pick --continue

Cherry-pick के दौरान विरोध

Cherry-pick के दौरान विरोध तब होता है जब स्थानांतरित किए जा रहे कमिट के परिवर्तन उसी पंक्तियों को प्रभावित करते हैं जिन्हें लक्ष्य ब्रांच में बदला गया था। Git निष्पादन रोक देता है, विरोध वाली फ़ाइलों को चिह्नित करता है, और समाधान की प्रतीक्षा करता है। स्थिति में, ऐसी फ़ाइलें both modified के रूप में दिखाई देती हैं।

विरोध हल करने के चरण: विरोध वाली फ़ाइल खोलें, विरोध चिह्नक खोजें (<<<<<<<, =======, >>>>>>>), सामग्री संपादित करें, चिह्नक हटाएँ, हल की गई फ़ाइलों के लिए git add चलाएँ, और git cherry-pick --continue निष्पादित करें। यदि विरोध हल नहीं किया जा सकता — git cherry-pick --abort पूरे cherry-pick को रद्द कर देता है, ब्रांच को उसकी मूल स्थिति में लौटाता है।

एक सामान्य समस्या: कमिट में पहले से मौजूद परिवर्तनों के समतुल्य परिवर्तन हैं। इस मामले में, Git cherry-pick का प्रयास करते समय “nothing to commit” या “empty commit” रिपोर्ट करता है। --keep-redundant-commits और --empty=keep फ़्लैग Git को अनुक्रम बनाए रखने के लिए एक खाली कमिट बनाने के लिए मजबूर करते हैं, जबकि --skip ऐसे कमिट को छोड़ने की अनुमति देता है।

# Cherry-pick के दौरान विरोध — रुकें
git cherry-pick a1b2c3d
# error: a1b2c3d... कमिट संदेश लागू नहीं किया जा सका

# विरोध हल करें → इंडेक्स में जोड़ें
git add src/conflicted_file.swift
git cherry-pick --continue

# खाली कमिट छोड़ें (पहले से लागू)
git cherry-pick --skip

# पूर्ण निरस्तीकरण
git cherry-pick --abort

Cherry-pick की सर्वोत्तम प्रथाएँ

पहला नियम: हमेशा सत्यापित करें कि स्थानांतरित किया जा रहा कमिट आत्मनिर्भर है। यदि कमिट A कमिट B के परिवर्तनों पर निर्भर करता है जो स्थानांतरित नहीं किया जा रहा है, तो A पर cherry-pick लगाने से बिल्ड टूट सकता है। Cherry-pick से पहले, git show --stat <hash> के माध्यम से यह जाँचना उपयोगी है कि कमिट ने कौन सी फ़ाइलें बदली हैं।

दूसरा नियम: cherry-pick संचालन का दस्तावेज़ीकरण करें। -x फ़्लैग का उपयोग करें ताकि कमिट संदेश मूल कमिट के संदर्भ को बनाए रखे। यह बाद के इतिहास विश्लेषण के दौरान यह समझने में मदद करेगा कि परिवर्तन कहाँ से आया। -x के बिना, cherry-pick एक नियमित कमिट जैसा दिखता है, और इसकी उत्पत्ति केवल git log --graph के माध्यम से निर्धारित की जा सकती है।

तीसरा नियम: उन ब्रांचों के बीच cherry-pick से बचें जो बहुत अधिक विचलित हो गई हैं। यदि कमिट बनाए जाने के बाद बहुत समय बीत चुका है और कोडबेस में काफी बदलाव आया है, तो विरोध असंख्य और जटिल होंगे। ऐसे मामलों में, लक्ष्य ब्रांच में सुधार को फिर से लागू करना बेहतर है — दर्जनों विरोधों को हल करने की तुलना में इसमें कम समय लगेगा।

• Cherry-pick केवल बाहरी निर्भरताओं के बिना आत्मनिर्भर कमिट।
• -x फ़्लैग संदेश में कमिट उत्पत्ति का दस्तावेज़ीकरण करने के लिए अनिवार्य है।
• बचें महत्वपूर्ण कोडबेस विचलन वाले पुराने कमिट पर cherry-pick लगाने से।
• CI/CD cherry-pick के बाद बिल्ड सत्यापित करें: विरोध नहीं हुआ हो सकता है, लेकिन कोड संकलित नहीं हो सकता है।
• PR टिप्पणी pull request बनाते समय इंगित करें कि cherry-pick के माध्यम से कौन से कमिट स्थानांतरित किए गए थे।