What is git rebase?

The git rebase command is used to move or replay a sequence of commits onto a new base commit. It helps maintain a clean, linear Git history by applying your branch's commits on top of another branch.

Unlike git merge, which creates a merge commit, git rebase rewrites commit history by replaying commits one by one onto the target branch.

Interview Answer

"I use git rebase to keep my branch history clean and linear. Instead of creating unnecessary merge commits, rebase reapplies my commits on top of the latest base branch, making the project history easier to understand and simplifying code reviews. Since rebase rewrites commit history, I use it only on local or private feature branches."

Advertisement

Basic Syntax

git rebase main

This command replays the current branch's commits on top of the latest main branch.

How git rebase Works

Before Rebase

main
A──B──C

feature
     \
      D──E


After Rebase

main
A──B──C

feature
         \
          D'──E'

The commits D and E are replayed as new commits (D' and E') on top of main.

Why Use git rebase?

Rebasing provides several benefits:

• Creates a clean, linear commit history
• Eliminates unnecessary merge commits
• Makes code reviews easier
• Simplifies project history
• Keeps feature branches up to date

Real-Time Example

Before raising a Pull Request, I usually rebase my feature branch with the latest main branch. This ensures my branch contains the latest changes and avoids unnecessary merge commits, making the review process cleaner.

git rebase vs git merge

Both commands integrate changes from one branch into another, but they do so differently.

Comparison

Visual Comparison

Using Merge

main
A──B──C────────M
     \        /
      D──────E

A merge commit (M) preserves the branching history.

Using Rebase

main
A──B──C──D'──E'

The history becomes linear with no merge commit.

Best Practice

• Use git rebase for local or private feature branches.
• Use git merge for shared branches where preserving history is important.

Real-Time Example

During feature development, I regularly rebase my local branch with the latest main branch. However, after the branch is shared with the team, I avoid rebasing and use merge instead to prevent rewriting shared history.

When Not to Use git rebase

Although rebasing is powerful, there are situations where it should be avoided.

Do Not Rebase

Avoid rebasing:

• Public branches
• Shared branches
• Branches already pushed to remote
• Commits that other developers depend on
• When preserving original commit history is important

Why?

Rebasing rewrites commit hashes.

This may:

• Break other developers' branches
• Cause merge conflicts
• Create duplicate commits
• Confuse project history

Interview Answer

"I never rebase commits that have already been shared with other developers because rebasing rewrites commit history. For shared branches like main or develop, I prefer merge to avoid disrupting the team's workflow."

Best Practices

• Rebase only local commits.
• Never rebase shared history.
• Coordinate with teammates before rewriting history.

Interactive Rebase (git rebase -i)

Interactive Rebase allows you to edit, reorder, squash, combine, or remove commits before sharing your work.

It is one of Git's most powerful history-cleaning features.

Syntax

git rebase -i HEAD~5

This opens the last 5 commits in an editor.

Example

pick 123abc Add Login API

pick 456def Fix typo

pick 789xyz Update validation

Available Commands

Interactive Rebase Workflow

Recent Commits
       │
       ▼
Interactive Rebase
       │
       ▼
Edit
Reorder
Squash
Drop
       │
       ▼
Clean Commit History

Real-Time Example

Before submitting my feature branch for review, I use interactive rebase to squash work-in-progress commits, remove unnecessary commits, and improve commit messages so the Git history remains clean and meaningful.

Squashing Commits

Squashing combines multiple commits into a single meaningful commit.

This produces a cleaner project history.

Interview Answer

"Before merging my feature branch, I usually squash multiple work-in-progress commits into one meaningful commit. This keeps the main branch history clean and simplifies code reviews."

Before Squashing

Fix typo

Update API

Testing

Final changes

After Squashing

Implement User Authentication Feature

Benefits

• Cleaner history
• Easier reviews
• Better debugging
• Removes unnecessary commits
• More meaningful project history

Cherry-Picking

Cherry-picking copies a single commit from one branch and applies it to another branch without merging the entire branch.

Interview Answer

"Cherry-picking allows me to apply a specific commit from one branch to another without merging the entire branch. I commonly use it for production hotfixes and backporting bug fixes."

Workflow

Step 1: Find the Commit

git log

Step 2: Switch Branch

git checkout <target-branch>

Step 3: Cherry-Pick

