It's not as bad. Provided you keep reference to the PR number in the commit message. Luckily Github includes PR number into the commit message when merging automatically and in the github history it will even create a link directly to the PR. That way one does not lose the history of the PR itself, should anyone really need it.
It worked well with one team I was involved in.
Teaching good commit practices and using git to its full potential is doable, when majority of the team is already good with it and only some developers need help, if the whole team has problems with that, it's not so easy, the option to squash merge saves a lot of time.
Also helps to get rid of nasty merge commits of merging main branch into feature branch, if github is setup so that it requires the feature branch to have latest changes from main branch (which should be required). Rebasing would be preferable, but it's not as comfortable, because it will require new approval from your team, if your protected branches rules require an approval before merge (which it should).
I assume you are referring to the "Squash and merge" option on GitHub? If so, yes I 100% agree with you.
On the other hand, if you mean devs should not squash and rebase before pushing a PR, then I disagree.
PS. Some of the formatting in your post is off :) Around the last example with git
It's not as bad. Provided you keep reference to the PR number in the commit message. Luckily Github includes PR number into the commit message when merging automatically and in the github history it will even create a link directly to the PR. That way one does not lose the history of the PR itself, should anyone really need it.
It worked well with one team I was involved in.
Teaching good commit practices and using git to its full potential is doable, when majority of the team is already good with it and only some developers need help, if the whole team has problems with that, it's not so easy, the option to squash merge saves a lot of time.
Also helps to get rid of nasty merge commits of merging main branch into feature branch, if github is setup so that it requires the feature branch to have latest changes from main branch (which should be required). Rebasing would be preferable, but it's not as comfortable, because it will require new approval from your team, if your protected branches rules require an approval before merge (which it should).
by squash you mean collapse all commits into a single one? because i think that's wrong :)
I do think spending some time in
git rebase --interactive(ormagitin my case) makes a lot of sense, however.Yeah, totally agree!
No, that's not what I mean. I was confused if that was what you meant. I guess we're on same page :D