Thoughts on mergingI often merge incomplete PRs.
When I code, I create a lot of commits. And when using pull requests, I create a lot of those too. Two dozen in a day would not be unusual.
This leads to some thought patterns that I think are interesting.
Back in the day when I worked on days- or weeks-long feature branches, I would spend a lot of time making sure my PR was “perfect.” I’d address every comment in great detail. I only merged every few days or weeks, so I wanted to make it count.
Now that I’m creating dozens of commits/PRs per day, my thought process is often different. I often merge, knowing the PR is incomplete, instead prefering a follow-up pull request.
One of the problems with pull requests is that they often serve as a bottleneck to flow. So when I have a PR that is deemed incomplete, either by me, or by a reviewer, as long as it’s not broken, I’ll often merge it even in the incomplete state. Then I’ll submit a follow-up PR a moment later addressing the concerns.
I’d be curious to hear from you: How do you decide when to merge a pull request? Are you striving for micro-PRs?
Commit your work daily, even if it's a WIP. Push it to the server. Open a pull request. Don't be afraid of sharing your incomplete work.
Reader response: The downward spiral of manual acceptance testing
Lack of unit testing drives the need for manual testing. Since testing is bunched up, development is as well.
Improve your software delivery