3 ms·
I’d do a git commit —amend instead of a rebase to keep the number of commits to 1
by gigatexal 4y ago
I’d do a git commit —amend instead of a rebase to keep the number of commits to 1
- e3bc54b2 4y agoThat is what I dislike about the Pull Request workflow. It encourages piling on commits, polluting commit log (not to mention useless merge commits). To this day I haven't found anything better than Gerrit for reviewing changes across iterations. I wish it makes a comeback on broader scale.
- saagarjha 4y agoPull requests are great, you just need to be mindful of what commits you're sending people. Every commit I put in a PR is a commit I made with intent. Just squashing them all does them a disservice.
- alexchamberlain 4y agoI don't know how many times I've said that reviewing the structure of the commits is part of a PR, just like reviewing the code. It seems to be a revelation.
- johnny22 4y agoluckily github can just squash it for you if you choose. You don't have to have a useless merge commit. The option is right there in the dropdown. I assume gitlab as well.
- meibo 4y agoIdeally your commits are squashed and then merged anyway, GitHub just still uses merge as a default since I assume it's the most "logical" to git newbies.
- Avamander 4y agoOnly a polluted commit history should be squashed - bad commit messages, incorrect segmentation, fixes to earlier commits etc. Think of it this way, if the commit works on its own it should remain as-is. If it's a hodgepodge of ten commits that inter-depend then they probably should be squashed.
- jrmurray 4y agoNot sure why I always forget amend exists. That is much cleaner