Git is a powerful version control system that allows developers to efficiently manage and collaborate on projects. Two common Git operations for integrating changes from one branch into another are git merge and git rebase. While both serve a similar purpose, they have distinct differences in how they work and when to use them. In this article, we will explore the differences between git merge and git rebase with detailed examples and explanations.

Git Merge

git merge is a Git command used to combine changes from one branch into another. It creates a new commit that incorporates the changes from the source branch (often referred to as the “feature branch”) into the target branch (usually the “main” or “master” branch). The result is a commit history that includes a merge commit, indicating when and where the integration occurred.

After you create new branch, you should have some new commits on the new branch(Ex: Dev branch) and the old branch (Ex: main) separately. Only then you can see the new merge commit when you use git merge. If you create a new branch, it will have all old commits. If you only add new commits to the new branch, and merge, you will see them in the old branch but you won’t see a new commit. In order to see the new commit, after you create new branch, you should have different commits on new branch and old branch.

Syntax:

1

git merge <source-branch>

How Git Merge Works:

1. Checkout the Target Branch: First, you need to be on the target branch where you want to merge the changes. You can do this using git checkout <target-branch>.

2. Run the Merge Command: Next, you run git merge <source-branch>, where <source-branch> is the branch you want to merge into the target branch.

3. Conflict Resolution: If there are any conflicts between the changes in the source and target branches, Git will pause the merge process, and you’ll need to resolve these conflicts manually. Once conflicts are resolved, you can continue the merge.

4. Commit Merge: Git creates a new merge commit that records the fact that a merge took place. This commit has two parent commits, one from the target branch and one from the source branch, indicating the merge relationship.

When to Use Git Merge:

Use git merge when you want to maintain a clear and accurate history of when branches were merged. This is especially useful for shared or public repositories, as it provides a transparent record of changes. On the other hand, if you have too many commits on feature branch and master branch, everytime when you use git merge, you will have too many commits as git merge will maintain all the commits. If you want to maintain clean commit history, you should use git rebase as explained below.

Git Rebase

git rebase is another Git command used for integrating changes from one branch into another, but it works differently from git merge. Instead of creating a new merge commit, git rebase rewrites the commit history to appear as though the changes from the source branch were made directly on top of the target branch. This results in a linear commit history, free of merge commits.

Syntax:

1

git rebase <target-branch>

How Git Rebase Works:

1. Checkout the Source Branch: Start by being on the source branch that you want to rebase onto the target branch. You can do this using git checkout <source-branch>.

2. Run the Rebase Command: Then, run git rebase <target-branch>, where <target-branch> is the branch you want to rebase onto.

3. Resolve Conflicts: Like with merging, conflicts may arise during the rebase process, and you’ll need to resolve them. Once resolved, continue the rebase.

4. Reapply Commits: Git will reapply each commit from the source branch onto the target branch one by one, effectively “moving” them to the tip of the target branch.

When to Use Git Rebase:

Use git rebase when you want to maintain a cleaner and more linear commit history. This is particularly helpful in feature branches where you want to ensure that each commit is atomic and meaningful. It is also useful for keeping the main branch clean and free of unnecessary merge commits.

Do not use git rebase in public repositories because git rebase creates a linear commit. So, you might be working off of the latest commit but all your colleagues will work on original master branch. Also, when multiple people are working on a repository do not use git rebase on that repo.

Check merging-vs-rebasing and Golden rule of rebasing for more information.

Key Differences and Examples

Let’s illustrate the differences between git merge and git rebase with examples:

Git Merge Example:

Imagine you have a feature branch feature/add-new-feature that you want to merge into your main branch main. Here’s how you would use git merge:

1
2
3
4
5

# Checkout the main branch
git checkout main

# Merge the feature branch into main
git merge feature/add-new-feature

After merging, your commit history might look like this:

1
2
3
4
5
6
7

*   Merge branch 'feature/add-new-feature' into main
|\
| * Commit C4 (Feature Work)
| * Commit C3 (Feature Work)
|/
* Commit C2 (Main Work)
* Commit C1 (Main Work)

Git Rebase Example:

Now, let’s rebase the same feature/add-new-feature branch onto main:

1
2
3
4
5

# Checkout the feature branch
git checkout feature/add-new-feature

# Rebase the feature branch onto main
git rebase main

After rebasing, your commit history would be linear:

1
2
3
4

* Commit C2 (Main Work)
* Commit C1 (Main Work)
* Commit C3 (Feature Work)
* Commit C4 (Feature Work)

Notice that there are no merge commits, resulting in a cleaner commit history.

In order to understand Git merge vs Git rebase, checkout below video:

Conclusion

In summary, git merge and git rebase are both valuable tools for integrating changes in Git, each with its own strengths and use cases. git merge is suitable for maintaining a clear merge history and is often used in collaborative environments. On the other hand, git rebase is ideal for creating a linear commit history, making it useful for feature branches and keeping the main branch clean.

The choice between git merge and git rebase depends on your project’s specific needs and your preferred workflow. Understanding the differences and when to apply each command empowers you to make informed decisions in your Git workflow, contributing to a more organized and manageable codebase.