Applying Specific Commits with git cherry-pick

1. Learning Outcomes#

इस chapter को पूरा करने के बाद आप:

समझ पाएँगे कि git cherry-pick किसी selected existing commit की changes को current branch पर क्यों और कैसे apply करता है।
commit hash से सही commit identify कर पाएँगे।
git cherry-pick <commit> का safe basic workflow follow कर पाएँगे।
समझ पाएँगे कि cherry-pick के बाद नया commit बनता है और उसका commit ID source commit से अलग क्यों होता है।
बिना पूरी branch merge किए targeted fix या backport apply कर पाएँगे।
cherry-pick, merge और rebase के बीच practical difference समझ पाएँगे।
conflict आने पर पहले सीखी हुई conflict-resolution process का उपयोग करके git cherry-pick --continue चला पाएँगे।
गलत या unwanted cherry-pick को git cherry-pick --abort से रोक पाएँगे।
duplicate changes और unnecessary cherry-picking से बचने की practical strategy समझ पाएँगे।

2. एक Practical Situation से शुरुआत#

मान लीजिए आपकी team के पास दो branches हैं:

main — यहाँ latest development चल रही है।
release/2.1 — यह production release के लिए stable branch है।

main पर एक urgent bug fix commit हो चुका है। लेकिन main में उस fix के बाद कई नई features भी हैं, जिन्हें अभी release/2.1 में नहीं ले जाना है।

यहाँ पूरी main branch merge करना सही choice नहीं है। हमें केवल एक specific bug-fix commit चाहिए।

यही वह situation है जहाँ git cherry-pick बहुत useful होता है।

Key Idea

git cherry-pick पूरी branch नहीं उठाता। यह किसी चुने हुए existing commit की change को current branch पर apply करता है और वहाँ एक नया commit बनाता है।

3. Cherry-Pick का Simple Mental Model#

Cherry-pick को ऐसे समझिए: source branch की पूरी history को target branch में मिलाने के बजाय, आप history में से केवल एक जरूरी change चुनते हैं।

मान लीजिए main पर commit C में bug fix है और release branch अभी commit B पर है।

Visual Diagram80%

Rendering diagram…

इस visual में solid arrows commit history दिखाते हैं। Dotted path यह दिखाता है कि C की change select करके release branch पर apply की गई। Target branch पर resulting commit D एक नया commit है।

यह point बहुत important है: cherry-pick source commit को physically move नहीं करता और न ही वही commit object दूसरी branch पर चिपकाता है। वह उस commit की change को current branch की current state पर apply करके नया commit बनाता है।

4. Step 1 — जिस Commit को Transfer करना है, उसे Identify करें#

Cherry-pick के लिए आपको उस commit का hash चाहिए जिसे apply करना है।

Recent commits देखने के लिए:

BASH

git log --oneline

मान लीजिए आपको यह bug fix commit मिला:

a1b2c3d Fix payment validation bug

यहाँ a1b2c3d वह short commit hash है जिसे हम cherry-pick करेंगे।

Commit apply करने से पहले उसकी change inspect करना एक अच्छा professional habit है:

BASH

git show a1b2c3d

इससे आप verify कर सकते हैं कि selected commit वास्तव में वही change है जिसकी target branch को जरूरत है।

Remember

Commit hash देखकर blindly cherry-pick न करें। पहले commit message और diff देखकर confirm करें कि आप सही change transfer कर रहे हैं।

5. Step 2 — Target Branch पर जाएँ#

Cherry-pick हमेशा current branch पर नया commit बनाता है।

इसलिए पहले उस branch पर switch करें जिसे change receive करनी है।

BASH

git switch release/2.1

अब branch और working tree verify करें:

BASH

git status

Practical work में cherry-pick शुरू करने से पहले working tree को clean रखना बेहतर है। इससे unrelated local changes और cherry-pick changes mix होने का risk कम होता है।

अब एक बार branch name mentally confirm करें: क्या यही वह branch है जहाँ fix चाहिए? यदि हाँ, तभी आगे बढ़ें।

6. Step 3 — Selected Commit Apply करें#

Basic syntax:

BASH

git cherry-pick <commit>

हमारे example में:

BASH

