The Be Sure Blog

Code Snippets | Problem Solving | Tips & Tricks

The Be Sure Blog banner

Git Merge VS Rebase, pros and cons for each

posted on 26.1.2023 by Below Surface in "GitHub"

Rebasing and merging both solve the same problem: Integrating changes from one branch to another. This may occur when a feature branch was created from the main branch and both had individual changes committed to them over time. After a while, the commits of the "feature" branch could be ready to be joined into the "main" branch and this is when either merging or rebasing can be used. A smart way to do this, is to merge the commits of the main branch into the features branch first. This way, we would not destroy the main branch in any case and we can see if the commits of the two branches work well together, or if there are any merge conflicts that need to be addressed.

Solution 1: Git merge

Since most people use merging to solve this task, this is explained first:

$ git checkout feature
$ git merge main
$ git add .
$ git commit -m "merge main into feature"
$ git push

Please note that in our example we do not face any merge conflicts. If we would, we would need to resolve them manually after running $ git merge main.

After successfully merging the main branch into feature and making sure, the program still runs smoothly, we can then go on and create a merge request to merge the feature branch into main. Because currently the features branch has all the commits of the main branch in it, but the main branch still has none of the ones pushed to the feature branch. We can either do this via the GitHub website, or via the command line, if the main branch is not secured:

$ git checkout main
$ git merge feature
$ git add .
$ git commit -m "merge feature into main"
$ git push

Note: Git merges are "forward focused". They result in new commits, while existing commits in the merged branches stay untouched.


- keeps the history intact and traceable

- easier to use


The downside of merging: When developing the feature branch takes a long time and simultaneously many new commits happen in the main branch as well, the main should be merged into the feature branch frequently. This way potential merge conflicts do not pile up and make merging the two branches very time consuming or even impossible. That's when git rebase comes into play.

Solution 2: Git rebase

With git rebase we can move the whole feature branch to the beginning of the main branch. This way, all the commits are still there, but the git history was changed. New commits are created on the main branch for each commit of the feature branch. This is how to do it:

$ git checkout feature
$ git rebase main

Pros of git rebase:

- the project history is cleaner

- no unnecessary merge conflicts

- a linear project history


If a commit has been shared with other developers and is in use, it should not be rebased, since history would be changed, that other developers already have changed.




More posts of this category

Get started with GitHub Actions

Learn about CI/CD with GitHub


Fixing .gitignore is ignoring a .gitignore rule

Ignoring a folder does not work? This may be a solution!


CI/CD: How I finally fixed "err: npm WARN EBADENGINE"

Running the same .sh script may deliver two different results, not anymore!


Delete files and folders from GitHub history

How I deleted a folder from the GitHub history of a repository