I've worked on two projects in the last six years that used PRs and had a high commit frequency. Two things had to work or we would have lost all our sanity po

I've worked on two projects in the last six years that used PRs and had a high commit frequency. Two things had to work or we would have lost all our sanity points (reference to Call of Chthulhu): automated checks of style, building, testing; and small PRs subscribing to the 'do one thing and do it well' approach. As for the second, it's more doable than you might think - if you decomposed your work well. We decomposed our work at these levels on one project: product, demo capability, epic, task; the other project used feature, epic, task. Typically PRs were at the task level, though sometimes at PR level. For us this had the added benefit that the developer velocity on these two projects exceeded the velocity of any of the other projects I've been on. Some other tricks we used were to make sure we rebased our task branches from develop every morning (and if needed after lunch); each task branch had 1 person only working on it; where complexity warranted we created an Epic-### branch for that epic and treated it as a mini-develop for tasks on that epic.