One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
git reset --soft is still my go-to solution, there is so much less opportunity to shoot yourself in the foot than git rebase --shit (not an actual git flag).
In practice, I almost always do that against origin/main to clean up the pull request
In this case, the complete workflow would be this:
git fetch
git merge origin/main
# if conflictsecho"resolve conflicts in your IDE"
git commit -a-m"resolve conflicts"# end if
git reset --soft origin/main
git commit -a-m"my commit message"
git push --force
That's it, the PR contains only one commit my commit message and the workflow is pretty much idiot proof.
I’m getting a lot of people all over the place say “why not rebase?” 😅 and the fact of the matter is this method is less scary and much more suited to my usual use cases. As you say, you’re much less likely to shoot yourself in the foot — meaning you won’t end up on a weird state of “in an interactive rebase and not know how to get out if you make a mistake”.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
Some people like powerful tools like can do everything. If something go wrong they will read the reference docs and the best practices and make sure they get it right the next time.
For me the most important feature is simplicity, which for practical purpose I would define as focusing on choosing good enough solutions that minimize the probability that things could go wrong.
The first set will always prefer git rebase and the second git reset --soft
Souvenir souvenir, this was my first article on this website actually :) dev.to/jmfayard/pull-requests-a-si...
git reset --softis still my go-to solution, there is so much less opportunity to shoot yourself in the foot thangit rebase --shit(not an actual git flag).In practice, I almost always do that against
origin/mainto clean up the pull requestIn this case, the complete workflow would be this:
That's it, the PR contains only one commit
my commit messageand the workflow is pretty much idiot proof.Oh, nice!
I’m getting a lot of people all over the place say “why not rebase?” 😅 and the fact of the matter is this method is less scary and much more suited to my usual use cases. As you say, you’re much less likely to shoot yourself in the foot — meaning you won’t end up on a weird state of “in an interactive rebase and not know how to get out if you make a mistake”.
It's a difference in mindset.
Some people like powerful tools like can do everything. If something go wrong they will read the reference docs and the best practices and make sure they get it right the next time.
For me the most important feature is simplicity, which for practical purpose I would define as focusing on choosing good enough solutions that minimize the probability that things could go wrong.
The first set will always prefer git rebase and the second git reset --soft
Absolutely! Well said!