Git Merge and Git Rebase
Git Merge and Git Rebase serve the same purpose. They are designed to integrate changes from multiple branches into one
Git Merge
merging takes the contents of a source branch and integrates them with a target branch
In this process, only the target branch is changed. The source branch history remains the same.
Pros
Simple and familiar
Preserves complete history and chronological order
Maintains the context of the branch
Cons
Commit history can become polluted by lots of merge commits
Debugging using git bisect can become harder
Merge the master branch into the feature branch using the checkout and merge commands.
Git Rebase
Rebase compresses all the changes into a single “patch.” Then it integrates the patch onto the target branch. Unlike merging, rebasing flattens the history because it transfers the completed work from one branch to another. In the process, unwanted history is eliminated. Rebases are how changes should pass from the top of the hierarchy downwards, and merges are how they flow back upwards.
Pros
Streamlines a potentially complex history
Manipulating a single commit is easy (e.g. reverting them)
Avoids merge commit “noise” in busy repos with busy branches
Cleans intermediate commits by making them a single commit, which can be helpful for DevOps teams
Cons
Squashing the feature down to a handful of commits can hide the context
Rebasing public repositories can be dangerous when working as a team
It’s more work: Using rebase to keep your feature branch updated always
Rebasing with remote branches requires you to force push. The biggest problem people face is they force push but haven’t set git push default. This results in updates to all branches having the same name, both locally and remotely, and that is dreadful to deal with.
This moves the entire feature branch on top of the master branch. It does this by re-writing the project history by creating brand new commits for each commit in the original (feature) branch.