Skip to content

Instantly share code, notes, and snippets.

@roparz

roparz/README.md

Last active June 13, 2018 17:09
Show Gist options
  • Save roparz/9994b31baf201937febb7c37d0d50ac0 to your computer and use it in GitHub Desktop.
Save roparz/9994b31baf201937febb7c37d0d50ac0 to your computer and use it in GitHub Desktop.
Download ZIP
Pull-request merge process
Raw
README.md

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

capture d ecran 2018-06-13 a 15 03 49

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment