I’ve been asked a lot of times about my process for submitting pull requests, so I figured I’d write it up!
First – A Few Caveats
- This is my style; yours might vary, and that’s fine! I think there are a lot of ways to do this well, and there’s no sense in being dogmatic about it.
- I don’t follow this 100% every time. I don’t think you have to do these things exactly in order to be successful. It’s better to adapt to your situation/context.
- I’m assuming you’re familiar with pull requests and how they work. If you’re not yet familiar with that, I recommend searching around and finding some great articles on that first, or some of the contents of this article might be confusing.
- This assumes you want pull requests. Many teams prefer to forego them because they feel they add unnecessary overhead. I disagree; I think they build historical context and communication skills that pay off in the long run. My point is, if you doubt pull requests in general, then this post isn’t for you.
Why Use Pull Requests at All?
I’m a big fan of working out loud. To me, pull requests represent a way of sharing your thoughts and code as early as possible. They also allow you to make notes on your thoughts as you go and make it easier for others to review. To be clear, I think that making things easier to review is great, but I think PRs are powerful even if there’s no review process in place.
Top comments (0)