DevOps · Git

Git Merge and Rebase

Merge and rebase both combine work from two branches. They differ in the history they leave behind.

Beginner 5 min Lesson 7 of 30
Before you start:Branching Strategies
0/30 in DevOps
On this page · 5 min · Beginner

Learning objectives#

  • Merge a branch and understand fast-forward
  • Rebase a feature branch onto main
  • Resolve merge conflicts
  • Know when not to rebase

Explanation#

git merge joins histories. If main has not moved, it fast-forwards; otherwise it creates a merge commit with two parents.

git rebase replays your commits on top of the latest main, producing a straight line of history — but it rewrites commit hashes.

Golden rule: never rebase commits that others have already pulled (shared branches). Rebase your own local work freely.

Conflicts happen when both sides changed the same lines. Edit the file, keep the right code, git add it and continue.

Code example: Updating a feature branch and resolving a conflict#

ShellUpdating a feature branch and resolving a conflict Illustrative
git switch feature/product-search
git fetch origin
git rebase origin/main
# CONFLICT (content): Merge conflict in src/ProductsController.cs


# Open the file, choose the correct lines between <<<<<<< ======= >>>>>>>, then:
git add src/ProductsController.cs
git rebase --continue


git push --force-with-lease     # safe force-push for your own branch


# Alternative without rewriting history:
# git merge origin/main
Expected output
The feature branch now sits on top of the latest main with a linear history, ready for a clean PR.

This example is illustrative. Copy or download it and run it in your own environment; the expected output is shown above.

Step-by-step explanation#

  1. fetch downloads the latest main.
  2. rebase replays the feature commits on top of it.
  3. Conflicts are fixed by editing, adding and continuing.
  4. --force-with-lease refuses to overwrite someone else’s new commits.

Real-world use case#

Before requesting review, a developer rebases on main so reviewers see only their changes and CI tests the latest code.

Common mistakes#

Rebasing main or a shared branch

Everyone else’s history breaks. Only rebase your own branches.

git push --force

Can delete teammates’ commits. Use --force-with-lease.

Best practices#

  • Rebase local feature branches; merge shared ones
  • Pull often to keep conflicts small
  • Use --force-with-lease
  • Run tests after resolving conflicts

Remember this#

Merge = join histories. Rebase = replay on top.

Never rebase shared history.

Conflict: edit → add → continue.

Practice exercise#

Your task: Abort a rebase that went wrong.

Show solution
Shell Illustrative
git rebase --abort

Mini quiz#

Git Merge and Rebase quizMultiple choice Question 1 of 1

What is the golden rule of rebasing?

Score so far: 0/0

Want more? Practise all DevOps MCQs · DevOps interview questions

My notes#

Saved in this browser.

Progress is saved in this browser. Sign in to sync.