Gitflow: Should I squash commits when merging from a release branch into master?

I am going to merge my release branch to master and I am wondering if I should squash the commits from develop into a single merge commit when merging into master.

General documentations about git flow contain figures like this one from in the Atlassian page:

In those figures only single commits appear on master instead of all commits made to develop.

Acctually, I like the idea of having a master branch which release commits only.

Should I retain all commits on develop when merging into master? Or do you squash the commits before merging to master when following Gitflow?

Link to the source article: Gitflow Workflow - Atlassian

Solution 1:

In my opinion, and bear in mind, this is just an opinion, and you will likely get different answers, you should NOT squash the commits when merging into master from the develop branch. Doing so would lose a lot of the history of the changes that have been made. For example, almost all the commits I make are tagged with an issue number, so that there is full trace-ability back through the git history into the issues that were raised, and why changes were made.

More to the point, you shouldn't be merging directly from develop into master. Assuming you are following git-flow, then this transition should be being done through a release branch.

If you had asked whether, when on a feature or hotfix branch, should the commits be squashed then that would have been a different answer. In these cases, arguably the branch should be small enough to warrant only a single commit, so in these situations, I almost always rebase and squash commits into a single one, prior to merging into the target branch.

Solution 2:

The master branch is used to maintain a record of releases, so each commit should represent a squashed set of changes from the development branches that made up the release build.

Squashing the commits makes it much easier to see what changes went into a release and to create hotfix branches from a release commit when necessary. Tag each squashed commit with the release version number.

Solution 3:

If you squash merge between develop, a release branch and master it gets very hard to merge a change to a release branch back to develop without file conflicts. It's also hard to merge a hotfix to develop, then merge develop through a release back to master later.