I like squash merge on small changes, but when larger code changes are there it becomes a huge commit which is difficult to review if you ever have to go back.
If the squash merge is too big to review then that change should have been broken up into multiple separate changes. Regardless whether you’re using pull requests or some equivalent or directly merging feature branches, if “one unit of work” is too much to review when squashed, then your unit of work is too big and needs to be split up. A unit of work should always be reviewable as a whole.
I like squash merge on small changes, but when larger code changes are there it becomes a huge commit which is difficult to review if you ever have to go back.
If the squash merge is too big to review then that change should have been broken up into multiple separate changes. Regardless whether you’re using pull requests or some equivalent or directly merging feature branches, if “one unit of work” is too much to review when squashed, then your unit of work is too big and needs to be split up. A unit of work should always be reviewable as a whole.
Right… for sure… but then if you don’t want to squash, then it doesn’t matter you can’t squash a merge commit.