Git Cherry-Pick: कई commits, branches और conflicts

TL;DR: git cherry-pick <sha> किसी भी branch से एक commit उठाकर आपकी मौजूदा branch पर copy कर देता है — वही patch, नया SHA, history कहीं नहीं हिलती। कई commits के लिए SHA list करें या range लें (git cherry-pick A..B); ध्यान रहे range में A छूट जाता है, इसलिए उसे भी साथ लाने के लिए A^..B लिखें। अगर बीच में conflict पर रुक जाए, तो resolve करें, git add करें, फिर git cherry-pick --continue। Cherry-pick एक ख़ास fix ले जाने का काम है — जब दूसरी branch का सब कुछ चाहिए, तो merge या rebase करें।

git cherry-pick असल में क्या करता है?

Cherry-pick मौजूदा commit उठाकर उसका diff आपकी मौजूदा branch पर नए commit की तरह लगा देता है। मूल commit अपनी जगह खड़ा रहता है; copy को नया SHA मिलता है। Git कुछ भी “हिलाता” नहीं — जो लोग बाद में पूछते हैं कि commit पुरानी branch पर अब भी दिख रहा है क्यों, वे ठीक यही देख रहे होते हैं।

यही copy-नहीं-move वाला model तय करता है कि cherry-pick कब सही tool है:

• किसी feature branch का एक fix अभी main पर चाहिए, बाक़ी सब merge किए बिना।
• ग़लत branch पर लगा hotfix सही branch पर जाना चाहिए।
• किसी release branch पर patch दोबारा लगाना है जो main से कभी merge नहीं करती।

इसका जोड़ीदार हुनर है किसी ग़लत निकले commit को वापस निकालना — उसकी बारीक़ियाँ git undo last commit: keep the changes में हैं।

दूसरी branch से commit cherry-pick कैसे करें?

SHA ढूँढ़ें, target branch पर जाएँ, pick करें:

# 1. Source branch पर वह commit ढूँढ़ें
git log feature/payment-fix --oneline -5

# 2. उस branch पर जाएँ जिसे यह मिलना चाहिए
git switch main

# 3. उसे copy करके लाएँ
git cherry-pick 1a2b3c4

दो सुविधाएँ जो काम आती हैं:

• git cherry-pick <branch> उस branch का सबसे ऊपरी (tip) commit उठाता है — काम की बात है, पर यह भूल-भूल से भी हो जाता है जब “tip” की आपकी समझ पुरानी हो।
• Pick के बाद git log -1 --stat confirm करता है कि क्या उतरा। एक सेकंड का पढ़ना, एक revert बचा लेता है।

Commits feature/payment-fix पर बनी रहती हैं; उस branch को जब चाहें हटा दें — main पर पहुँची copy का अपना SHA है और पुराने से कोई मोह नहीं।

एक से ज़्यादा commits cherry-pick कैसे करें?

तीन शक्लें, उस क्रम में जितनी बार ज़रूरत पड़ती है:

# 1. साफ़-साफ़ लिस्ट — आपके लिखने के क्रम में pick होंगी
git cherry-pick 1a2b3c4 5d6e7f8

# 2. Range — A के बाद से B तक, B समेत
git cherry-pick A..B

# 3. A समेत range
git cherry-pick A^..B

A..B बनाम A^..B का फ़र्क़ वही पुराना चौंकाने वाला मोड़ है: A..B में A छूट जाता है। अगर आप git log से range को आँखों में रखकर oldest..newest pick करें, तो सबसे पुराना commit चुपचाप रह जाएगा। जब मक़सद “सबसे पुराने कुछ commits, उन्हीं क्रम में” हो, तो oldest^..newest लिखें — off-by-one ग़ायब।

तीन picks को तीन commits की जगह एक में सिलना हो, तो -n / --no-commit से बिना commit किए stage करें, फिर एक बार commit करें:

git cherry-pick -n 1a2b3c4 5d6e7f8
git commit -m "Backport: payment retry fixes"

git cherry-pick काम क्यों नहीं कर रहा?

