Native Android developer/Consultant for Appwise, I work on custom projects for clients.
PHP/JS (web) developer in my freetime. Trying to keep learning in an ever changing tech world.
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.
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.
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.
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.
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
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Why not use "Squash and merge"? It will automatically combine all commits into one and merge it.
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.
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
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.
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