Comprehensive Guide to Git Cherry-pick: Selective Commit Migration Between Branches

Fundamental Principles of Cherry-pick Operations

In the Git version control system, cherry-pick is a powerful tool that allows developers to copy specific commits from one branch to another. When executing the git cherry-pick <commit-sha> command, Git creates a new commit containing the same changes as the original commit but with a completely new SHA-1 hash value.

Analysis of SHA Value Changes

A common confusion users encounter when using cherry-pick is: why do new commits have different SHA values from the original commits? This stems from Git's commit mechanism. Each Git commit's SHA value is based not only on file content changes but also includes metadata such as commit time, author information, and parent commit references. Even with identical file changes, different timestamps and parent commits will generate completely different SHA values.

Consider the following example:

# Original commit
Original commit: be530cec7748e037c665bd5a585e6d9ce11bc8ad

# New commit after cherry-pick
New commit: a1b2c3d4e5f67890123456789012345678901234

Optimizing Tracking with -x Parameter

To address tracking issues, Git provides the -x option. When using git cherry-pick -x <sha>, Git appends the original commit's SHA value to the new commit message, which is highly valuable for auditing and tracking cherry-pick operations.

Practical operation example:

$ git cherry-pick -x be530cec7748e037c665bd5a585e6d9ce11bc8ad
[dev a1b2c3d] Fix critical security vulnerability
 Date: Thu Nov 16 14:30:00 2023 +0800
 1 file changed, 15 insertions(+)
 (cherry picked from commit be530cec7748e037c665bd5a585e6d9ce11bc8ad)

Suitable Scenarios for Cherry-pick

Cherry-pick is particularly useful in the following situations:

• Backporting fixes: Applying critical fixes from production to older release branches without introducing new features
• Emergency production fixes: Applying hotfixes to development branches for testing
• Selective feature migration: Extracting specific features from branches that cannot be merged
• Cross-repository code reuse: Copying changes from fork repositories to upstream repositories

Detailed Operational Procedures

The standard workflow for executing cherry-pick includes:

1. Identify the target commit's SHA value: Use git log to view commit history
2. Switch to the target branch: git checkout target-branch
3. Execute cherry-pick: git cherry-pick <commit-sha>
4. Handle potential conflicts and continue operations

Conflict Resolution Strategies

When cherry-pick encounters conflicts, Git pauses the operation and marks conflicting files. The resolution process is as follows:

# After manually resolving conflicts
$ git add <resolved-file>
$ git cherry-pick --continue

# To abort the operation
$ git cherry-pick --abort

Consideration of Alternative Approaches

While cherry-pick is powerful, alternative approaches should be considered in certain situations:

• When most changes from a branch are needed, using git merge might be more appropriate
• If the original commit contains complex dependencies, creating new customized commits might be clearer
• For consecutive multiple commits, consider using git cherry-pick <start-sha>..<end-sha> range operations

Best Practice Recommendations

To maintain clear version history, it is recommended to:

• Always use the -x option for tracking purposes
• Clearly explain the reason for cherry-picking in commit messages
• Regularly check for duplicate changes to avoid code redundancy
• Establish unified cherry-pick usage standards within teams