Merge vs Rebase in Git : Which to Choose and When

Hello! I'm Anas , a DevOps and Cloud enthusiast with a passion for building scalable, efficient, and secure infrastructure. With a strong focus on automation, containerization, and orchestration, In this blog I'll be diving into the git branching in detail.

When working with Git, managing branches is an essential part of the development process.

Two common methods of integrating changes from one branch to another are merging and rebasing. In this post, we'll explore the differences between these two approaches using a practical example.

Creating a New Branch

 git checkout -b dev
Switched to a new branch 'dev'

We can verify that we're now on the dev branch by running git branch:

git branch
* dev
 main

the dev branch by creating a new file 2.txt and committing it:

echo > 2.txt
git add .
git commit -m "Adity added new files"
output:
[dev 7c72071] Adity added new files
 1 file changed, 1 insertion(+)

merge the changes from the dev branch into the main branch:

git checkout main
Switched to branch 'main'
git merge dev

output:
Updating d11083c..7c72071
Fast-forward
1 file changed, 1 insertion(+)

The merge is successful, and we can see the updated commit history:

f708885  Merge branch 'dev' -> it maintain history some merge has taken place this commit is extra added but not in rebase.
7c72071 (HEAD -> main, dev) Adity added new files
d11083c my first commit

Notice that the merge commit is not explicitly shown in the log. Instead, the commit history appears not linear

Rebasing Changes into Main Branch

Let's create another file 3.txt on the dev branch and commit it:

echo > 3.txt
git add .
git commit -m "Added 3.txt"
output:

e177660 (HEAD -> dev) Added 3.txt
7c72071 (main) Adity added new files
d11083c my first commit

Now, let's rebase the main branch onto the dev branch

git checkout main
Switched to branch 'main'
git rebase dev
output:

Successfully rebased and updated refs/heads/main

The rebase is successful, and we can see the updated commit history:

e177660 (HEAD -> main, dev) Added 3.txt
7c72071 Adity added new files
d11083c my first commit

notice, Rebase is linear, it reapplies the commits from one branch onto another.

• Merge is not linear, it preserves the branch structure and commit history.

• Rebase is linear, it creates a linear commit history, but loses the original branch structure and commit history.

• Here's a simple illustration to help you visualize the difference:

•     A -- B -- C   (main)
       \
        D -- E -- F   (dev)
  

  After merge:

•     A -- B -- C -- G   (main)
       \       /
        D -- E -- F   (dev)
  

  a new merge commit G is created

Rebase

A -- B -- C   (main)
 \
  D -- E -- F   (dev)

After rebase:

A -- B -- C -- D -- E -- F   (main)

Why use git merge?

1. Preserves commit history: git merge preserves the commit history, including the original branch structure and commit messages.

2. Easy to revert: If something goes wrong, you can easily revert the merge commit and go back to the previous state.

3. Non-destructive: git merge doesn't rewrite the commit history, so it's safe to use even on public branches.

Why use git rebase?

1. Linear commit history: git rebase creates a linear commit history, which can be easier to read and understand.

2. Simplifies commit history: By reapplying commits, git rebase can simplify the commit history and eliminate unnecessary merge commits.

3. Useful for local branches: git rebase is useful for local branches, where you want to clean up your commit history before pushing changes to a remote repository.

When to use git rebase?

1. Local branches: Use git rebase on local branches to clean up your commit history before pushing changes to a remote repository.

2. Private branches: Use git rebase on private branches, where you're the only one working on the branch.

3. Before pushing: Use git rebase before pushing changes to a remote repository to ensure a clean, linear commit history.

When to use git merge?

1. Public branches: Use git merge on public branches, where multiple developers are working on the same branch.

2. Collaborative workflows: Use git merge in collaborative workflows, where you want to preserve the commit history and branch structure.

3. After pushing: Use git merge after pushing changes to a remote repository to ensure that the commit history is preserved.

Conclusion

Git Merge:

• Preserves commit history and branch structure

• Easy to revert

• Non-destructive

• Suitable for public branches and collaborative workflows

  Git Rebase:

  • Creates a linear commit history

  • Simplifies commit history

  • Useful for local branches and private workflows

  • Can be destructive, so use with caution

Happy learning!!