When to use git rebasing and why ?

note : My earlier post was about some of the useful commands of git and how to use them

Git rebase : introduction

Git rebase is a handy mechanism when you need merge the changes of your branch with another branch (probably with the master branch) . But the process behind a git-rebase is not that simple as the definition suggests , but it is clean and awesome . In this post , I am going to go through with the process behind a git rebase , when to use it , and when to avoid it .

Let’s look at the following simple scenario..

Say you have a master branch called master .. (duh)


And you are creating a development-branch out of this master branch to do your development stuff.

git-rebase-1

And you are now working on this development-branch for sometime . You make changes , you add these changes and you commit those changes to this branch . Now after few days , you decides that it is the right time to integrate your changes to the master branch . But guess what , your team members have already pushed their changes to the master branch . So you cannot just easily merge your changes to the master without messing up the changes of your peers . Following diagram illustrates the situation

git-rebase-4

As you can see there is a gap between the branch you are working on and the master . This is where the it rebase comes in .By using git rebase you are going to integrate your changes (commit B1 , B2) with the master (Where now the head is located at commit M3) ,

git-rebase-2

Now the situation changes to something like below

     git-rebase-3

When you use git rebase , the commit history (commit hashes) changes entirely . That is why i have used the green color to represent the history instead of blue (color of master’s commits) or red (color of development-branch commits).

The Advantage

It creates a linear History which is the very reason why we need to use git rebasing. Your history is clean flat and readable . You can identify the commits of each of your team members very easily in different timelines .

The Disadvantage

In a situation where you have so many people consistently pushing their changes to master and when there are so many branches being merged with the master , It is kind of a pain in the a** to keep your branch upto date with master using git rebase . You have to constantly do the rebasing , and might need to resolve conflicts time to time

Also rewriting your commit history after each and every reabsing is not always a good thing . It means that your commit hashes change consistently and also , you need to force push every time to the remote after a rebase

When to use git rebase : Only when you need a clean linear history so that you can clearly see what is going on with the all the commits from all the team members

When not to use : If you prefer to follow a simple mechanism where you can integrate your changes with the upstream branch without a fuss you can always go with git merge

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s