Module 6 Lesson 3: Cherry-picking commits

Sometimes you don't want a whole branch. You just want that one commit.

Maybe a coworker wrote a great helper function on their feature-x branch, but that branch is messy and not ready to merge. Or maybe you fixed a bug on an experimental branch and want to move just that fix to main.

In this lesson, we master git cherry-pick.

---

1. What is Cherry-picking?

Cherry-picking is the act of picking a specific commit from one branch and applying it to your current branch.

• It doesn't move the entire branch.
• it doesn't create a merge commit.
• It creates a new commit on your current branch with the exact same content as the source commit.

graph LR
    subgraph "Feature Branch"
        F1["Fix Typo (SHA: 7f3d)"]
        F2["Half-baked feature"]
    end
    
    subgraph "Main Branch"
        M1["Stable"]
    end
    
    F1 -- "git cherry-pick 7f3d" --> M2["Fix Typo (SHA: 1a2b)"]
    M1 --> M2

---

2. How to Cherry-pick

Step 1: Find the ID

You need the SHA-1 ID of the commit you want. You can find this using git log while looking at the other branch.

Step 2: Switch to Target

Switch to the branch you want to receive the commit (e.g., main).

Step 3: Pick the fruit

git cherry-pick 7f3d9a1

Multiple Cherry-picks

You can pick several commits at once:

git cherry-pick 1a2b3c4 5d6e7f8

---

3. Handling Conflicts

Just like a merge or rebase, cherry-picking can result in conflicts if the code you are "picking" touches lines that have changed on your current branch.

1. Fix the conflict.
2. git add <file>
3. git cherry-pick --continue (or --abort if you change your mind).

---

4. Why Use It? (The Hotfix Scenario)

The most common use for cherry-picking is the Hotfix.

1. You discover a bug in a feature you're building on feature-z.
2. You fix it on feature-z (Commit abc).
3. You realize main needs that fix right now, but feature-z itself is broken.
4. You switch to main, cherry-pick abc, and push to production.
5. You go back to feature-z and keep working.

---

Lesson Exercise

Goal: Granular commit movement.

1. Create a branch experiment.
2. Add a file helper.txt. Commit it.
3. Add another commit to experiment that makes a mess of a different file.
4. Switch back to main.
5. Find the ID of the helper.txt commit.
6. Cherry-pick that ID into main.
7. Verify that helper.txt is now on main, but the "messy" changes from experiment are not.

Observation: You'll see that cherry-picking gives you the ultimate control over what enters your stable history.

---

Summary

In this lesson, we established:

• Cherry-picking applies a single specific commit to your current branch.
• It requires the SHA-1 ID of the source commit.
• It is ideal for grabbing isolated fixes or functions without merging a whole branch.
• It results in a new commit with a new ID.

Next Lesson: If rebase is a linear timeline, and cherry-pick is a single fruit, what if you want to rewrite your entire branch history? Welcome to Lesson 4: Interactive rebase.