4 ms·
This to me seems more like a logical separation than anything technical. I use GitHub and always squash commits before merging a PR. This keeps the commit log
by leifg 5y ago
This to me seems more like a logical separation than anything technical.
I use GitHub and always squash commits before merging a PR. This keeps the commit log clean and also has the side effect that you have the PR number in the merge commit.
Having said that I also suggest keeping PRs small. If you are going to reformat a code base, make that a separate commit. Updating a library, separate commit. Adding a library you need for a new feature: create a PR for the library update, base your implementation off that branch and rebase against main when the first PR is merged.
- dnilasor 5y ago+1 to keeping PRs small. This makes it much more logical to me. But I have worked at organizations where this is frowned upon...teams liked the PRs to be one logical unit/fix/improvement and component parts became frustrating or got merged at different times, creating the need for rework. From reading a lot of feedback on this post one thing that stands out is, the best way to use git just depends on the context. But it doesn't hurt to have commands like this in your toolbox and know how to use the tool well. Plus we all have our private, icky antipatterns that we know we should improve, right?
- hcarvalhoalves 5y agoI dislike the rule of "small PRs" because people tend to interpret it as "arbitrary number of lines changed", and end up breaking a bugfix or feature into many PRs that don't make sense to review or release in isolation. I interpret "small PRs" as being "PRs should be about one bugfix/feature".
- okl 5y agoSquashing commits is something lazy people do! :P