I'm sorry but I think this is a bit of a misleading advice, especially to juniors, unless you'll add a warning and caveats to the post.
Like others mentioned, I would not recommend this method unless you really know what you're doing and especially not in the scenario mentioned in the post (after someone already reviewed your PR once) because it will completely destroy the git history as the commit hashes change so GitHub can't connect the PR comments to their original location in the code and the PR comments are now "orphans" and confusing.
Instead, I'd personally recommend a fresh commit for fixing issues in a PR and when the time comes to land the PR to the main branch you can squash merge it in so the PR branches are "messy" and include lots of small meaningful commits while the main branch is clean and linear.
I will, however, definitely follow this advice in cases where you found issues with your code before you pushed it to the upstream branch. As a rule of thumb, if you'll need to force push the code I'd try to avoid this method unless you absolutely know what you're doing.
Thank you for sharing your thoughts and concerns. You've raised some important points that should definitely be considered when deciding how to manage your Git workflow, especially for juniors.
The suggestion of using fresh commits and squashing when merging is a sound practice, but it might not be the best fit for every project. Some teams prefer a more streamlined approach to maintain clarity in their commit history.
Ultimately, the decision should be based on a combination of factors, including project requirements, team consensus, and individual familiarity with Git practices. It's valuable to have a range of strategies in your Git toolkit to adapt to different situations.
There is no a silver bullet for each case, and it can lead to long discussion, with my article I wanted to add one more way how handled such cases.
Thank you again. I will consider to add a disclaimer in the article based on your comment
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.
I'm sorry but I think this is a bit of a misleading advice, especially to juniors, unless you'll add a warning and caveats to the post.
Like others mentioned, I would not recommend this method unless you really know what you're doing and especially not in the scenario mentioned in the post (after someone already reviewed your PR once) because it will completely destroy the git history as the commit hashes change so GitHub can't connect the PR comments to their original location in the code and the PR comments are now "orphans" and confusing.
Instead, I'd personally recommend a fresh commit for fixing issues in a PR and when the time comes to land the PR to the main branch you can squash merge it in so the PR branches are "messy" and include lots of small meaningful commits while the main branch is clean and linear.
I will, however, definitely follow this advice in cases where you found issues with your code before you pushed it to the upstream branch. As a rule of thumb, if you'll need to force push the code I'd try to avoid this method unless you absolutely know what you're doing.
Thank you for sharing your thoughts and concerns. You've raised some important points that should definitely be considered when deciding how to manage your Git workflow, especially for juniors.
The suggestion of using fresh commits and squashing when merging is a sound practice, but it might not be the best fit for every project. Some teams prefer a more streamlined approach to maintain clarity in their commit history.
Ultimately, the decision should be based on a combination of factors, including project requirements, team consensus, and individual familiarity with Git practices. It's valuable to have a range of strategies in your Git toolkit to adapt to different situations.
There is no a silver bullet for each case, and it can lead to long discussion, with my article I wanted to add one more way how handled such cases.
Thank you again. I will consider to add a disclaimer in the article based on your comment