Git Cherry-Pick: How to Select and Apply Specific Commits

Syntax of Git Cherry-Pick

Understanding the git cherry-pick syntax is key to effectively using this command. It’s not just about selecting commits but about applying them precisely to achieve the desired outcome.

The basic syntax for cherry-picking a single commit is:

git cherry-pick <commit-hash>

• git cherry-pick: The command that initiates the operation.
• <commit-hash>: The unique identifier (SHA-1 hash) of the commit you want to cherry-pick. This hash can be found by running git log to list the commit history.

When executing the above command, Git applies the changes from the specified commit to the current branch, creating a new commit with the same changes but a different hash. 

It’s important to note that the command only transfers the commit itself, not the context or parent history from the original branch.

New to Git and GitHub? Get started with version control in this beginner-friendly GitHub and Git tutorial.

How to Use Git Cherry-Pick: Step-by-Step Examples

Now that you understand the basic syntax of git cherry-pick, it's time to see the command in action.

This section provides hands-on examples that walk you through common basic and more complex scenarios where cherry-picking is useful. Each example illustrates how to apply the changes from one or more commits to another branch. 

Example 1: Cherry-picking a single commit

Let’s say you’ve made a fix on a feature branch that you want to apply to the main branch without merging the entire feature branch.

• First, find the hash of the commit you want to cherry-pick by running:

git log

• Locate the commit’s hash. 
• Switch to the main branch:

git checkout main

• Run the cherry-pick command (assume the hash is abc1234):

git cherry-pick abc1234

When you run this command, Git will apply the changes from the commit identified by abc1234 to your current branch (which is main in this case). Git creates a new commit on the main branch that contains the same changes as the original commit but with a new commit hash.

Example 2: Cherry-picking multiple commits

In some situations, you may need to apply several distinct commits from one branch to another. Suppose you have three separate commits in your feature branch that you need to bring into the main branch.

• Find the commit hashes for each commit you want to cherry-pick using git log:

git log

• Switch to the main branch:

git checkout main

• Run the cherry-pick command, listing the commits:

git cherry-pick abc1234 def5678 ghi7890

Example 3: Cherry-picking a commit range

Let’s say you’ve made a series of commits on the feature branch and want to apply them to the main branch in one go without specifying each commit individually. How would you do it?

• Use git log to identify the start and end commits you want to cherry-pick (e.g., abc1234 to ghi7890).
• Switch to the main branch:

git checkout main

• Run the cherry-pick command with a commit range:

git cherry-pick abc1234...ghi7890

Example 4: Cherry-picking a commit from a remote branch

Sometimes, a critical fix exists in a remote branch, and you want to apply it to your local branch without merging the entire branch. Here’s how to do it:

• Fetch the latest changes from the remote repository

git fetch origin

• List the commits in the remote branch to find the hash you need:

git log origin/feature_branch --oneline

• Assume the commit hash you need is abc1234.
• Switch to your local main branch:

git checkout main

• Cherry-pick the commit from the remote branch:

git cherry-pick abc1234

This lets you apply a commit from a remote branch without merging the entire branch.

Need to check out a remote branch? Follow this step-by-step guide on Git checkout for remote branches.

Example 5: Cherry-picking a commit and modifying it

If you cherry-pick a commit but need to make slight modifications before committing, you can use Git’s interactive mode. Here’s how:

• Switch to the target branch:

git checkout main

• Cherry-pick the commit but stop before committing:

git cherry-pick -n abc1234

The -n (or --no-commit) flag applies the changes but does not create a commit.

• Modify the files as needed.
• Stage and commit the changes manually:

git add .
git commit -m "Modified cherry-picked commit from feature_branch"

This is useful when you need to tweak a cherry-picked commit before finalizing it.

Handling Conflicts During Git Cherry-Pick

Conflicts are inevitable when cherry-picking commits between branches, especially when the codebase has diverged significantly. 

While cherry-pick is designed to apply changes cleanly, it can’t always reconcile differences automatically. In these cases, conflicts must be resolved manually. Understanding how conflicts arise and how to handle them is crucial for completing a cherry-pick operation.

How conflicts happen

Conflicts typically occur when the changes from the cherry-picked commit overlap with or contradict changes already present in the target branch. For example:

• Same line modified in both branches: If the same line of code is modified in both the source and target branches, Git won’t know which version to apply.
• File deleted in one branch but modified in another: If a file is deleted in one branch but modified in the cherry-picked commit, Git will not know whether to retain it or apply the changes.
• Unrelated changes but same file: Even when the changes seem unrelated, if they occur within the same file, Git may flag it as a potential conflict.

When a conflict occurs, Git will stop the cherry-pick operation, leaving your working directory in a conflicted state that must be resolved before proceeding.

Resolving conflicts

Once a conflict arises, Git will provide indicators of the conflicting files, and you’ll need to manually resolve the discrepancies. Here’s how to resolve conflicts:

1. Check the conflicting files: Run the following command to see which files conflict:

git status

The command will display the list of files with conflicts. 

2. Resolve the conflicts: You can manually edit the conflicting files to resolve the issues. Remove the conflict markers (<<<<<<<, =======, >>>>>>>) and determine which changes to keep or how to combine them.

3. Use Git Mergetool (optional): If resolving conflicts manually is cumbersome, you can use a merge tool to assist in visualizing and resolving conflicts:

git mergetool

Depending on your configuration, the above tool will open a visual merge tool, which makes it easier to review and resolve conflicts.

4. Mark the conflicts as resolved: After resolving conflicts, mark the files as resolved using:

git add <conflicted-file>

5. Complete the cherry-pick: Once all conflicts are resolved and the files are staged, finalize the cherry-pick by running:

git cherry-pick --continue

Many modern IDEs and tools, such as Visual Studio Code and GitHub, offer built-in merge conflict resolution features. GitHub’s web interface allows you to resolve conflicts directly in pull requests, making it easier to collaborate on shared repositories without switching to a local environment.

Skipping a commit after a conflict

Sometimes, resolving a conflict may be too complex, or you may realize the commit is not necessary after all. In such cases, you can skip the commit entirely.

1. Abort the current cherry-pick process: If the conflict is too complicated, and you don’t want to apply the commit, you can skip it by running:

git cherry-pick --skip

This will abandon the conflicting commit and move on to the next one (if you’re cherry-picking multiple commits).

2. Abort the entire cherry-pick: If you want to abort the cherry-pick operation altogether, you can run:

git cherry-pick --abort

This command will restore your working directory to the state it was in before you started the cherry-pick. 

Want to clean up your commit history? Learn how to combine multiple commits into one with this Git squash tutorial.

Best Practices for Using Git Cherry-Pick

Misusing cherry-pick can lead to complicated histories and confusion in your project’s version control. To avoid these pitfalls, adhering to best practices ensures you’re using cherry-pick effectively without introducing unnecessary complexity to your codebase.

Keep it small and specific

Cherry-picking is most effective when used for small, specific commits that address well-defined tasks, such as bug fixes or minor feature enhancements. 

Avoid cherry-picking large, complex commits that bundle together multiple changes, as these can introduce conflicts and make it harder to manage the codebase. The more targeted the commit, the easier it is to apply without unintended side effects.

Document your cherry-picks

To maintain a clear history, always provide proper context when cherry-picking. This can be done through detailed commit messages or annotations in the documentation. 

The main gist is that you must explain why a cherry-pick was necessary. This is particularly important when cherry-picking across long-lived branches or collaborative environments, as it helps future contributors understand why changes were selectively applied.

Review the commit history

Before cherry-picking, review the commit history of both the source and target branches. This step helps identify whether the commit you’re about to cherry-pick depends on other changes. Missing dependencies can result in incomplete functionality or bugs, so ensure the cherry-pick doesn’t introduce half-baked features or updates.

Avoid overuse of cherry-picking

While cherry-picking is convenient for applying specific changes, overusing it can lead to a fragmented history with duplicate commits across branches. This can make it difficult to trace the origin of certain changes or understand the broader development context. 

Always evaluate whether merging or rebasing is a more appropriate strategy before cherry-picking. Use cherry-pick sparingly and purposefully to avoid cluttering the commit history.

Struggling with unnecessary files in Git? Learn how to use .gitignore effectively with this Git ignore tutorial.

Troubleshooting Common Issues with Git Cherry-Pick

Troubleshooting problems that arise when using cherry-pick requires a clear understanding of Git’s underlying mechanisms. In this section, I'll cover some common problems you might encounter while cherry-picking and how to resolve them.

Cherry-picking a commit that doesn’t exist

Sometimes, you may attempt to cherry-pick a commit that isn’t accessible from the current branch or has already been merged. This typically results in an error message stating that the commit couldn’t be found or applied.

1. Commit not found: This happens when the commit hash you’re trying to cherry-pick doesn’t exist in your current repository or branch context. Ensure you’re referencing the correct commit by checking the commit history with git log on the branch where the commit exists. Solution:

• Double-check the commit hash to ensure it’s correct.
• Verify that the commit exists on a branch you have access to.
• If the commit is in a remote branch, ensure the branch has been fetched with git fetch.

2. Commit already applied: If the commit has already been merged or cherry-picked into the target branch, Git will prevent you from duplicating it. This safeguard keeps the history clean and avoids redundant changes. Solution:

• Use git log to check if the commit is already in the target branch.
• If needed, skip the cherry-pick operation since the changes have already been applied.

Cherry-picking after a rebase or a merge

Cherry-picking after a rebase or merge can introduce complexities due to the altered history of your branches. Rebasing rewrites commit histories while merging combines branches, both of which may impact the applicability of a cherry-pick.

1. Conflicts due to rebased commits: After a rebase, the commit history is rewritten, which can cause issues if you attempt to cherry-pick commits that have been altered during the rebase process. You may run into conflicts as the cherry-pick tries to apply changes that don’t align with the rewritten history. Solution:

• Carefully review the commit history after a rebase using git log to ensure the commit you’re cherry-picking hasn’t already been modified.
• Resolve conflicts as you would in a standard cherry-pick process, using git status and manual edits.

2. Duplicate commits after a merge: Merging branches can lead to a situation where a commit you want to cherry-pick has already been included in the merged history. Cherry-picking it again can result in duplicate commits, which can clutter your history and make it difficult to track changes. Solution:

• Before cherry-picking, inspect the commit history on both branches to confirm whether the commit has already been merged.
• Avoid cherry-picking the same commit if it’s already in the target branch.

Need to undo changes in Git? Learn when to use git reset vs. git revert in this Git reset and revert tutorial.

Conclusion

git cherry-pick is a powerful way to apply specific commits from one branch to another without merging the entire branch. Whether you're moving a bug fix, a feature update, or just selectively applying changes, it helps keep your Git history clean and focused.

In this guide, I covered how to cherry-pick single and multiple commits, resolve conflicts, and follow best practices to avoid common pitfalls. By using cherry-pick wisely, you can improve your workflow while keeping your repository organized.

If you're looking to deepen your Git skills, check out Foundations of Git for a strong starting point. You can also explore Introduction to GitHub Concepts or take a structured approach with the GitHub Foundations skill track.

Now that you know how to cherry-pick like a pro, go ahead and try it in your next project!