Pull-request merge process

When it's a fix or feature branch

If I consider that all commits of the branch are good (well named, concerns correctly separated) then I use the Rebase and merge option. All commits are merge into develop as is without creating a merge commit (they are put just after the last commit in develop).

In the other hand, if there are "Work in progress" (WIP) commits in the branch, or if I consider that all commits refer to the same fix/feature and should be grouped, I use the Squash and merge option. All commits are grouped in one commit and put in develop (still without creating a merge commit). The commit will default take the name of the pull-request but you can change it if needed.

Generaly, I consider that developers can do what they want in their fix/feature branches but have to name clearly and explicitly their pull-requests. It's the guy who merge the branch who have to take care about the commit naming convention.

When it's a release branch

I use the Create a merge commit but I change the name of the merge commit with, for exemple, v1.10.0 (12/Jun/18).

When it's master to develop

I use the Create a merge commit and I change the name of the merge commit with Merge branch master into develop.

Screenshot