In the world of version control with Git, two fundamental commands stand out: Git rebase and Git merge. These commands integrate changes from one branch into another but have distinct characteristics and implications for your version control workflow. In this blog post, I will explore the differences between Git rebase and merge, their use cases, and how they affect your project’s commit history.
What is Git Rebase?
Git rebase is a powerful command that allows you to integrate changes from one branch into another while maintaining a clean and organized commit history. Unlike Git’s traditional merge command, which creates a new commit to merge two branches, rebase applies the commits of one branch onto another as if they had been made sequentially.
To understand how rebase works, let’s consider a scenario with a forked repository called “kaniko” that has branches named ‘main’ and ‘testbranch.’ When comparing the two branches, we notice that ‘testbranch’ is 4 commits (let’s assume that the commit names are a,b,c,d) behind ‘main’ and 1 commit ahead (let’s say commit name is e). Now let’s say that the point where both the branches diverged is called z, then the head of the testbranch becomes z+e (which includes the extra commit e). So, when you rebase, testbranch is moved behind by one place (z+e-e) and then, the 4 commits from main are applied (z+e-e+a+b+c+d) and after this e is applied back on top of this (z+e-e+a+b+c+d+e). It is important to note that the + & – here do not indicate an arithmetic addition or subtraction but instead means the addition of a commit or removal of a commit respectively. To sum up, with rebase, the head of ‘testbranch’ is aligned with that of main after keeping aside the one extra commit. The extra commit is then applied on top of the aligned head, ensuring synchronization between the branches.
In the below image, I have used an –interactive flag which will enable me to modify the way the extra commits are applied while rebasing, with a bunch of supporting options as can be seen in the second image.
Normally, git rebase main should also work exactly the same way with no problems at all.
Shows how rebase is done
Shows the interactive rebase panel which shows actions that can be done on the extra commit on testbranch
In the interactive panel above the extra commit ‘e’ is nothing but – ‘Dockerfile changes to build from ubuntu’. ‘Pick’ lets you pick and apply that commit on top of the rebased head. With the interactive flag one of the things that can be done is, you can change the ordering of commits applied on top of the rebased head. Suppose the extra commit is not just ‘e’ but ‘e’, ‘f’, ‘g’, then with the interactive flag, they can be picked and applied in any order: e+f+g, f+g+e etc:-. Other things you can do with the interactive flag is drop useless commits instead of applying them on the rebased head and so on.
An illustration of how rebase works
Here is one more interesting tweak than you can do using rebase with a flag called –onto.
Initially, in the above use case I am checking out into a branch called “anotherbranch” using “testbranch” as the base. So the head points to tip of “testbranch”. But let’s say when you compare it with main its way too behind and or you think it’s way too outdated to work with so you want to come back in sync with main without losing any work that you have pushed into “anotherbranch”. That is where the flag –onto becomes helpful. Now instead of using testbranch head as the base for anotherbranch, by doing git rebase –onto main testbranch, you can move the base head from testbranch to main and the extra work that you had done is reapplied on top of main. Pretty convenient.
What is Git Merge?
Git merge, on the other hand, combines the commits from one branch into another by creating a new “merge commit” that represents the merge point. This approach preserves the commits of both branches, resulting in a branching structure that shows the integration of changes over time. Merge commits clearly indicate when and where different branches were merged, providing a comprehensive view of the project’s development.
However, compared to rebasing, using merge can result in a more cluttered commit history. If the ‘main’ branch is very active, multiple merge commits on your branch can pollute the project’s history. Despite this, merge is generally considered an easier option, as it involves fewer caveats and potential conflicts.
If we look at the same example as that for rebase, z+e is the head of testbranch while z+a+b+c+d is the head of the main branch. If we want the testbranch to come in sync with the main branch, using the merge strategy, the extra commits in the main branch (a,b,c,d) are added as a merge commit(a+b+c+d) onto the testbranch. Finally, the effect on the testbranch is the same (z+e+a+b+c+d). No commits/information is lost in either of the processes and at the end of the day all the information is synced.
An illustration of how merge works when it is used in the same scenario instead of rebase
It’s important to note that when contributing to a repository, reviewing the repository’s rules is beneficial to determine which strategy to use during development. Let us now look at a CLI example of how merging works. In the below example, I am merging a branch onto main which creates a new merge commit on main.
Of course, this would not be possible if the main is protected. Then, you will have to raise a pull request that gets reviewed by your peers and then merged.
A Look at Git Pull
Git pull combines the functionality of both git merge and git rebase. When you run the git pull command, Git retrieves new commits from the remote repository and incorporates them into your local branch.
By default, the git pull command runs the following commands:
git fetch
git merge
However, if you want to use the rebase strategy after fetching, you can include the –rebase flag in your git pull command. The choice between merge and rebase depends on the specific requirements of your project and the pros and cons of each strategy.
Here’s an example of using the Git CLI for pulling with the rebase strategy:
This command fetches new commits from the ‘origin’ remote repository and performs a rebase on your local branch.
In summary, Git rebase and merge are powerful commands with distinct characteristics. Git rebase allows you to integrate changes by applying commits sequentially, resulting in a cleaner commit history. Git merge, on the other hand, creates merge commits that preserve the branching structure and provide a comprehensive view of the project’s development. The choice between rebase and merge depends on your project’s requirements and the desired commit history. By understanding the differences and use cases of these commands, you can effectively manage your version control workflow with Git.
Using Git on Ozone
Being an end-to-end CI/CD platform, Ozone integrates with almost every popular registry and repository that DevOps teams subscribe to.
You can connect to them and run various operations from our predefined pipeline templates where there’s no need to code a YAML. You can build and deploy across clusters while, at the same time, having visibility across workloads from a single pane of glass.
