3 ms·
It is not related to squashing or not. One of the main rule when using git (or any other VCS I guess) is that each commit should be atomic. IMO squashing commi
by FrankSansC 6y ago
It is not related to squashing or not. One of the main rule when using git (or any other VCS I guess) is that each commit should be atomic.
IMO squashing commits is something that you should do locally, not remotely. For example I'm currently debugging a fairly large C application on an embedded system. Each bug has it's own branch. When debugging / testing / trying to fix it I tend to do a lot of commits. When the bug is fixed I do an interactive rebase to pick / drop / squash commits in order to have only a clean one at the end (and then push it).
- kelchm 6y agoWhy do it locally when most modern repository software (GitHub, GitLab, BitBucket, etc) can do it for you when a PR is merged? My point of view is that if work is being done on an individual feature or bug fix, having a view of the individual commits might help give any reviewers important context on how a final solution was arrived at. It can also be helpful to be able to see the specific changes that have been made since a prior review. While in most cases I favor squashing commits when it comes time to merge into the parent branch, it seems like doing it manually just creates extra work and potentially throws away information that may have been useful to reviewers.