Thanks for taking the time Dan.
That's an interesting point regarding setting boundaries for when code should be integrated. Before I switched to PRs, I found that there was often commits to pull - as in, when I got to a point with what I was working on and looked at Source Tree (other Git clients are available) there was a number of commits ready for me to pull. This made me feel compelled to pull them (it felt dirty not having them), and therefore integrate the latest changes with what I was working on.
Although when working on a separate branch I can effectively do the same as it will tell me there are commits on the mainline I can pull & merge into my branch - I don't feel that compulsion as much for some reason; I'm more comfortable to leave it longer. Maybe that's because it's more slightly effort - I need to switch to the mainline, pull, switch back to my branch, then merge. It's not a huge difference, but maybe enough to discourage/delay it.
On the flip side in terms of pushing, because there is an ever increasing number upstream commits showing, it's a reminder to me that if I let that number get too big, the greater chance I have of facing a merge conflict. This encouraged me to rap up a unit of functionality and integrate it.
So what I'm getting at is, whilst there was no hard-line boundary or stopwatch ticking for when you must integrate, the nature of the process sort of 'manipulates' my behaviour and encourages me to divide work up into small chunks and to integrate it regularly.
The issue of trust is indeed interesting. My team sounds much like yours - we have a decent bond and trust one another. PRs haven't been an issue for us in that regard; we're always grateful for suggestions/corrections added as PR comments. In fact it's because we have trust that I think we should look to "kick-on" and try to get productivity gains without using PRs. But I have seen PRs in other teams I've been privy to turn into what can only be described as "flame wars". That isn't the fault of pull requests obviously, PRs can't be blamed for a dysfunctional team, but I feel they won't help and encourage trust develop where other methods might.
With regards to automated tests - I think many people would argue it's just as natural to execute them after committing to the mainline (with or without a PR). But this is essentially the trade-off that comes with PRs; you either have the checks done at the point of a PR to mitigate against a broken mainline but at the expense of flow & productivity, or you favour productivity and trust/assume the developer's commit is good and validate it afterwards, only stopping flow if it transpires there is a failure.
