Big PRs are hard to review. Everybody knows that. I recently read two great articles (thanks @sandeep) and I want to summarize them here with some of my own thoughts. The articles are How to Scope Down PRs and An Opinionated Guide To Handling Pull Re...

Markdown supported Β· ββ΅ to post
Sandro Volpicella
We also love to ship as small and independant as possible. However not always possible, for instance a big new feature (standalone system for instance) how would you go about that?
(meaning the PR is still "small" but way bigger then just a couple of lines of code)
These are awesome tips Sandro Volpicella. My favourite are keeping PRs small and making sure they solve or add one functionality. This helps a lot, especially when you have issues in a particular PR, tracking or fixing it becomes easier, and if for some reason it breaks the codebase, git revert to the rescue. π
Thanks for the summary Sandro Volpicella. This is especially useful for me!
Gonna dig into the reference articles you provided as well!
Shad Mirza
Building Hashnode
Damn, I was writing a very similar piece. Gotta update my draft now π
Great read Sandro Volpicella