What are the differences between these two actions in git? When should we use merge, when rebase and why?
Git is a version control system and we use it to store and save changes within one or more files over time. It is a great tool because it shows us the status of a file at any specific time in history and shows precise information on who changed what at what time. But it is not so simple to work with that information if we have a lot of data and a lot of creators.
Git gives us an option to work in parallel to other users and have live tracking on file changes. That can often be a problem when we want to save it all together in the final file. For that action in Git, we have two functions, merge and rebase.
The main difference between them can be observed from the diagrams pictured below.
What does the picture show us?
In the middle diagram, we observe two branches. The green represents the master and the blue represents a new branch created from the master. For every branch, we have a couple of independent commits.
On the left diagram, we merge a new branch to master by action merge. Merge action resembles a new commit, where we can view all the changes created in that separate branch. After merging we can also historically see which branch is a part of what commit. The merge action stores all the changes as they happened, it represents real history.
On the right diagram, we used the rebase action. That action placed all commits from the new branch in the master branch. That is not real history, since it is forced by rebase.
Why should we use rebase?
When we are working on a bigger project, we can expect to have a lot of branches. Using the merge actions leaves us with the view of all the old merged branches, which leads to a mess within the project. It is difficult to follow which commit is originating from which branch.
Rebase has a cleaner history, but just seemingly because git commits are immutable. Using rebase, Git creates new commits and places them in the master branch, at its base. Commits in separated branches stay in their place and are deleted automatically, as they become unreachable. At the end of that process, the history looks cleaner.
What about conflicts?
Using both actions can require conflict resolution. Those conflicts happen when there are changes in the same lines of files in different branches. So, while we merge or rebase, we need to resolve presented conflicts and decide on them, which line is correct and from which branch. This we resolve in the same way in both actions.
What to use?
When in doubt, using merge is always the better option. The rebase is recommended only if we have our commits stored locally. When our work is online, we can create issues for other team members. One of the issues is the complete loss of saved work.
