{"id":625,"date":"2023-01-13T16:16:00","date_gmt":"2023-01-13T16:16:00","guid":{"rendered":"https:\/\/www.aviator.co\/blog\/?p=625"},"modified":"2025-09-25T11:51:11","modified_gmt":"2025-09-25T11:51:11","slug":"rebase-vs-merge-pros-and-cons","status":"publish","type":"post","link":"https:\/\/www.aviator.co\/blog\/rebase-vs-merge-pros-and-cons\/","title":{"rendered":"Rebase vs. Merge: Pros and cons"},"content":{"rendered":"\n

Managing repository history is one of the critical parts of keeping your code base scalable. Many approaches might be helpful in one case and not work in another. Here we will discuss how git merge and git rebase differ from each other.<\/p>\n\n\n\n

Let’s have a look at how both commands work.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Git rebase<\/strong><\/h2>\n\n\n\n

As the git official docs<\/a> state: \u201cReapply commits on top of another base tip,\u201d <\/em><\/strong>this reapply will place all commits on the current branch on top of the target branch. Let’s take an example here:<\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n

Assume the following history exists and the current branch is a feature<\/code>:<\/p>\n\n\n\n

           A---B---C feature\n\n         \/\n\n    D---E---F---G main<\/code><\/pre>\n\n\n\n
From this point on, feature<\/code> as the result of the following commands:<\/p>\n\n\n\n
git rebase main<\/code><\/p>\n\n\n\n
would be:<\/p>\n\n\n\n
                   A'--B'--C' feature\n\n                 \/\n\n    D---E---F---G main<\/code><\/pre>\n\n\n\n
Now all the commits done on the feature branch are re-aligned on top of the new state of the main branch. During this process, all commits on the feature<\/code> branch are rewritten and have new commit IDs. If there is any conflict in between the rebasing process, git will stop the process and ask you to resolve conflicts before proceeding.<\/p>\n\n\n\n
Here are the options<\/a> available with the git rebase<\/code> command.<\/p>\n\n\n\n
Git merge<\/strong><\/h2>\n\n\n\n
According to the official docs: \u201cJoin two or more development histories together,\u201d it is a non-destructive operation that adds a forked stream on top of the target stream without rewriting commits. <\/p>\n\n\n\n
Here is what it will look like in our example:<\/p>\n\n\n\n
\"\"\/<\/figure>\n\n\n\n
Assuming the feature<\/code>  branch is forked from the main<\/code> branch, with the main<\/code> having commits applied after the fork was created, the state of the repository will look like this:<\/p>\n\n\n\n
           A---B---C feature\n\n         \/\n\n    D---E---F---G main<\/code><\/pre>\n\n\n\n
From this point on, the feature<\/code>:<\/p>\n\n\n\n
git merge main<\/code><\/p>\n\n\n\n
Would result in the following output:<\/p>\n\n\n\n
          A---B---C feature\n\n         \/         \\\n\n    D---E---F---G---H main<\/code><\/pre>\n\n\n\n
Here, H<\/code> is the new commit on top of the feature<\/code> branch that has the full stream coming from main<\/code>. <\/p>\n\n\n\n
A new commit will be created on the feature<\/code> branch that might feel unnecessary. But, on the flip side, the commit history is intact and commits are not re-written. Git will ensure the merge<\/code> is safe and will prompt in case of any conflicts just like the rebase<\/code> command.<\/p>\n\n\n\n
This is what our feature branch will look like now<\/a>.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Differences<\/strong><\/h2>\n\n\n\n
Both commands as seen may offer similar results but differ in how they achieve them. These differences can have a significant impact on how your commit history looks in the long run. <\/p>\n\n\n\n
We have identified a few of the most important differences that can help you better understand both; Remember we aren\u2019t establishing any conclusions just yet, we will discuss pros, cons, and use cases later in the post.<\/p>\n\n\n\n
Commit logs<\/strong><\/h2>\n\n\n\n
For merge<\/code> it keeps the commit history intact with the merge commit showing on top, while rebase<\/code> rewrites, it means the timestamp of actual commits is lost and new commit IDs are created.<\/p>\n\n\n\n
Commit history<\/strong><\/h2>\n\n\n\n
On the other hand, when the feature<\/code> branch is merged in main<\/code>, it may create a single commit so the implementation details go away after merge<\/code>. Rebase eliminates the extra merge commits and makes commit history linear with all commits of feature<\/code> lined up together.<\/p>\n\n\n\n
Conflict resolution<\/strong><\/h2>\n\n\n\n
Both commands handle conflicts differently – merge<\/code> being more focused on bringing the stream on top of the other will show conflicts at once, while rebase<\/code> processes one commit at a time. Hence, it presents conflicts on each commit.<\/p>\n\n\n\n
Benefits<\/strong><\/h2>\n\n\n\n
Both commands in the discussion are super useful in their own capacity. Let’s dive into what each command offers as compared to each other.<\/p>\n\n\n\n
Merge<\/strong><\/h2>\n\n\n\n