When merge, rebase, and squash
After using git for a long time, I still didn’t realize the importance of understanding the different scenarios that we can have in our developing process. I recently started using merge squash because a colleague suggest I include so I decided to make some research and understand it in deep when we choose to use one of those because, to be honest, sometimes can be confusing.
In this article, we will see when and why we should use these commands depending on the scenario.
Rebase
Rebasing means moving or combining a series of commits to a new base commit. In other words, it changes the basis of the current branch from one commit to another making it look like the branch has been created from another commit.
Rebase rewrite the history on top of a branch.
Problems rebasing changes
Why do we use Git at all? Because it is our most important tool for tracking down the source of bugs in our code. Git is our safety net. By rebasing, we give this less priority, in favor of the desire to achieve a linear history.
- Avoid using rebase after creating a pull request, other developers will be looking at your commits, which means that it’s a public branch.
- Rebasing can be dangerous! Rewriting the history of shared branches is prone to teamwork breakage.
- Another side effect of rebasing with remote branches is that you need to force push at some point.
When to rebase?
- If you want to make a local clean-up and you can rebase your branch with the master branch.
- You can rebase in the scenario that you are pulling changing of someone else feature or if you and your colleague are working in the same branch as it will create linear history.
Merge
The git merge command integrates the independent lines of development into a single branch.
The primary use of git merge is to combine two branches. It is also used to merge multiple commits into one history.
Benefits of use merge
- Traceability: This helps keep information about the historical existence of a feature branch and groups together all commits part of the feature.
Problems merging changes
- History can become intensely polluted by lots of merge commits, and visual charts of your repository can have rainbow branch lines that don’t add too much information, if not outright obfuscate what’s happening.
Squashing Merge
Squash merging is a merge option that allows you to condense the Git history of topic branches when you complete a pull request. A simple way to think about this is that a squash merge gives you just the file changes, and a regular merge gives you the file changes and the commit history.
Imagine if your feature branch has a large number of commits- E.g. 1000s commits. Rather than merging all commits individually from feature to master, there is an option to add up all commits into a single commit. This is called a squash commit because it “squashes” all the individual commits into one big change. As far as the history of the master branch is concerned, the history of the feature branch would be lost.
When squash merge
It is very useful when we are working on a feature branch and we have done so many commits for a single feature now we want to merge this to master.
Summary
I think this is all you need, make sure that you understand each of these strategies that git provides and use them according to your goals.
