Git is the ultimate tool for developers. Yet, branching strategies still confuse many of us.
Commands like merge, rebase, and cherry-pick manipulate your commit history in completely different ways. If you just guess what they do, you risk ruining your team's shared history or losing track of your changes.
The easiest way to understand Git is to visualize it. Let us look at exactly what happens to your Git graph when you run these three critical commands.
🏗️ Starting Point: Our Example Repository
Imagine we have a standard repository. We branched off the main branch from commit B to work on a new feature in a feature branch.
While we worked on our feature, someone else pushed commit C and D to main.
Here is what our history looks like right now:
C --- D [main]
/
A --- B
\
E --- F [feature]
- main has two new commits: C and D.
- feature has two new commits: E and F.
🔀 1. Git Merge (The Safe Record Keeper)
When you merge main into your feature branch (or vice versa), Git creates a special, brand-new commit called a merge commit.
git checkout feature
git merge main
The Visual Graph After Merge:
C ------- D ------ [main]
/ \
A --- B \
\ v
E --- F --- G [feature]
What happened under the hood?
Git looked at the common ancestor (B), took the history of main (C and D), took the history of feature (E and F), and combined them. Commit G is the merge commit. It has two parent commits: F and D.
- Pros: 100% non-destructive. It preserves the exact historical timeline of when things actually happened.
- Cons: Your Git graph can quickly become a messy "train track" web if you have many developers merging constantly.
🚀 2. Git Rebase (The Clean History Rewriter)
Rebase takes all the commits from your current branch, lifts them up, and replants them on top of the very last commit of the target branch.
git checkout feature
git rebase main
The Visual Graph After Rebase:
C --- D [main]
/ \
A --- B E' --- F' [feature]
What happened under the hood?
Git temporarily blew away commits E and F. It caught your feature branch up to main's latest commit (D). Then, it applied your changes back on top as brand-new commits (E' and F').
Notice they are named E' and F' now. They have entirely new SHA hashes because their parent commit changed from B to D.
- Pros: Creates a perfectly linear, beautiful history. No messy merge commits.
- Cons: It rewrites history. Never rebase a public branch that other people are actively pulling from. You will break their local repositories.
🍒 3. Git Cherry-Pick (The Surgical Precision Tool)
Sometimes you do not want an entire branch. You just want one specific fix or feature from another branch. Cherry-picking grabs a single commit by its SHA hash and copies it onto your current branch.
Imagine we are back at our starting point, and we only want commit C from main, but we want to ignore commit D.
git checkout feature
git cherry-pick
The Visual Graph After Cherry-Pick:
C --- D [main]
/
A --- B
\
E --- F --- C' [feature]
What happened under the hood?
Git copied the exact code changes introduced in C, generated a brand-new commit (C'), and pasted it right onto the tip of your feature branch.
- Pros: Highly targeted. Great for pulling a critical bug fix into a release branch without pulling unfinished features.
- Cons: It duplicates commits. C and C' contain the exact same changes but live in different places with different hashes.
🧠 Cheat Sheet: When to Use Which?
| Command | Best Use Case | Risk Level | Effect on History |
|---|---|---|---|
| git merge | Merging a completed feature into main. | 🟢 Safe | Preserves actual history; adds a merge commit. |
| git rebase | Updating your local feature branch with upstream changes before making a PR. | 🔴 High | Rewrites history; keeps graph completely linear. |
| git cherry-pick | Grabbing a hotfix from a dev branch straight into production. | 🟡 Medium | Duplicates a single commit onto your current branch. |
The Golden Rule of Git: If your branch is shared with other developers on GitHub, use merge. If the branch exists only on your local computer, use rebase to keep things clean.
Which of these strategies does your team use at work or on open-source projects? Let me know in the comments!
Top comments (0)