git cherry-pick a1b2c3d

यदि conflict नहीं आता, तो Git selected commit की change current branch पर apply करता है और नया commit create करता है।

अब history देखने के लिए:

BASH

git log --oneline --decorate --graph

आप target branch पर नया commit देखेंगे। उसका message source commit जैसा हो सकता है, लेकिन commit ID सामान्यतः अलग होगा।

7. Cherry-Pick नया Commit क्यों बनाता है?#

यह concept समझना जरूरी है, क्योंकि beginners अक्सर सोचते हैं कि source commit का वही hash दूसरी branch पर दिखाई देगा।

Git commit ID केवल file changes से नहीं बनता। Commit object में कई महत्वपूर्ण चीजें होती हैं, जैसे:

project tree की snapshot reference
parent commit
author information
committer information
commit message
related timestamps और metadata

Cherry-pick के समय target branch का parent अलग होता है। नया commit target branch की current history के ऊपर बनता है। Committer metadata भी नया हो सकता है।

इसलिए source commit और cherry-picked commit की logical change समान हो सकती है, लेकिन पूरा commit object समान नहीं होता। इसी कारण उनका commit ID अलग होता है।

उदाहरण के लिए:

source branch पर fix commit: a1b2c3d
target branch पर cherry-picked result: f7e8d9a

इन दोनों IDs का अलग होना normal है।

Key Idea

Cherry-pick का goal same commit ID copy करना नहीं है। Goal selected commit की change को दूसरी history पर apply करना है।

8. पूरी Branch Merge किए बिना Selected Change लेना#

मान लीजिए main में यह sequence है:

M1 — login improvement
M2 — payment bug fix
M3 — new dashboard
M4 — experimental API change

Release branch को केवल M2 चाहिए।

यदि आप पूरी main branch merge करते हैं, तो बाकी unrelated changes भी आ सकती हैं। Cherry-pick आपको केवल M2 जैसी targeted change लेने देता है।

इसका practical benefit यह है कि stable release branch में केवल approved fix पहुँचाई जा सकती है।

लेकिन यही power गलत use करने पर history को confusing भी बना सकती है। इसलिए cherry-pick को targeted transfer tool की तरह use करें, routine branch synchronization tool की तरह नहीं।

9. Cherry-Pick vs Merge vs Rebase#

तीनों commands history से related हैं, लेकिन उनका उद्देश्य अलग है।

Operation	मुख्य उद्देश्य	क्या पूरी branch history integrate होती है?	Typical use
`git cherry-pick`	Selected commit की change current branch पर apply करना	नहीं	Targeted fix, backport
`git merge`	दो development histories को integrate करना	हाँ, branch history के context में	Branch integration
`git rebase`	Commits को नए base पर replay करके history reorganize करना	Selected branch commits replay होते हैं	Linear history / base update

कब Cherry-Pick बेहतर है?#

जब requirement हो:

“मुझे पूरी branch नहीं चाहिए; केवल यह specific approved change चाहिए।”

कब Merge बेहतर है?#

जब दूसरी branch का पूरा relevant development current branch में integrate करना हो।

कब Rebase relevant है?#

जब commits को किसी नए base के ऊपर replay करके history को reorganize या update करना हो।

Common Mistake

Cherry-pick को merge का universal replacement मत समझिए। यदि branches को नियमित रूप से पूरी development history share करनी है, तो merge या team-approved rebase workflow अधिक appropriate हो सकता है।

10. Backport क्या है?#

Backport का simple meaning है: किसी newer development line में हुई fix को older supported release में ले जाना।

मान लीजिए bug पहले main पर fix हुआ:

BASH

git log --oneline

आपने fix commit का hash identify किया: a1b2c3d.

अब older release branch पर जाएँ:

BASH

git switch release/2.1

फिर fix apply करें:

BASH

git cherry-pick a1b2c3d

यही एक common backport workflow है।

Backport के बाद केवल Git command success देखना काफी नहीं है। Older release का code context अलग हो सकता है, इसलिए build, tests और relevant application behavior verify करना चाहिए।

11. Targeted Fix का दूसरा Common Use Case#

कभी-कभी feature branch पर काम करते हुए एक useful independent fix भी commit हो जाता है।

