I’m guessing this is in reference to a scenario where a review of the PR has already been performed, and the rebase+force push is made to introduce new changes to the PR, possibly to address PR feedback.
I agree that these changes should be made in separate commits, for the benefit of the reviewer.
There are other scenarios where rebases are appropriate though, such as getting potentially incompatible changes from the main branch into the PR, and here I believe a rebase+force push is the right tool for the job.
Oh there’s totally a time and place for rebase strategies, this just wasn’t one of them.
Git’s biggest problems come from
people taking ritualistic views on what is “right” instead of thinking about which strategies work best for the situation, project, and team.
I’m guessing this is in reference to a scenario where a review of the PR has already been performed, and the rebase+force push is made to introduce new changes to the PR, possibly to address PR feedback.
I agree that these changes should be made in separate commits, for the benefit of the reviewer.
There are other scenarios where rebases are appropriate though, such as getting potentially incompatible changes from the main branch into the PR, and here I believe a rebase+force push is the right tool for the job.
Oh there’s totally a time and place for rebase strategies, this just wasn’t one of them.
Git’s biggest problems come from
people taking ritualistic views on what is “right” instead of thinking about which strategies work best for the situation, project, and team.