4 ms·
> you could make one PR per commit, and each one could be squashed onto the main branch (although a single commit squash doesn’t do much). You can then use git
by nemetroid 5y ago
> you could make one PR per commit, and each one could be squashed onto the main branch (although a single commit squash doesn’t do much). You can then use git bisect at a later time to find out which of those commits broke something.
You can, and I've tried doing this (both writing code and as a reviewer), but I've found it to mostly have disadvantages compared to a single merge request with all the commits:
* The reviewer gets less context for the earlier commits. Usually, a sequence of commits like this starts out by doing refactoring/redesigning of existing code, with the later commits adding new functionality. If the earlier commits add a new abstraction, it's much easier to evaluate if it's a good design or not if you get to see the actual use of the new abstraction (in the later commits).
* It takes more time, both for the reviewer and the submitter. For the reviewer, each "iteration" of the review might be shorter, but there will be more iterations in total, since they're only looking at a subset of the changes at once. If the reviewer only looks at merge requests a few times per day (to strike a balance between being responsive and avoiding interruptions), this translates to longer total time.
Sometimes it does make more sense to do. If the total set of changes is very large, it's probably a good idea to split it up (though not necessarily to single commits). Likewise, if your early commits make fundamental changes to the design of the code and might need a complete do-over after review, it might make more sense to present that part separately (though see the first item above). But in my experience, it usually just leads to more work and more context switching for everyone involved.
> If you make a series of smaller, but non-functional commits, you won’t be able to use git bisect no matter if you squash them or not.
I agree that this is the worst of all options.