DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Jonathan Hall
Jonathan Hall

Posted on • Originally published at jhall.io on

Thoughts on merging

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?


If you enjoyed this message, subscribe to The Daily Commit to get future messages to your inbox.

Top comments (0)

Timeless DEV post...

Git Concepts I Wish I Knew Years Ago

The most used technology by developers is not Javascript.

It's not Python or HTML.

It hardly even gets mentioned in interviews or listed as a pre-requisite for jobs.

I'm talking about Git and version control of course.