Git Rebase 

In Git, rebasing is the process of applying a series of commits on top of another branch. This can be used to incorporate changes from one branch into another, or to clean up a branch by removing or rearranging commits.

Here’s how it works:

1.You select the branch you want to rebase (the “rebase branch”)

As we can see the file in the dev branch is ready with the commit. 

2. You select the branch you want to rebase onto (the “base branch”)

The file in the master branch is also ready with the commit.

From the above example, we have committed to the master branch and want to rebase it on the dev1 branch. Let’s see the below commands :

$ git checkout dev1

Now you are on the dev1 branch. Hence, you can rebase the dev1 branch with the master branch. See the below command:

$ git rebase master

3.Git reapplies each commit from the rebase branch, one by one, on top of the base branch.

The result is a new linear branch that includes the changes from both the rebase branch and the base branch, as if the rebase branch had been created based on the latest version of the base branch.

Rebasing can create a more linear history by avoiding merge commits, but it can also cause conflicts if the base branch has changed since the rebase branch was created. In these cases, you’ll need to resolve the conflicts before the rebase can continue.

It’s important to note that rebasing can rewrite Git history, which can make it difficult or impossible to collaborate with others who have cloned the original branch. As a result, it’s often recommended to use rebasing only on branches that have not been shared with others.

Git Merge vs Git Rebase :

• Git merge and Git rebase are two ways to integrate changes from one branch into another branch. The main difference between the two is how they preserve the history of the changes.
• Git merge creates a new “merge commit” that records the fact that two branches have been combined. The merge commit has two parent commits, one from the branch being merged and one from the branch being merged into. This creates a branching history that shows the divergent development of the two branches and the point at which they were combined.
• Git rebase, on the other hand, reapplies the changes from the branch being rebased onto the branch being rebased onto, resulting in a linear history where it appears as if the changes happened at once. The branch being rebased is effectively “moved” to the tip of the branch being rebased onto.

• In general, Git merge is a better choice when you want to preserve the entire history of your project, while Git rebase is a better choice when you want to maintain a linear history and avoid creating unnecessary merge commits. However, it’s important to note that rebasing can make it difficult or impossible to collaborate with others who have cloned the original branch, as it rewrites the Git history.