उदाहरण:

feature branch में दस commits हैं।
उनमें से केवल एक commit production bug fix करता है।
बाकी nine commits अभी incomplete feature से related हैं।

Production या release branch पर पूरी feature branch merge करने के बजाय केवल fix commit cherry-pick किया जा सकता है।

यहाँ भी rule वही है:

सही commit identify करें।
target branch पर switch करें।
commit inspect करें।
cherry-pick करें।
result test करें।

12. Conflict आने पर क्या होता है?#

Cherry-pick हर बार automatic नहीं होता।

यदि source commit जिस code को बदल रहा है, target branch पर वही area अलग तरह से बदल चुका है, तो Git conflict detect कर सकता है।

ऐसी स्थिति में cherry-pick बीच में pause हो जाता है।

Visual Diagram80%

Rendering diagram…

यहाँ नया conflict-resolution concept नहीं है। वही familiar process apply होती है: conflict inspect करें, correct content decide करें, markers remove करें, resolved file stage करें, फिर cherry-pick continue करें।

Conflict के समय Status देखें#

BASH

git status

Git आपको बताएगा कि कौन-सी files conflicted हैं।

Conflicted file खोलें और पहले सीखी हुई conflict-resolution approach से सही final content रखें।

फिर resolved file stage करें:

BASH

git add path/to/conflicted-file

यदि multiple files resolve की हैं, तो सभी required resolved files stage करें।

अब cherry-pick continue करें:

BASH

git cherry-pick --continue

Git pending cherry-pick complete करने की कोशिश करेगा और successful होने पर target branch पर नया commit बन जाएगा।

Remember

केवल file edit कर देना पर्याप्त नहीं है। Resolved file को git add से stage करना जरूरी है, ताकि Git जान सके कि conflict resolve हो चुका है।

13. Unwanted Cherry-Pick को Abort करना#

कभी conflict देखते समय आपको पता चलता है कि:

आपने wrong commit चुना था,
wrong target branch पर थे,
change अभी apply नहीं करनी चाहिए,
conflict बहुत risky है और पहले analysis चाहिए।

यदि cherry-pick अभी in progress है, तो उसे cleanly cancel करने के लिए:

BASH

git cherry-pick --abort

यह current cherry-pick operation को रोकता है और branch को उस state में वापस लाने की कोशिश करता है जहाँ वह cherry-pick शुरू होने से पहले थी।

--abort खासकर conflict के दौरान बहुत useful है, क्योंकि manually आधी changes undo करने से ज्यादा safe और clear workflow देता है।

14. `--continue` और `--abort` को Confuse न करें#

Command	कब use करें	परिणाम
`git cherry-pick --continue`	Conflicts resolve और stage कर चुके हैं, selected change अभी भी चाहिए	Pending cherry-pick आगे complete होता है
`git cherry-pick --abort`	Current cherry-pick cancel करना है	In-progress cherry-pick छोड़ा जाता है और pre-operation state restore की जाती है

Simple memory rule:

change चाहिए → resolve + stage + --continue
change नहीं चाहिए → --abort

15. Duplicate Changes से क्यों बचना चाहिए?#

Cherry-pick एक नई commit identity बनाता है। इसलिए यदि same logical change को बार-बार long-lived branches के बीच cherry-pick किया जाए, तो history में उस change की multiple commit IDs दिखाई दे सकती हैं।

उदाहरण:

main पर fix commit A
release पर उसका cherry-picked commit B
बाद में किसी workflow में equivalent change फिर से दूसरी direction में manually या cherry-pick के जरिए आ जाती है

अब team को समझना कठिन हो सकता है कि कौन-सी change पहले से मौजूद है, कौन-सी नई है, और future merge में conflict क्यों आ रहा है।

हर duplicate cherry-pick हमेशा conflict पैदा करेगा, ऐसा नहीं है। लेकिन unnecessary repeated cherry-picking history reasoning और future integration को complex बना सकता है।

Cherry-Pick से पहले Practical Checks#

Cherry-pick चलाने से पहले:

target branch confirm करें।
source commit का git show <commit> से diff inspect करें।
target branch history check करें।
सोचें कि क्या same logical fix पहले से target branch में किसी और commit के रूप में मौजूद है।
यदि पूरी branch integrate करनी है, तो cherry-pick की जगह normal merge/rebase strategy consider करें।
cherry-pick के बाद tests चलाएँ।

Warning

Long-lived branches को synchronize करने के लिए हर commit को अलग-अलग cherry-pick करना scalable strategy नहीं है। Cherry-pick को selective transfer के लिए रखें।

16. एक Safe End-to-End Workflow#

मान लीजिए fix commit a1b2c3d को release/2.1 में backport करना है।

पहले source commit inspect करें:

BASH

git show a1b2c3d

Target branch पर जाएँ:

BASH

git switch release/2.1

Working state verify करें:

BASH

git status

Commit apply करें:

BASH

git cherry-pick a1b2c3d

यदि conflict नहीं है, तो history inspect करें:

BASH

git log --oneline --decorate --graph

यदि conflict है, तो resolve करने के बाद:

BASH

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

यदि operation cancel करनी है:

BASH

git cherry-pick --abort

अंत में relevant tests, build और application behavior verify करें।

17. Common Mistakes#

Wrong Branch पर Cherry-Pick करना#

सबसे common mistake है सही commit select करना लेकिन wrong target branch checkout करना।

याद रखें: नया commit current branch पर बनता है।

Commit Hash Verify न करना#

Similar commit messages होने पर गलत hash pick हो सकता है। git show <commit> से diff inspect करना safer है।

Conflict Resolve करके `git add` भूल जाना#

Git तब तक cherry-pick continue नहीं कर सकता जब तक resolved files stage न हों।

Cherry-Pick को Branch Synchronization Strategy बना देना#

एक-दो targeted fixes के लिए cherry-pick बहुत useful है। लेकिन long-lived branches के regular full integration के लिए merge/rebase workflow अधिक suitable हो सकता है।

New Commit ID देखकर Panic करना#

Different hash expected behavior है। Cherry-pick selected change को नई history context में नया commit बनाकर apply करता है।

18. Hands-On Practice#

Practice 1#

Requirement

main branch पर commit 7ac91fe में production bug fix है। आपको केवल यही fix release/3.0 में apply करनी है।

Your Task

Safe command sequence लिखिए जिसमें target branch switch करना, commit inspect करना और cherry-pick करना शामिल हो।

HintShow Hint

पहले उस branch पर जाएँ जिसे change receive करनी है।

SolutionShow Solution

BASH

git show 7ac91fe
git switch release/3.0
git status
git cherry-pick 7ac91fe

Explanation

git show selected change verify करता है। git switch release/3.0 target branch को current branch बनाता है। git status current state confirm करता है। अंत में git cherry-pick 7ac91fe selected fix को release branch पर apply करता है।

Practice 2#

Requirement

Cherry-pick के दौरान src/payment/Validator.java में conflict आया। आपने conflict manually resolve कर दिया है और selected fix अभी भी रखना चाहते हैं।

Your Task

Cherry-pick safely complete करने के लिए अगली commands लिखिए।

HintShow Hint

Resolved file को पहले staged state में लाना होगा।

SolutionShow Solution

BASH

git status
git add src/payment/Validator.java
git cherry-pick --continue

Explanation

git status current conflict state verify करता है। git add Git को बताता है कि file resolve हो चुकी है। git cherry-pick --continue paused operation को complete करता है।

19. Interview Preparation#

What does git cherry-pick do?Show Answer

git cherry-pick applies the changes introduced by one or more selected existing commits onto the current branch, creating new commit(s) in the current branch's history.

Key Points:

It is used for selective commit transfer.
It does not merge an entire branch.
The resulting commit normally has a different commit ID.

Why interviewer asks this:

Interviewer यह check करना चाहता है कि आप targeted change transfer और full branch integration के बीच difference समझते हैं या नहीं।

Why does a cherry-picked commit usually get a different hash?Show Answer

Because the new commit is created in a different history context, typically with a different parent and committer metadata. A Git commit ID represents the complete commit object, not only the visible file changes.

Key Points:

Same logical change does not imply the same commit object.
Parent history affects commit identity.
Cherry-pick creates a new commit on the target branch.