चार असली वजहें, आम होने के क्रम में:

1. Conflict ने pick को रोक दिया। Git patch लगाता है, ऐसी line पर पहुँचता है जो दोनों branches पर बदली थी, और sequence के बीच रुक जाता है:

# फ़ाइलें resolve करें, फिर:
git add <resolved-files>
git cherry-pick --continue   # या --abort से pick से पहले वाली हालत में लौटें

--continue optional नहीं और अपने-आप भी नहीं होता — जब तक आप इसे नहीं चलाते, आप रुकी हुई cherry-pick sequence के अंदर हैं और git status बार-बार यही कहता रहेगा।

2. Pick खाली निकला (“The previous cherry-pick is now empty”)। बदलाव इस branch पर पहले से मौजूद है — अक्सर किसी पुराने pick या squashed merge से। git cherry-pick --skip से छोड़ दें, या अगर आपको वह निशानी सच में चाहिए तो --allow-empty से खाली commit बनवाएँ।

3. Commit कोई merge commit है। Merge के दो parents होते हैं, इसलिए “यह diff लगाओ” अस्पष्ट है — git अंदाज़ा लगाने की बजाय मना कर देता है। बता दें कि आप किस parent के मुक़ाबले diff ले रहे हैं:

git cherry-pick -m 1 <merge-sha>   # parent 1 = वह branch जिसमें आपने merge किया था

4. ग़लत working tree या detached HEAD। Pick वहीं उतरता है जहाँ HEAD इशारा कर रहा हो। Pick से पहले git branch --show-current चलाएँ; अगर कुछ न छपे, आप detached HEAD में हैं और branch बदलते ही commit अनाथ हो जाएगा।

Cherry-pick vs merge vs rebase: कब कौन सा?

कमांड	Target पर क्या उतरता है	History	कब इस्तेमाल करें
git cherry-pick <sha>	सिर्फ़ नाम वाले commit(s)	Copy, नए SHA	कोई एक ख़ास fix अभी ले जाना हो
git merge <branch>	Branch का सब कुछ	Merge commit या fast-forward	पूरी branch चाहिए, divergence दिखती रहे
git rebase <base>	Branch के सारे commits, दोबारा लिखकर	Linear, बदले हुए SHA	Branch एक साफ़ linear सिलसिले की तरह चाहिए
git revert <sha>	किसी commit का उलटा	एक undo commit जुड़ता है	Shared history पर लग चुका commit वापस लेना हो

एक line का नियम: cherry-pick चुनिंदा चीज़ ले जाता है; merge और rebase सब कुछ। किसी branch के साथ “sync” के लिए cherry-pick उठाना संकेत है कि आपको असल में merge चाहिए — और अगर वह branch आपके fork की main बनाम upstream है, तो पूरा routine sync a fork with upstream, step by step में है।

एक आदत जो टालनी चाहिए: वही commit लंबे समय तक कई branches में cherry-pick करते रहना। Source branch पर हर आगे का fix माँगे एक और pick, और कुछ समय में branches अलग-थलग हो जाती हैं। Release branches पर backport सामान्य pattern है; हमेशा चलने वाली समानांतर दुनिया नहीं।

Cherry-pick workflow, संक्षेप में

git log <source-branch> --oneline -5   # SHA(s) ढूँढ़ें
git switch <target-branch>             # सही जगह पहुँचें
git cherry-pick A^..B                  # range, list, या single SHA
# conflict पर: resolve → git add → git cherry-pick --continue
git log -1 --stat                      # क्या उतरा, कन्फ़र्म करें

ढूँढ़ें, switch करें, pick करें, verify करें। इस कमांड को ख़तरनाक होने का जो बदनाम मिला है, वह उसका हक़ नहीं — diff या तो लग जाता है, या रुककर बता देता है कि क्यों नहीं। असल में बर्बादी करने वाली एक ही ग़लती है: ग़लत branch में pick करना — और push से पहले git log -1 उसे छिपने का मौक़ा ही नहीं देती।