Software Programmer
asked on
Rebase vs Merge - When to use ? Real Time Application ?
We have two concepts in GIT Rebase and Merge
Rebase Overrides the history of commits
Merge keep track of history of commit.
Merge would be cluttered if many people works and commits on the same feature branch.
Rebase would be time consuming when multiple people commits on the same branch eventhough we just changed a few lines in the same committed file.
When to use Rebase and when to use merge in real time is not clear?
Please advise.
Rebase Overrides the history of commits
Merge keep track of history of commit.
Merge would be cluttered if many people works and commits on the same feature branch.
Rebase would be time consuming when multiple people commits on the same branch eventhough we just changed a few lines in the same committed file.
When to use Rebase and when to use merge in real time is not clear?
Please advise.
David Johnson, CD
It is my understanding that rebase is used when one releases a version until then one uses merge, you can then archive the previous commits.
As Git is distributed, each repository can be slightly different. Your own repository may contain some really weird branches that you do not want to publish. From that point of view, you may want to keep "your official" branch that will keep the wanted history that is to be published to the outer repository (upstream). You may keep your own history of your own branches, and (say) after a week of work, you want to publish only several commit points of the work. So, you rebase from the chosen ones to your official branch (that may be named by your name). And only then you publish your official branch changes to the other repository (keeping the secret of your own weird history -- nothing personal :)
Another situation, the bigger project may have one branch (possibly master), that will contain only the commit points that are related to the official releases. It may be mostly linear with some branching for fixes. In other words, you do not want to present the commit points that are not interesting for the "end user" (programmer).
Anyway, you can start with the simple merge approach (not having any secrets). After a while, you may find that you want make one clean branch. Only then you introduce the new branch for the purpose and use the rebase command to create the commits alongside.
Another situation, the bigger project may have one branch (possibly master), that will contain only the commit points that are related to the official releases. It may be mostly linear with some branching for fixes. In other words, you do not want to present the commit points that are not interesting for the "end user" (programmer).
Anyway, you can start with the simple merge approach (not having any secrets). After a while, you may find that you want make one clean branch. Only then you introduce the new branch for the purpose and use the rebase command to create the commits alongside.
This question needs an answer!
Become an EE member today
7 DAY FREE TRIALMembers can start a 7-Day Free trial then enjoy unlimited access to the platform.
View membership options
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.