GIT Merge Strategy

what do all these merge strategies mean

Tags: Technology, GIT, Source Control
Posted by mjourdan on February 04, 2019

I've been using TFS for a while now on the online Azure DevOps. As Microsfot has been continuing to enhance the experience, they've introduced GIT. So I've decided to devote some time to start using it moving forward. One of the first obstacles I found was understanding the merge strategies. So I thought I would share what I found and when to use each of the merge strategies.

What merge strategy is right for you?

I found Atlassian did a nice job explaining the differnt merge strategies and wanted to include a snippit from them here.

When to do a merge commit

Select Merge commit when you want to maintain an exact history of changes. Merge commits are also useful if, as part of your workflow, pull requests are large in scope and you review commits individually. Because this strategy keeps all commits during the merge, you’ll still see all commits from the source branch on the Commits page.

When to do a squash merge

Select Squash to make your commits list less cluttered, which results in less time to search for commits that introduce a bug (with a git bisect) and provides an easy-to-follow commit history. Because this strategy combines all commits when you merge, you’ll only see one commit on the destination branch on the Commits page.

When to do a fast-forward merge

Select Fast forward if the destination branch has no new commits since you created the source branch. Fast-forward merges move the source branch tip up to the destination branch tip, combining commit histories. Because this strategy moves the source branch’s commits to the destination branch, you’ll still see all commits on the Commits page.

You can also read more about Microsoft's GIT branching guidance here.