Efficiently Cherry-Picking and Merging Commit Ranges to Target Branches in Git

Evolution of Commit Range Selection in Git

Within the Git version control system, selecting specific commit ranges and applying them to target branches represents a common yet error-prone operation. Early Git versions limited the cherry-pick command to single commit selection, making batch processing of multiple consecutive commits challenging. With the release of Git 1.7.2, this limitation saw breakthrough improvements.

Fundamental Syntax for Range Selection

Modern Git supports selecting multiple commits simultaneously through range notation. The basic syntax format is git cherry-pick A..B, where A and B represent the starting and ending commit hashes respectively. It's crucial to note that A must be older than B; otherwise, the command will fail silently. This syntax design ensures logical consistency in commit history.

Critical Differences in Range Inclusivity

In range notation, two primary methods exist for including the starting commit: using the ^ symbol and the ~ symbol. When employing git cherry-pick A^..B, Git selects commits starting from A's parent commit up to and including commit B. However, when commit A represents a merge commit, this notation may yield unexpected results.

Consider the following commit history scenario:

A---B---C-------D---E--CommitId99   <- master
     \         /
      X---Y---M                     <- feature (CommitId1 is M)

When executing git cherry-pick CommitId1^..CommitId99, since CommitId1 (commit M) is a merge commit, CommitId1^ points to its first parent commit D, transforming the range to D..CommitId99 and excluding commit M itself. In contrast, using git cherry-pick CommitId1~..CommitId99 correctly includes commit M, as CommitId1~ points to commit Y, making the range Y..CommitId99.

Alternative Approach Using rebase --onto

For complex commit range operations, git rebase --onto provides a more robust solution. This command enables reapplying specified commit ranges to new base commits, particularly suitable for scenarios requiring linear commit history preservation.

Detailed operational steps include:

# Create temporary branch at current integration branch location
git checkout -b tmp

# Move integration branch to end of working branch range
git branch -f integration last_SHA-1_of_working_branch_range

# Reapply patchset to tmp branch (original integration branch location)
git rebase --onto tmp first_SHA-1_of_working_branch_range~1 integration

This operation replays all commits from after the parent of first_SHA-1_of_working_branch_range up to the commit pointed to by integration (the last commit in the working branch range).

Conflict Resolution Strategies

When conflicts arise during commit replay, Git offers multiple resolution options:

• Resolve conflict and continue: git rebase --continue
• Skip current patch: git rebase --skip
• Abort entire operation: git rebase --abort

Scripted Cherry-Pick Approach

For scenarios requiring precise control over the selection process, combining git rev-list with loop structures enables scripted operations:

git rev-list --reverse --topo-order B~..D | while read rev 
do 
  git cherry-pick $rev || break 
done

This method permits verification after each cherry-pick operation, ensuring process reliability.

Operational Considerations

When performing commit range selection operations, special attention should be paid to:

• Ensuring the starting commit isn't a root commit to avoid "unknown revision" errors
• Noting potential impacts on subsequent merge operations, as cherry-picking creates new commit hashes
• Leveraging Git 2.9.x/2.10+ capabilities for direct cherry-pick operations on orphan branches (empty head)
• Preferring ~ symbol over ^ symbol to ensure consistent behavior when including merge commits

Best Practice Recommendations

Based on practical project experience, the following best practices are recommended:

• Visualize commit history using git log --oneline --graph before operations to ensure accurate range selection
• Validate operation results in testing environments before affecting production systems
• Prioritize rebase --onto over cherry-pick range operations for complex commit histories
• Establish team standards clarifying when to use cherry-pick versus merge or rebase operations