git cherry-pick <commit-hash>

Cherry-Pick Workflow

Feature Branch
      │
Specific Commit
      │
      ▼
Cherry-Pick
      │
      ▼
Target Branch

Common Uses

• Production hotfixes
• Backporting bug fixes
• Copying individual commits
• Applying urgent fixes to release branches

Note

Cherry-picking creates a new commit with a different commit hash while preserving the original changes.

git bisect: Finding the Buggy Commit

git bisect helps locate the exact commit that introduced a bug using binary search.

Instead of checking every commit manually, Git repeatedly narrows the search range until it identifies the problematic commit.

Interview Answer

"I use git bisect when a bug appears after several commits. By marking one known good commit and one bad commit, Git performs a binary search to quickly identify the commit that introduced the issue."

Basic Workflow

Start bisect:

git bisect start

Mark current commit as bad:

git bisect bad

Mark a known good commit:

git bisect good <commit-hash>

Git checks out a middle commit.

Test it.

If the bug is absent:

git bisect good

If the bug exists:

git bisect bad

Repeat until Git identifies the first bad commit.

Finish:

git bisect reset

Bisect Workflow

Known Good Commit
        │
        ▼
Known Bad Commit
        │
        ▼
Binary Search
        │
        ▼
Test Commit
        │
 ┌──────┴──────┐
 │             │
Good         Bad
 │             │
 └──────┬──────┘
        ▼
First Bad Commit Found

Benefits

• Quickly finds the buggy commit
• Saves debugging time
• Uses efficient binary search
• Ideal for reproducible bugs

Handling Hotfixes in Production

Production hotfixes should be handled separately from ongoing feature development.

A dedicated hotfix branch ensures minimal risk while resolving production issues quickly.

Interview Answer

"When a production issue occurs, I create a dedicated hotfix branch from the production branch, implement the minimal required fix, test it thoroughly, merge it back into production, and then merge or cherry-pick the same fix into the development branch so all branches remain synchronized."

Typical Hotfix Workflow

Production Branch
        │
        ▼
Create Hotfix Branch
        │
        ▼
Implement Fix
        │
        ▼
Testing
        │
        ▼
Merge into Production
        │
        ▼
Merge/Cherry-Pick into Develop

Benefits

• Fast production recovery
• Isolated fixes
• Reduced deployment risk
• Better traceability
• Synchronizes all active branches

Real-Time Example

During one release, a payment issue was discovered in production. We created a dedicated hotfix branch from the production branch, implemented the fix, tested it, merged it back into production, and then cherry-picked the same commit into the development branch to ensure future releases included the fix.

Frequently Asked Questions (FAQs)

1. What is git rebase?

git rebase moves or reapplies commits from one branch onto another base commit, creating a clean and linear commit history without unnecessary merge commits.

2. What is the difference between git rebase and git merge?

git merge combines branches by creating a merge commit while preserving the complete branch history.

git rebase reapplies commits onto another branch, producing a linear history by rewriting commit hashes.

3. When should you not use git rebase?

Avoid using git rebase:

• On public or shared branches
• After commits have been pushed to a shared repository
• When preserving the original commit history is important

Rebasing shared commits can create conflicts and confusion for other developers.

4. What is Interactive Rebase?

Interactive Rebase (git rebase -i) allows you to:

• Reword commit messages
• Edit commits
• Squash commits
• Fix up commits
• Reorder commits
• Remove unnecessary commits

It is commonly used to create a clean commit history before pushing code.

5. What is Cherry-Picking?

Cherry-picking copies a specific commit from one branch to another without merging the entire branch.

It is commonly used for:

• Production hotfixes
• Backporting bug fixes
• Applying individual commits to release branches

Example:

git cherry-pick <commit-hash>

6. How does git bisect find a bug?

git bisect performs a binary search through the commit history.

You mark:

• A known good commit
• A known bad commit

Git repeatedly checks out commits between them until it identifies the exact commit that introduced the bug.

7. How do you handle hotfixes in production?

A typical production hotfix workflow is:

1. Create a hotfix branch from the production branch.
2. Implement the minimal required fix.
3. Test the fix thoroughly.
4. Merge the hotfix back into production.
5. Merge or cherry-pick the same fix into development or release branches.
6. Deploy the updated production branch.

This approach minimizes downtime while ensuring all active branches remain synchronized.