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.
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