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.
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
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) ,
Now the situation changes to something like below
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
Force push is considered a bad practice and it could be dangerous if multiple people are working on same branch. You can avoid a force push on a branch using a merge ex:
ReplyDeletegit checkout feature
git rebase master
git checkout master
git merge feature
git push
This way you'll create clean history plus avoid doing a force push.
Yes . that is correct :) that is why i have mentioned that in a project where a lot of people working on as a team , rebasing is not a very good option .But then again if the team prefers a clean linear history , then they can enforce rebasing assuming they very well know about the consequences since like you said we need to --force push every time we rebase it .
DeleteGreat Article
ReplyDeleteB.Tech Final Year Projects for CSE in JavaScript
FInal Year Project Centers in Chennai
JavaScript Training in Chennai
JavaScript Training in Chennai
Same four stuff real. Open similar whom.
ReplyDelete