Why interviewer asks this:

यह question Git commit identity और history model की conceptual understanding check करता है।

20. Quick Recap#

git cherry-pick selected existing commit की change को current branch पर apply करता है।
सही commit चुनने के लिए commit hash identify और inspect करें।
पहले target branch checkout करें, क्योंकि नया commit वहीं बनेगा।
Basic command है git cherry-pick <commit>.
Cherry-picked result नया commit होता है, इसलिए उसका hash source commit से सामान्यतः अलग होता है।
Targeted fixes और backports cherry-pick के strong use cases हैं।
Conflict आए तो resolve करें, files stage करें और git cherry-pick --continue चलाएँ।
गलत या unwanted in-progress operation को git cherry-pick --abort से cancel करें।
Long-lived branches के routine synchronization के लिए repeated cherry-picking avoid करें।
Cherry-pick के बाद history और tests दोनों verify करें।

Printing is unavailable

1. Learning Outcomes#

2. एक Practical Situation से शुरुआत#

3. Cherry-Pick का Simple Mental Model#

4. Step 1 — जिस Commit को Transfer करना है, उसे Identify करें#

5. Step 2 — Target Branch पर जाएँ#

6. Step 3 — Selected Commit Apply करें#

7. Cherry-Pick नया Commit क्यों बनाता है?#

8. पूरी Branch Merge किए बिना Selected Change लेना#

9. Cherry-Pick vs Merge vs Rebase#

कब Cherry-Pick बेहतर है?#

कब Merge बेहतर है?#

कब Rebase relevant है?#

10. Backport क्या है?#

11. Targeted Fix का दूसरा Common Use Case#

12. Conflict आने पर क्या होता है?#

Conflict के समय Status देखें#

13. Unwanted Cherry-Pick को Abort करना#

14. `--continue` और `--abort` को Confuse न करें#

15. Duplicate Changes से क्यों बचना चाहिए?#

Cherry-Pick से पहले Practical Checks#

16. एक Safe End-to-End Workflow#

17. Common Mistakes#

Wrong Branch पर Cherry-Pick करना#

Commit Hash Verify न करना#

Conflict Resolve करके `git add` भूल जाना#

Cherry-Pick को Branch Synchronization Strategy बना देना#

New Commit ID देखकर Panic करना#

18. Hands-On Practice#

Practice 1#

Practice 2#

19. Interview Preparation#

20. Quick Recap#

Practice lab

Operation	Main Purpose
`git cherry-pick`	Apply selected commit changes to the current branch
`git merge`	Integrate development histories
`git rebase`	Replay commits onto a new base

Printing is unavailable

1. Learning Outcomes#

2. एक Practical Situation से शुरुआत#

3. Cherry-Pick का Simple Mental Model#

4. Step 1 — जिस Commit को Transfer करना है, उसे Identify करें#

5. Step 2 — Target Branch पर जाएँ#

6. Step 3 — Selected Commit Apply करें#

7. Cherry-Pick नया Commit क्यों बनाता है?#

8. पूरी Branch Merge किए बिना Selected Change लेना#

9. Cherry-Pick vs Merge vs Rebase#

कब Cherry-Pick बेहतर है?#

कब Merge बेहतर है?#

कब Rebase relevant है?#

10. Backport क्या है?#

11. Targeted Fix का दूसरा Common Use Case#

12. Conflict आने पर क्या होता है?#

Conflict के समय Status देखें#

13. Unwanted Cherry-Pick को Abort करना#

14. --continue और --abort को Confuse न करें#

15. Duplicate Changes से क्यों बचना चाहिए?#

Cherry-Pick से पहले Practical Checks#

16. एक Safe End-to-End Workflow#

17. Common Mistakes#

Wrong Branch पर Cherry-Pick करना#

Commit Hash Verify न करना#

Conflict Resolve करके git add भूल जाना#

Cherry-Pick को Branch Synchronization Strategy बना देना#

New Commit ID देखकर Panic करना#

18. Hands-On Practice#

Practice 1#

Practice 2#

19. Interview Preparation#

20. Quick Recap#

14. `--continue` और `--abort` को Confuse न करें#

Conflict Resolve करके `git add` भूल जाना#