DevOps Bootcamp · Lesson

Rebasing vs. Merging

Compare and contrast rebasing and merging, learning when to use each for a clean and linear history.

Rebasing vs. Merging is a free DevOps Bootcamp lesson on CoddyKit — lesson 3 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the DevOps Bootcamp learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

Merge or Rebase? The Choice

When working with Git, you often find your branch diverging from another, like your feature branch from main.

How do you bring those changes together? Git offers two primary strategies: merging and rebasing. Both achieve integration, but they do so in fundamentally different ways, leading to different project histories.

Merging: Combining Histories

Merging is Git's default way to integrate changes. When you merge one branch into another, Git takes the content of the source branch and combines it with the target branch.

The key characteristic of a merge is that it creates a new merge commit. This commit has two parent commits, explicitly showing that two divergent histories were brought together. It preserves the exact history of both branches.

Performing a Git Merge

Let's see a simple merge. We'll create a feature branch, add a commit, and then merge it back into main.

git init my_merge_project
cd my_merge_project
echo "Initial content" > file.txt
git add .
git commit -m "Initial commit"

git branch feature
git checkout feature
echo "Feature A" >> feature.txt
git add .
git commit -m "Add feature A"

git checkout main
echo "Main update" >> main.txt
git add .
git commit -m "Update main"

git merge feature

git log --oneline --graph

Merge: Pros and Cons

Merging is straightforward and safe for shared branches, but can lead to a 'messy' history.

Pros:
Preserves the exact history of commits.
Non-destructive, doesn't rewrite existing commits.
Simple to use and understand.
Cons:
Can create a 'noisy' history with many merge commits.
Graph can look complex with many branches merging in.

Rebasing: Rewriting History

Rebasing is an alternative to merging that integrates changes by moving or combining a sequence of commits to a new base commit. Instead of creating a merge commit, it rewrites the project history.

Essentially, your feature branch's commits are 'replayed' on top of the target branch's latest commit, making it appear as if you started your work from there. This creates a linear history without extra merge commits.

Performing a Git Rebase

Now, let's try the same scenario with rebase. We'll rebase our feature branch onto main.

Notice how the feature branch's commit is re-applied on top of main's latest commit, then a fast-forward merge makes main point to it.

git init my_rebase_project
cd my_rebase_project
echo "Initial content" > file.txt
git add .
git commit -m "Initial commit"

git branch feature
git checkout feature
echo "Feature B" >> feature.txt
git add .
git commit -m "Add feature B"

git checkout main
echo "Main update 2" >> main.txt
git add .
git commit -m "Update main 2"

git checkout feature
git rebase main

git checkout main
git merge feature

git log --oneline --graph

Rebase: Pros and Cons

Rebasing creates a clean history, but comes with a significant warning about shared branches.

Pros:
Creates a clean, linear project history.
Easier to navigate and understand the commit history.
Can clean up (squash, reorder) commits before integrating.
Cons:
Rewrites commit history.
Can be dangerous if used on commits that have already been pushed to a shared (public) remote repository.

Merge vs. Rebase: The Comparison

Here's a quick summary of the core differences:

Merge:
Creates a new merge commit.
Preserves full, exact history.
Non-destructive.
Graph can be complex.
Rebase:
Rewrites history, no merge commit.
Results in a linear history.
Destructive (alters commit IDs).
Graph is very clean.

Choosing Your Strategy

So, when should you use which?

Use Merge when:
Working on public/shared branches (e.g., main, develop).
You need to preserve the exact history of your project.
You want to explicitly show when divergent histories were combined.
Use Rebase when:
Working on your private feature branch before pushing it.
You want a clean, linear history.
You want to tidy up your feature branch commits (e.g., squash, reorder) before integration.

The Golden Rule: Never rebase commits that have already been pushed to a shared remote repository! Rebasing shared history can cause major headaches for collaborators.

Quick Check: Merge or Rebase?

Consider the properties of Git's two main integration strategies.

Recap: Merge vs. Rebase

In this lesson, we explored Git's two fundamental ways to integrate changes: merging and rebasing.

Merging combines histories with a new merge commit, preserving all original commits.
Rebasing rewrites history, creating a linear flow by moving commits.

Choose wisely based on your team's workflow and remember the golden rule: never rebase public history! This understanding is crucial for maintaining a clean and collaborative Git workflow.

Frequently asked questions

Is the “Rebasing vs. Merging” lesson free?

Yes — the full text of “Rebasing vs. Merging” is free to read here on the web, and the DevOps Bootcamp course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the DevOps Bootcamp course, upgrade to CoddyKit PRO.

What will I learn in “Rebasing vs. Merging”?

Compare and contrast rebasing and merging, learning when to use each for a clean and linear history. You practise DevOps Bootcamp with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start DevOps Bootcamp?

No prior experience is required. DevOps Bootcamp on CoddyKit is structured for beginners through advanced learners; this is — lesson 3 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Rebasing vs. Merging” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this DevOps Bootcamp lesson?

Yes. Every DevOps Bootcamp lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

← Back to DevOps Bootcamp