Handling Cherry-Pick Conflicts
Conflicts occur when the changes being cherry-picked can't be automatically applied to the target branch. This guide explains how to identify and resolve them.
Why Conflicts Happen
Cherry-pick conflicts typically occur when:
- Code divergence - Target branch has different code in the same location
- File deleted - File exists in source but was removed in target
- Renamed files - File was renamed differently in each branch
- Adjacent changes - Nearby code was modified in target branch
Identifying Conflicts
In recommit Dashboard
Check Cherry-Pick History for failed tasks:
| Status | Meaning |
|---|---|
| ✅ Success | Cherry-pick completed, PR created |
| ❌ Failed | Conflict or error occurred |
In GitHub
When a conflict occurs, recommit still creates a PR, but:
- PR title may indicate conflict
- PR may have merge conflicts
- CI checks might fail
Resolving Conflicts
Open the Conflicted PR
- Go to Cherry-Pick History in recommit
- Find the failed/conflicted entry
- Click the PR link to open in GitHub
Review the Conflict
In GitHub, you'll see:
- Conflict markers in the diff
- Files that need resolution
- Merge conflict indicator
Resolve Locally or in GitHub
Option A: Resolve in GitHub (Simple conflicts)
- Click "Resolve conflicts" button
- Edit the conflicted files
- Mark as resolved
- Commit the resolution
Option B: Resolve Locally (Complex conflicts)
# Fetch the cherry-pick branch
git fetch origin cherry-kit/123-v2
# Checkout the branch
git checkout cherry-kit/123-v2
# You'll see the conflicts, resolve them in your editor
# Then stage and commit
git add .
git commit -m "Resolve cherry-pick conflicts"
# Push the resolution
git push origin cherry-kit/123-v2Merge the PR
After resolving conflicts:
- Ensure CI passes
- Get review if required
- Merge the PR
Common Conflict Scenarios
Scenario 1: Code Changed in Both Branches
Situation: Same function modified differently
<<<<<<< HEAD
function calculate(x) {
return x * 2; // v2 has this
}
=======
function calculate(x) {
return x * 3; // Original PR has this
}
>>>>>>> cherry-pickResolution: Decide which version is correct, or combine them.
Scenario 2: File Deleted in Target
Situation: File was removed in target branch but modified in source
Resolution:
- If file should exist: recreate it with the changes
- If file should be deleted: skip those changes
Scenario 3: Import/Dependency Differences
Situation: Different package versions or imports
<<<<<<< HEAD
import { something } from 'package@v2';
=======
import { something } from 'package@v3';
>>>>>>> cherry-pickResolution: Use the version appropriate for the target branch.
Preventing Conflicts
Keep Branches Synchronized
Regularly merge or rebase between branches:
- Reduces divergence
- Earlier conflict detection
- Smaller, easier resolutions
Use Squash Merge
Squash merging creates single commits:
- Cleaner cherry-picks
- Fewer intermediate conflicts
- Easier to understand changes
Small, Focused PRs
Smaller PRs mean:
- Less code to conflict
- Easier to resolve if conflicts occur
- Faster review and merge
Avoid Long-Running Branches
The longer a branch lives, the more it diverges:
- Merge frequently
- Keep version branches updated
- Consider feature flags instead of long branches
Automated Conflict Detection
recommit will still create PRs even with conflicts, allowing you to resolve them in GitHub's interface.
When to Skip Cherry-Pick
Sometimes a cherry-pick shouldn't happen:
| Scenario | Action |
|---|---|
| Change not relevant to target version | Close the PR |
| Breaking change for older version | Close the PR |
| Dependency not available | Close the PR |
It's okay to close auto-created PRs if the change shouldn't be applied to that branch.
Conflict Resolution Workflow
Cherry-pick fails with conflict
│
▼
PR created anyway
│
▼
Review the conflict
│
┌────┴────┐
│ │
▼ ▼
Should Should NOT
apply? apply?
│ │
▼ ▼
Resolve Close PR
conflict
│
▼
Merge PRGetting Help
If you're stuck on a complex conflict: