Selective Migration: Using TortoiseGit to Cherry-Pick Commits

The Problem: Porting a Single Fix Without a Full Merge

You have a critical bug fix on a development branch, but you cannot merge the entire branch into production because it contains half-finished features and unstable code. Manually copying code blocks is error-prone and loses the commit metadata. You need a way to isolate a specific change and apply it to your current branch without bringing along the surrounding noise.

The solution is cherry-picking. In Git, this is the process of selecting a specific commit by its SHA-1 hash and applying those exact changes to your current HEAD. While the command line is powerful, TortoiseGit provides a visual way to identify and migrate these commits through the Windows Shell extension, reducing the risk of picking the wrong hash from a long terminal list.

Visual Identification via the Log

The primary advantage of using TortoiseGit for this task is the Show Log dialog. Instead of scrolling through git log, you can visually navigate the commit graph to find the exact point where a fix was implemented.

When you open the log, you can filter by branch or author to isolate the target commit. Because TortoiseGit displays the commit graph, you can see the relationship between the commit you want and the branch it originated from, ensuring you aren't accidentally picking a commit that depends on other un-ported changes.

Executing the Cherry-Pick

To move a commit from one branch to another using TortoiseGit, follow this workflow:

1. Switch Branches: Ensure you have checked out the target branch (e.g., main or production) where the fix needs to land.
2. Open Log: Right-click your project folder and select TortoiseGit > Show Log.
3. Locate Commit: Use the branch dropdown in the log window to select the source branch (e.g., develop). Find the specific commit containing the fix.
4. Apply: Right-click the desired commit and select Cherry-pick.

Handling Conflicts

If the code surrounding the fix has diverged significantly between branches, Git will trigger a merge conflict. TortoiseGit will pause the operation and launch the Merge Tool. You must resolve the conflicts manually, mark them as resolved, and then commit the result to complete the cherry-pick process.

Worked Example: Porting a Hotfix

Consider a scenario where a security patch was committed to feature-auth but must be applied to stable-v1 immediately.

Step	Action	Expected Result
1	Checkout stable-v1	Working directory reflects production state.
2	Open Log > Select feature-auth	Log shows commits from the auth branch.
3	Right-click commit a1b2c3d > Cherry-pick	Changes from a1b2c3d are staged to stable-v1.
4	Verify via git log or TortoiseGit Log	A new commit exists with a different hash but identical content.

Trade-offs and Limitations

While convenient, cherry-picking is not a substitute for a proper merge strategy. The most significant limitation is commit duplication. When you cherry-pick, Git creates a brand new commit object with a new SHA-1 hash, even though the content is the same.

If you later merge the source branch into the target branch, Git is usually smart enough to recognize the identical changes, but in complex histories, this can lead to redundant conflict resolutions. Additionally, because TortoiseGit relies on the Windows Explorer shell, this workflow is strictly limited to Windows environments.

Verifying the Result

To ensure the cherry-pick was successful without introducing regressions, run the following check in your terminal or via the TortoiseGit log:

# Run from the target branch directory
git log -n 5

Check that the most recent commit message matches the one you picked. To verify the actual code change, use TortoiseGit > Diff on the new commit to ensure only the intended lines were modified.