`git merge` vs `git rebase`, and what `stash` and `cherry-pick` do

• git merge -- integrates one branch into another by creating a new merge commit with two parents, preserving the true branching history.
• git rebase -- integrates by replaying commits one at a time onto a new base, producing new commits and a clean linear history.
• Merge commit -- a special commit with two parents that records where two lines of work joined.
• git stash -- temporarily shelves uncommitted changes (staged and unstaged) so your working tree is clean.
• git stash pop -- reapplies the most recently stashed changes and removes them from the stash stack.
• git cherry-pick -- copies one specific commit from any branch and applies it as a new commit on your current branch.

How does git merge work?

Merge brings branches together by creating a merge commit with two parents -- the tip of your branch and the tip of the branch you merged in. Nothing is rewritten. All original commits keep their hashes. The graph honestly shows that two lines diverged and joined.

# Merge main into feature branch
git checkout feature/emi-calculation
git merge main

# Before merge:
# main:    A -- B -- C
# feature:      \-- D -- E

# After merge:
# main:    A -- B -- C
# feature:      \-- D -- E -- M (merge commit, parents: E and C)

git log --oneline --graph

*   f4e5d6 Merge branch 'main' into feature/emi-calculation
|\  
| * c3d4e5 fix: correct rounding in fee calculation
* | b2c3d4 feat: add EMI edge case test
* | a1b2c3 feat: add EMI calculation
|/
* 901234 initial commit

How does git rebase work?

Rebase takes your commits, sets them aside, fast-forwards to the tip of the target, and replays your commits on top one at a time. The result is a straight line with no merge commits. The commits get new hashes because their parent changed.

# Rebase feature onto main
git checkout feature/emi-calculation
git rebase main

# Before rebase:
# main:    A -- B -- C
# feature:      \-- D -- E

# After rebase:
# main:    A -- B -- C -- D' -- E'
# D' and E' are NEW commits

git log --oneline --graph

* e6f7g8 feat: add EMI edge case test
* d5e6f7 feat: add EMI calculation
* c3d4e5 fix: correct rounding in fee calculation
* 901234 initial commit

When should you use merge vs rebase?

Merge is safe for shared branches because it does not rewrite history. Rebase is for private branches where you want a clean linear history. The rule: rebase private branches, merge shared branches.

| Scenario | Use Merge | Use Rebase |
|---|---|---|
| Integrating feature into main | Merge (or squash-merge) | -- |
| Updating private feature from main | Either | Rebase (cleaner) |
| Shared branch others have pulled | Merge always | Never rebase |
| Cleaning up local commits | -- | Interactive rebase |

package com.bank.loans;

import java.math.BigDecimal;
import java.math.RoundingMode;

/**
 * This class was developed on a feature branch.
 * Rajesh rebased it onto main for clean history,
 * then merged to main with a squash-merge.
 */
public class EmiCalculator {

    public BigDecimal calculate(
            BigDecimal principal, BigDecimal rate, int months) {
        BigDecimal r = rate.divide(
            BigDecimal.valueOf(1200), 10, RoundingMode.HALF_UP);
        BigDecimal factor = BigDecimal.ONE.add(r).pow(months);
        return principal.multiply(r).multiply(factor)
            .divide(factor.subtract(BigDecimal.ONE),
                2, RoundingMode.HALF_UP);
    }
}

EMI for principal=1000000, rate=8.5%, months=240
Result: 8678.23

How does git stash work?

Stash shelves all uncommitted changes -- both staged and unstaged -- saves them on a stack, and reverts your working directory to the last commit. You handle the urgent task, then pop to get your changes back.

# Rajesh is halfway through EMI changes when a production alert fires
git stash push -m "WIP: emi calculation refactor"

Saved working directory and index state On feature/emi-calculation:
  WIP: emi calculation refactor

# Switch to fix the production issue
git checkout main
git checkout -b hotfix/transfer-timeout
# ... fix the issue, commit, push, PR ...

# Come back and restore the shelved work
git checkout feature/emi-calculation
git stash pop

On branch feature/emi-calculation
Changes not staged for commit:
  modified:   src/main/java/com/bank/loans/EmiCalculator.java
Dropped refs/stash@{0} (abc1234)

# List all stashes
git stash list

stash@{0}: On feature/emi-calculation: WIP: emi calculation refactor
stash@{1}: On feature/sip-returns: WIP: return percentage formula

How does git cherry-pick work?

Cherry-pick takes one commit by its hash and applies the same change as a new commit on your current branch. It does not bring the whole branch -- it copies one specific commit. The classic use is applying a hotfix to multiple branches.

# A hotfix was committed on the release branch
git log release/2.4 --oneline -1

abc1234 hotfix: prevent transfer double-counting

# Cherry-pick that one fix onto main
git checkout main
git cherry-pick abc1234

[main def5678] hotfix: prevent transfer double-counting
 1 file changed, 5 insertions(+)

The new commit (def5678) has a different hash because its parent differs. The change is the same, but the commit is a distinct object.

What are common mistakes?

Overusing cherry-pick across long-lived branches leads to duplicated commits. Using rebase on shared branches causes history divergence. Using stash as a long-term storage instead of committing or branching.

# WRONG -- cherry-picking the same fix into 5 branches
# Creates 5 duplicate commits, confusing git blame

# CORRECT -- cherry-pick for targeted hotfix propagation only
git checkout main
git cherry-pick abc1234
# Then let normal merge flow propagate to other branches

What are common interview follow-up questions?

• What is interactive rebase and when would you use it?
• How do you resolve a rebase conflict versus a merge conflict?
• What is the difference between git stash pop and git stash apply?
• How does git reflog help recover from a bad rebase?

What should a senior engineer know?

A senior engineer uses all four tools appropriately: rebase for clean personal history, merge for integrating shared work honestly, stash as a quick temporary shelf (not long-term), and cherry-pick as a scalpel for one-off hotfix propagation. They know that merge preserves the audit trail auditors require, while rebase makes personal branch history reviewable.