Skip to content

DevOps Day 28: Targeted Code Integration with git cherry-pick

Today's task was a fantastic lesson in a more advanced, surgical Git technique: git cherry-pick. The scenario was incredibly realistic: a developer was working on a large, unfinished feature but had made one specific, valuable commit that needed to be brought into the main codebase immediately.

This taught me that merging isn't an all-or-nothing operation. Git provides powerful tools to select individual changes and apply them where needed. I learned how to identify a specific commit by its hash and use cherry-pick to copy it to another branch. This document is my detailed, first-person account of that entire process, including why this is the correct tool for the job.

Table of Contents

The Task

My objective was to take a single, specific commit from a work-in-progress feature branch and apply it to the stable master branch. The requirements were: 1. Work within the /usr/src/kodekloudrepos/apps repository on the Storage Server. 2. The commit to be moved was identified by its commit message: Update info.txt. 3. The change needed to be applied to the master branch. 4. The updated master branch had to be pushed to the remote server.

My Step-by-Step Solution

The process required careful investigation to find the right commit, followed by the precise application of the cherry-pick command. As the repository was in a root-owned directory, every command required sudo.

Phase 1: Investigation and Preparation

  1. I connected to the Storage Server (ssh natasha@ststor01) and navigated to the repository (cd /usr/src/kodekloudrepos/apps).
  2. Crucially, I first switched to my target branch. I needed to be on master before I could apply any changes to it. 
    sudo git checkout master
  3. Next, I needed to find the unique hash (the ID) of the commit I wanted to pick. I did this by looking at the log of the source branch (feature). 
    sudo git log feature --oneline
    In the output, I found the line a1b2c3d Update info.txt and copied the hash a1b2c3d.

Phase 2: The Cherry-Pick and Push

  1. With the hash in hand and my current branch set to master, I executed the main command. 

    # I used the actual hash from my 'git log' command
sudo git cherry-pick a1b2c3d
    This command took the changes from that one commit and created a brand-new commit on master containing those same changes.

  2. Finally, I pushed my updated master branch to the central server. 

    sudo git push origin master

Phase 3: Verification

The final step was to confirm the change was correctly applied to the master branch. 1. I ran git log --oneline again, this time on the master branch. 2. The output showed a new commit at the very top with the message "Update info.txt". This new commit had a different hash than the original on the feature branch, but it contained the exact same code changes. This was the definitive proof of success.

Why Did I Do This? (The "What & Why")

- git cherry-pick: This is the key command for this task. It allows you to select a single commit from anywhere in your repository's history and apply it as a new commit on top of your current branch. It's a surgical tool for moving specific changes around. - Why Not Merge?: The task stated that the feature branch was still a "work in progress." If I had run git merge feature, it would have brought all the commits from the feature branch into master, including the unfinished, potentially broken code. This would have destabilized the main branch. - Real-World Use Cases: - Hotfixes: This is the classic example. A developer is working on a big feature and, in the process, fixes a critical production bug. I can use cherry-pick to grab only the bug fix commit and apply it to master for an emergency release, without having to merge the entire unfinished feature. - Backporting: If I find a bug in version 2.0 of my software, I can fix it and then cherry-pick that fix commit back to the v1.0-maintenance branch to support older versions. - Selective Feature Release: As in this task, sometimes a small, complete part of a larger feature is ready to be released early.

Deep Dive: The Power of git cherry-pick vs. git merge

This task perfectly illustrated the difference between these two powerful Git commands.

[Image of a git cherry-pick diagram]

  • git merge feature (The Sledgehammer):

    • What it does: Takes the entire history of the feature branch and integrates it into master.
    • Result: The master branch now contains every single commit from the feature branch. It's an all-or-nothing operation.

  • git cherry-pick <hash> (The Scalpel):

    • What it does: Looks at the changes introduced by a single commit (identified by its hash) and applies just those changes to the current branch.
    • Result: A new commit is created on master. This new commit has a different hash but contains the exact same code changes and commit message as the original commit from the feature branch. This is surgical and precise.

My Key Takeaway: merge is for when an entire feature is complete. cherry-pick is for when you need a specific, isolated change from another line of development.

Common Pitfalls

- Cherry-picking onto the Wrong Branch: The most critical mistake would be to forget to git checkout master first. If I had stayed on the feature branch and cherry-picked a commit from it, I would have just created a duplicate commit on the same branch, which is pointless. - Merge Conflicts: If the changes in the cherry-picked commit conflict with changes that already exist on the master branch, Git will stop and force me to resolve the conflict manually before the new commit can be created. - Forgetting sudo: In this specific lab environment, the repository's location in /usr/src meant it was owned by root. Forgetting sudo for any command that writes to the repository (checkout, cherry-pick, push) would have resulted in a "Permission denied" error. - Missing git config: If my user name and email were not configured, the cherry-pick command (which creates a new commit) would have failed and asked me to identify myself first.

Exploring the Commands I Used

- sudo git checkout master: The command to switch my working directory to the master branch. This was the essential first step. - sudo git log feature --oneline: A command to view the commit history. - log feature: Tells Git to show me the log for the feature branch specifically, even though I'm currently on master. - --oneline: A very useful flag that condenses the output to show each commit on a single line, making it easy to find the message and its hash. - sudo git cherry-pick a1b2c3d: The main command of the task. It takes the changes from the commit with the specified hash and applies them as a new commit on the current branch. - sudo git push origin master: The standard command to push the updated state of my local master branch to the remote server named origin.