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:

Would you like a more detailed explanation on any of these cases? ๐Ÿš€

Question, extracting "chore" jobs from development branch

I worked on branch name A. A has several "chore" jobs such as documentation, package.json, settings.json which should be revealed explicitly. I chose cherry-pick to gather all these jobs in a "chore" branch and opened a PR for it. Is this usecase okay of using cherry-pick feature?

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

  1. Selective Commit Extraction: Instead of merging everything from A, you isolate only the "chore" commits (e.g., documentation, package.json, settings.json) into a separate chore branch.
  2. Clearer Code Review: The PR reviewers can focus only on chore-related changes, rather than filtering through unrelated commits from A.
  3. Better Git History Management: The commit history remains clean by categorizing changes properly. You avoid cluttering your feature branch (A) with non-functional updates.
  4. 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:

  1. Interactive Rebase on A

    git checkout A
    git rebase -i <base-branch>  # Example: git rebase -i develop
    
  2. Mark "chore" Commits as edit

    • Change pick to edit for chore-related commits.
    • Rebase stops at each chore commit.
  3. 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)

Steps:

git checkout main
git merge chore --no-ff
git push origin main

๐Ÿ”น If A will be merged soon

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


2. Best Practice to Avoid Merge Conflicts

To avoid merge conflicts when merging A later:

  1. Rebase A on top of main after chore is merged

    git checkout A
    git rebase main
    
  2. If there are conflicts, resolve them

    git add .
    git rebase --continue
    
  3. Push updated A

    git push origin A --force-with-lease  # Use force only if needed
    

Final Answer

Would you like a visualization of the git history to clarify this? ๐Ÿš€

Question, Why cherry-picked commits are duplicated?