DEV Community

Discussion on: A cleaner Github workflow: one commit per Pull Pequest

Collapse
amalv profile image
amalv Author

I'm glad you asked that question, I had exactly the same doubt when I started doing this workflow, so after researching a little I found this explanation from stackoverflow:

Merge commits
Will keep all commits history of the feature branch and move them into the master branch
Will add extra dummy commit.

Rebase and merge
Will append all commits history of the feature branch in the front of the master branch
Will NOT add extra dummy commit.

Squash and merge
Will group all feature branch commits into one commit then append it in the front of the master branch
Will add extra dummy commit.

Here is the link:

stackoverflow.com/questions/242723...

So, doing "squash and merge" instead of "rebase and merge", it seems that adds an extra dummy commit. I don't see a downside for using "rebase and merge" instead.

Collapse
rhymes profile image
rhymes

At DEV we use "squash and merge". People write their commits on their branches, then they submit the PR (rebased or not, depending on the situation or possible conflicts), when it's ready the title of the PR or an edited title will be the final and only commit.

If you look at the list of commits on master you can see how there's only one commit per PR

Thread Thread
amalv profile image
amalv Author

Thanks for the clarification rhymes, that's good to know. I will try this approach in my next public repository project, it seems that in both cases there is only one commit in the end but may be using "squash and merge" you can avoid the manual rebase step if there are no conflicts.

Thread Thread
rhymes profile image
rhymes

Yeah that's it. We only rebase if we need to bring in changes from master or if there's a conflict, but conflicts can be solved merging without rebasing as the final commit will be squashed anyway