Git Merge vs. Rebase: Understanding Branching Strategies for a Cleaner Workflow

You're coding away a new feature in your git branch,feeling good about the clean, elegant code you've written. But hold on! The main branch has been updated by other developers, and you need to integrate your changes without creating a mess.

This is where Git magic comes in: it offers two powerful tools for integrating changes from one branch to another: merge and rebase.

Understanding the difference between these approaches is crucial for maintaining a clean and organized codebase.

This guide will break down Merge vs. Rebase, explain how they work under the hood, and help you choose the right approach for a smooth and safe development workflow.

Git Merge:

Definition:

Git Merge is a way to combine the changes introduced in two separate branches into a single branch.

The first branch involved in this operation is called the source branch, which is typically the branch you're currently working in.

The other branch is called the target branch, which is the branch whose changes you want to integrate.

When you perform a merge, Git creates a new "merge commit" that acts as a checkpoint, recording the integration point between the two branches.

The merge commit includes informations about the branches involved and any conflicts that were encountered during the merge process.

Example:

Let's consider the following example:

Initially, the main branch had three commits labeled ("1," "2" ).

sidali:~/Desktop/test-git$ echo "..." >> 1.md
sidali:~/Desktop/test-git$ git add .
sidali:~/Desktop/test-git$ git commit -m '1'


sidali:~/Desktop/test-git$ echo "..." >> 1.md
sidali:~/Desktop/test-git$ git add .
sidali:~/Desktop/test-git$ git commit -m '2'

sidali:~/Desktop/test-git$ git log --graph --oneline

* 0a9d31e (HEAD -> main) 2
* a52a56e 1

then you created a new branch from the main branch called "features".

Both features and main now contain the same commits.

sidali:~/Desktop/test-git$ git checkout -b features
Switched to a new branch 'features'

sidali:~/Desktop/test-git$ git log --oneline --graph

* 0a9d31e (HEAD -> features, main) 2
* a52a56e 1

Let's create 2 additional commits on our newly created branch "features".

sidali:~/Desktop/test-git$ echo "..." >> 2.md
sidali:~/Desktop/test-git$ git add .
sidali:~/Desktop/test-git$ git commit -m '3'

sidali:~/Desktop/test-git$ echo "..." >> 2.md 
sidali:~/Desktop/test-git$ git add .
sidali:~/Desktop/test-git$ git commit -m '4'

sidali:~/Desktop/test-git$ git log --oneline --graph

* df2c347 (HEAD -> features) 4
* 24076e3 3
* 0a9d31e (main) 2
* a52a56e 1

Now let's come back to our main branch and add a new commit labeled "5" to simulate a teammate integrating changes in parallel on the main branch.

$ git checkout main

Switched to branch'main''

$ echo "..." >> sidali.txt
$ git add .
$ git commit -m '5'

$ git log --oneline --graph

* 7dcc795 (HEAD -> main) 5
* 0a9d31e 2
* a52a56e 1

The image bellow describe the current status of our two branches , main and features.

An image illustrating the status of the main and the feature branch before the merge

Did you guess it , now is the time to merge our features into the main branch using the "merge " git command.

$ git checkout man
Switched to branch 'main'

$ git merge features

After executing the "git merge" command from our current branch main, targeting the features branch, we should see our branches on features coming to main.

git merge message

No, not that fast :) . Before completing our merge, git needs more details from us about the reasons behind it.

As you can see from the image below we are prompted to enter a commit message.

• Press ctrl/command + O .
• Enter your merge commit message.
• Press ctrl/command + x to exit the nano editor.
• That's it, our merge is completed and you're good to go : ) .

Image illustrating a good-to-go state :)

The merge results are illustrated on this image bellow:

Git merge results

Git merge features branch to main

That's right! The merge creates a new "merge commit" that combines the changes from both branches. After a successful merge, the main branch will contain three commits: 1, 2, and the "Merge commit." This merge commit references the commits from the "features" branch (typically 3 and 4).

Importance of Git Merge:

Git Merge plays a crucial role in maintaining a clear and collaborative development workflow. Here are some key reasons why understanding Merge is important.

• Complete History: Merges create "merge commits" that record the entire Git history, allowing you to easily track changes and identify who made them ( useful for debugging!).
• Collaboration Friendly: Merging offers a clear way to combine developer work on separate branches while maintaining individual history. This promotes transparency and avoids conflicts in the codebase (perfect for teams!).
• Beginner-Friendly: Merging is the default and easiest way to integrate branches in Git. It doesn't require complex commands, making it accessible for beginners and teams with varying Git experience.

Git Rebase:

Definition:

Git Rebase is a powerful Git operation that allows you to rewrite the history of your branch by replaying its commits on top of another branch (usually the main or production branch).

You can imagine Git Rebase as a writer revising their chapters from the first one, incorporating new ideas while adding new chapters on top of the last ones or in between the existing chapters.

Example:

Let's start initializing a new git repo following the same steps as the previous example to reach the illustrated state on the image below for the two branches "features" and "main" :

sidali@sidali-HP-ZBook-15u-G5:~/Desktop/test-git$ git log --graph --oneline main
* e153403 (main) 5
* 1dd9395 2
* f7e4f67 1
sidali@sidali-HP-ZBook-15u-G5:~/Desktop/test-git$ git log --graph --oneline features
* f434621 (HEAD -> features) 4
* 2af35d3 3
* 1dd9395 2
* f7e4f67 1

An image illustrating the status of the main and the feature branch before the rebase

Now let's checkout the feature branch and rebase it to the main branch.

The rebase operation will proceed as follow:

• checkout the main branch.
• replaying the main branch commits on the feature branch sequentially, starting from the closest common ancestor
• If any conflict is faced during the Rebase Git will pause the operation and prompt you to fix them using your preferred editor ( vs code merge editor is very cool though).
• At the end of the Rebase, the main branch will remain untouched , but the features branch will have all the newly added commits on the main branch.

$ git checkout features
Switched to branch 'features'

$ git rebase main

Successfully rebased and updated refs/heads/features.

$ git log --oneline --graph

* 38aa3a6 (HEAD -> features) 4
* bbb886d 3
* e153403 (main) 5
* 1dd9395 2
* f7e4f67 1

An image illustrating the status of the main and the feature branch after the rebase

Have you noticed any key differences between Git merge and rebase so far?

Exactly! Unlike Merge, Git Rebase doesn't create a separate merge commit. Instead, it replays your existing commits on top of another branch, essentially rewriting your branch history for a more linear flow.

Importance:

While Git Merge is the default option, Git Rebase offers some advantages:

• Cleaner History: Rebasing can result in a more linear and streamlined Git history, making it easier to understand the overall development flow. Imagine a book with chapters rearranged in a logical order for smoother reading.
• Easier Patching: Sometimes, bug fixes or new features are isolated in specific commits. Rebase allows you to easily isolate these commits and apply them to different branches without merging unnecessary changes. This is like selectively sharing specific chapters of your revised book with different audiences.

However, it's crucial to consider the drawbacks of rewriting history:

• Potential Conflicts: During a rebase, you might encounter conflicts if your branch diverged significantly from the target branch. These conflicts require manual resolution, which can be time-consuming.
• Collaboration Risks: If you've already shared your branch with others, rebasing rewrites its history. This can cause issues for them if they've already pulled your work, leading to merge conflicts on their end. It's like revising your book chapters after others have already started reading the original version.pen_spark

Choosing Between Merge and Rebase

The choice between Merge and Rebase depends on your specific needs and workflow:

Use Merge When:

• You're working in a collaborative environment and want to preserve the complete Git history (including merge commits for clarity).
• You don't need to clean up your branch history before sharing it.
• You're new to Git and want to use the simpler and safer approach (avoiding potential conflicts and confusion for collaborators).

Use Rebase When:

• You're working on a local branch and want to clean up your history before sharing it publicly (creating a more linear flow).
• You understand the potential risks of rewriting history and are comfortable using it (especially if working solo or on a branch no one else has pulled).
• You want to isolate specific commits for easier patching across different branches.

Conclusion

Both Git Merge and Rebase are powerful tools for integrating changes. Understanding the key differences between them will help you choose the right approach for your situation. Here are some additional tips:

• Start with Merge: If you're new to Git, start with Merge as it's the default and safer option, especially in collaborative environments.
• Rebase Locally: Always use rebase on a local branch before pushing your changes to a remote repository, particularly when working with others.
• Visualize Your History: Consider using Git visual clients to help you visualize your Git history and make informed decisions about merging and rebasing.

By mastering both Merge and Rebase, you can maintain a clean and organized Git workflow, facilitating collaboration and clear communication within your development team.