When you generate a pull request, you merge your topic branch into your main branch or your default branch. The commit history made in the topic branch are reflected in the commit history of the main branch just like all the commits are integrated in the main branch after completing the pull request. As a developer, everyone has been a part of the heated debate as to in which way the code should get integrated, at some point.
Now working with the Azure Repos, you get the option of multiple merge type based on your scenarios. Let's go through them:
Merge (no-fast forward)
This is the default merge strategy. In this, each and every commit that is done in the topic branch is merged with the main branch. It emulates running git merge pr from the master branch.
This particular strategy comes into play because it gives a complete insight to how a developer worked in the topic branch as well as the direction in which the branch evolved.
However, having a lot of commits in your branch history can be very verbose.
Squash
A single new commit with all the repository contents is merged with the main branch. It emulates running git merge pr --squash from the master branch.
All the individual commits in the topic branch, that made up the pull request, are discarded, creating a simple, linear history in the branch. This scenario for this type of merge takes place usually during 'fix up' commits.
Rebase
Each and every individual commit is taken here from the topic branches and is cherry-picked onto the master branch. It emulates running git rebase master on the pull request branch, followed by git merge pr --ff-only on the master branch.
It also gives a simple, linear history, just like the Squash merge, but with every commit retained. These merge type comes into play where every commit has its importance and a proper commit standards are followed.
Semi- Linear
It is a mix of rebase and merge. It can be understood in two steps.
- The commits in a pull request are rebased on top of master branch
- Then those pull requests which are rebased are merged with the master branch.
It emulates running git rebase master on the pull request branch, followed by git merge pr --no-ff on the master branch.
All the individual commits are retained for someone to see how the work evolved, while also getting to see the work in every individual pull request.
