1. 5
  1.  

  2. 4

    I wouldn’t be particularly interested in anything on this domain, or about a specific branching strategy, but:

    One common problem with branching is that folks decide on an approach without discussing it. By the time a Pull Request is opened, time has been invested in a solution that may be sub-optimal.

    Yeah, this really hit home with me. Every team I’ve been on has taken PRs totally for granted. But it’s true that this often arises. Every engineer I’ve worked with has at least some of the time leaned on the creation of a PR as a shortcut to replace asking how we should implement something, or to suggest an approach - sometimes a really big one - and then we’ve all felt the pressure to honor their sunk cost by merging. Could PR approval itself be something to do away with?

    1. 2

      I think it depends on how large PRs normally are. I’ve seen shops where it’s not uncommon to have PRs be dozens of commits and a hundred files. That’s too large. That’s way too large. But a single commit and a handful of files? That’s an acceptable amount of work for somebody to commit to without oversight. That could be as little as 30 minutes or as much as a day, and either way I’m okay with there not needing to be a discussion prior to putting the work together.

      This isn’t a problem of PRs. It’s a problem of team culture.