git cherry-pick
UseCase of cherry-pick
git cherry-pick
is useful when you want to apply specific commits from one branch to another without merging the entire branch. Here are some real-world use cases with examples.
1. Hotfix from main
to release
branch
Scenario:
You're working on a main
branch and have fixed a critical bug. You need to apply only this fix to the release
branch without merging all main
changes.
Steps:
# Switch to the release branch
git checkout release
# Cherry-pick the commit from main
git cherry-pick <commit-hash>
# Push the changes
git push origin release
2. Selective Feature Backporting
Scenario:
A feature was developed in feature-branch
, but only part of it is needed in develop
before the full feature is ready.
Steps:
Switch to develop branch
git checkout develop
# Cherry-pick a single commit from feature-branch
git cherry-pick <commit-hash>
# Push the changes
git push origin develop
3. Fix a Mistakenly Committed Change
Scenario:
You accidentally committed a change to the wrong branch (main
instead of feature-xyz
). You need to move it to feature-xyz
and remove it from main
.
Steps:
# Switch to the correct branch
git checkout feature-xyz
# Cherry-pick the commit from main
git cherry-pick <commit-hash>
# Switch back to main and reset to remove the commit
git checkout main
git reset --hard HEAD~1
# Push the corrected branches
git push origin feature-xyz
git push origin main --force
โ ๏ธ Warning: The git reset --hard
and --force
push can rewrite history, so be careful when using them.
4. Resolving Merge Conflicts by Cherry-Picking One at a Time
Scenario:
You are trying to merge feature-branch
into develop
, but there are too many conflicts. Instead, you cherry-pick commits one by one and resolve conflicts individually.
Steps:
# Switch to develop
git checkout develop
# Cherry-pick the first commit
git cherry-pick <commit-hash>
# If thereโs a conflict, resolve it and continue
git add .
git cherry-pick --continue
# Repeat for more commits if necessary
git cherry-pick <next-commit-hash>
5. Extract a Commit from a PR
Scenario:
A pull request (PR) contains multiple commits, but only one of them should be merged into another branch.
Steps:
# Check out the branch where you want to apply the commit
git checkout develop
# Cherry-pick the needed commit from the PR branch
git cherry-pick <commit-hash>
# Push the changes
git push origin develop
Bonus: Cherry-Pick Multiple Commits
If you need multiple commits, use:
git cherry-pick <commit1-hash> <commit2-hash>
Or, for a range of commits:
git cherry-pick <oldest-commit-hash>^..<latest-commit-hash>
Final Tip
If cherry-picking leads to conflicts:
- Use
git cherry-pick --abort
to cancel. - Use
git cherry-pick --continue
after resolving conflicts.
Would you like a more detailed explanation on any of these cases? ๐
Question, extracting "chore" jobs from development branch
Yes, your use case for git cherry-pick
is a valid and practical approach! Here's why it makes sense and how you can refine it:
Why Your Approach Works Well
- Selective Commit Extraction: Instead of merging everything from
A
, you isolate only the "chore" commits (e.g., documentation,package.json
,settings.json
) into a separatechore
branch. - Clearer Code Review: The PR reviewers can focus only on chore-related changes, rather than filtering through unrelated commits from
A
. - Better Git History Management: The commit history remains clean by categorizing changes properly. You avoid cluttering your feature branch (
A
) with non-functional updates. - Avoids Unnecessary Merge Complexity: Instead of merging
A
(which may contain feature work in progress), you can apply only necessary commits.
Refining Your Workflow
Hereโs a structured way to implement this:
Step 1: Create a New chore
Branch
git checkout -b chore
Step 2: Find Commits for Chore Work
Use:
git log --oneline --author="Your Name"
or
git log --oneline --grep="chore"
to locate the commit hashes of chore-related tasks.
Step 3: Cherry-Pick Chore Commits
git cherry-pick <commit-hash-1> <commit-hash-2> <commit-hash-3>
or if the commits are sequential:
git cherry-pick <start-hash>^..<end-hash>
Step 4: Resolve Any Conflicts
If conflicts occur:
git add .
git cherry-pick --continue
If something goes wrong:
git cherry-pick --abort
Step 5: Push and Open a PR
git push origin chore
Then, open a pull request from chore
to the appropriate branch (e.g., develop
or main
).
Alternative Approach (Interactive Rebase)
If most of your commits in A
are chore-related but mixed with some feature work, you could rebase and split them instead of cherry-picking:
-
Interactive Rebase on
A
git checkout A git rebase -i <base-branch> # Example: git rebase -i develop
-
Mark "chore" Commits as
edit
- Change
pick
toedit
for chore-related commits. - Rebase stops at each chore commit.
- Change
-
Move the Commit to
chore
git checkout -b chore git commit --amend # Modify commit if necessary git push origin chore
This approach is safer if many commits are mixed together.
Final Thoughts
โ
Using git cherry-pick
in your case is a great choiceโit isolates chore changes efficiently.
โ
It helps keep feature branches clean and improves PR readability.
โ
If your branch A
already has a mix of work, consider interactive rebase as an alternative.
Your method is already well-structured! ๐ Would you like help automating this process with a script?
Question, Merge strategy based on workflow
In your case, the chore
branch should be merged into main
, but the timing and strategy depend on your workflow. Here's how you should approach it:
1. Merge Strategy Based on Workflow
๐น If A
is still in development (WIP)
- You donโt want to merge all of
A
yet, but you need to merge the chore-related changes. - โ
Merge
chore
intomain
first. - โ
A
continues development separately.
Steps:
git checkout main
git merge chore --no-ff
git push origin main
๐น If A
will be merged soon
- If
A
is almost ready to be merged intomain
, then mergingchore
first can lead to duplicate commits inA
. - โ
Merge
chore
intoA
first. - โ
Then merge
A
intomain
.
Steps:
git checkout A
git merge chore --no-ff
git push origin A
# Later, merge A into main
git checkout main
git merge A --no-ff
git push origin main
๐น If A
is already merged into main
-
If
A
got merged intomain
before thechore
PR, then some chore commits may already be inmain
. -
In this case, check if the commits exist in
main
already:git log main --grep="chore"
-
If they exist, you may not need to merge
chore
separately. -
If they donโt exist, merge
chore
normally.
2. Best Practice to Avoid Merge Conflicts
To avoid merge conflicts when merging A
later:
-
Rebase
A
on top ofmain
afterchore
is mergedgit checkout A git rebase main
-
If there are conflicts, resolve them
git add . git rebase --continue
-
Push updated
A
git push origin A --force-with-lease # Use force only if needed
Final Answer
- โ
If
A
is still in progress: Mergechore
intomain
directly. - โ
If
A
is almost ready: Mergechore
intoA
first, then mergeA
intomain
. - โ
If
A
is already merged intomain
: Check if chore commits already exist before mergingchore
separately.
Would you like a visualization of the git history to clarify this? ๐