EarJava@lemmy.fmhy.ml to Programmer Humor@programming.dev · 1 year agoApproved!lemmy.fmhy.mlimagemessage-square35fedilinkarrow-up1126arrow-down10cross-posted to: [email protected]
arrow-up1126arrow-down1imageApproved!lemmy.fmhy.mlEarJava@lemmy.fmhy.ml to Programmer Humor@programming.dev · 1 year agomessage-square35fedilinkcross-posted to: [email protected]
minus-squareAsifall@lemmy.worldlinkfedilinkarrow-up2·1 year agoThat can lead to another problem though, which is that if a developer knows a merge is only part of the whole change, it becomes easy to assume any issues will be handled elsewhere.
minus-squarelearningduck@programming.devlinkfedilinkarrow-up2·1 year agoHow do you improve on this? 1 bigger PRs, but with multiple smaller commits, so reviews can review by commits?
That can lead to another problem though, which is that if a developer knows a merge is only part of the whole change, it becomes easy to assume any issues will be handled elsewhere.
How do you improve on this?
1 bigger PRs, but with multiple smaller commits, so reviews can review by commits?