Phase 1: Programming & Fundamentals

Interactive rebase, cherry-pick & bisect

Beginner ~3 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you're building a super cool LEGO castle. You start by adding some walls, then a small tower, then maybe you try out a tricky roof design that doesn't quite work, so you take it apart and try again. You make lots of little changes and additions as you go. Each time you add a main section or fix something, it's like writing a note in your special building diary: "Added front door," "Fixed wobbly tower," "Experimented with roof." This diary becomes the "story" of how you built your castle.

Now, before you show off your amazing castle to your friends, you want your building story to look really neat and clear, right? You don't want them to read about all the times you experimented and messed up. This is where a powerful tool comes in, like having a magical eraser and pencil for your diary. You can go back and tidy up your notes. Maybe you wrote "Added a small brick," "Added another brick," "Added a third brick." You can change those three tiny notes into one clear note: "Built the whole wall!" Or maybe you accidentally wrote about the tower before the main gate; you can swap their order to make more sense. This helps keep your building story clean, easy to follow, and makes it look like you built it perfectly from the start!

Sometimes, while you're building your castle, you might see your friend building an awesome LEGO spaceship, and they've made a really cool engine design. You don't want to copy their whole spaceship, but you do want that specific engine design for your own castle, perhaps as a special flying turret! Instead of building it from scratch or trying to remember all their steps, you can just "cherry-pick" that one amazing engine part from their building diary and add it directly to your own castle's diary. It’s like taking a single page from their instruction book and copying it into yours to make your castle even cooler.

Finally, imagine your castle used to be perfect, but now one of the walls keeps falling down, and you can't remember when you added a wobbly piece. You’ve added so many pieces since it was last stable! Instead of checking every single piece you added, one by one, you can use a clever trick called "bisect." You look at your building diary and divide all your steps in half. Was the wall wobbly before this halfway point, or after? Once you narrow it down, you cut that section in half again. You keep doing this until you pinpoint the exact building step—the exact piece you added—that caused the problem. This means you can find and fix mistakes super fast, so your castle stands strong and amazing for everyone to see!

As a backend developer, maintaining a clean and understandable Git history is crucial, especially before your code gets reviewed or merged. Interactive Rebase (git rebase -i) is your powerful tool for rewriting local commit history. Imagine you've made several small, exploratory commits while working on a feature – some fixes, some experimental changes. Before pushing, you can use interactive rebase to squash these into fewer, more meaningful commits, reorder them, or even edit commit messages. This process cleans up your timeline, making your branch's history linear, easy to read, and much simpler for others to understand and review.

Sometimes, you don't need to merge an entire branch, but you do need a specific change from one branch applied to another. This is where Cherry-pick (git cherry-pick <commit-hash>) comes in handy. It allows you to take a single commit from anywhere in your repository's history and apply it directly onto your current branch, creating a new commit with the same changes. This is incredibly useful for situations like backporting a hotfix from a release branch to main, or quickly grabbing a critical bug fix from a colleague's ongoing feature branch without pulling in all their other work.

Debugging can be a time-consuming task, especially when a bug suddenly appears, and you're unsure which recent change introduced it. Git Bisect (git bisect) automates the process of finding the exact commit that introduced a bug. You start by telling Git a 'good' commit (where the bug wasn't present) and a 'bad' commit (where it is). Git then performs a binary search, checking out commits in the middle and asking you to mark them as 'good' or 'bad'. By repeating this, Git quickly narrows down and identifies the first problematic commit, saving you hours of manual investigation.

Key Takeaways

  • git rebase -i cleans up your local commit history before sharing, making it clear and linear.
  • git cherry-pick applies a single, specific commit from one branch to another, useful for targeted fixes or changes.
  • git bisect efficiently finds the exact commit that introduced a bug by automating a binary search.
  • Mastering these tools leads to a cleaner codebase, faster debugging, and more efficient collaboration.

Code Example

bash
# Imagine you have a branch 'feature-x' and 'main'.
# A critical fix (commit 'abc1234') was made on 'feature-x'
# and you need it on 'main' *now*, without merging 'feature-x' fully.

git checkout main              # Switch to the branch where you need the commit
git cherry-pick abc1234        # Apply commit 'abc1234' from 'feature-x' to 'main'

How this code works

This code snippet illustrates how to quickly bring a crucial fix from one development branch, such as feature-x, directly into the stable main branch without needing to merge the entire feature-x branch. This technique is invaluable for deploying urgent bug fixes or small, independent improvements that can't wait for a full feature release, allowing for targeted updates to be applied with precision.

The process begins with git checkout main, which switches the active working directory to the main branch, ensuring that subsequent operations affect it. Following this, the git cherry-pick abc1234 command is executed. This command takes the changes introduced by the specified commit ID (abc1234) from its original branch and reapplies them as a brand new commit directly onto main. A subtle point for beginners is understanding that cherry-pick doesn't move the original commit; instead, it creates a duplicate of its changes. This new commit on main will have a different commit ID from the original abc1234, effectively copying the fix rather than linking directly to the original.

Resources

Related Articles

Hand-picked reads to go deeper on git & version control.

Back to Backend Developer Roadmap