This seems to be much more about pair programming than killing off code reviews. Yes, they eliminated code reviews, but even with pair programming, that isn't necessary. They are not opposites. One can still use feature branches with or without code review and do pair programming. I'd be interested to know if not branching led to any problems for the other teams and/or releases. Creating a branch with modern version control systems like git is a snap, so even if you're not going to do a code review, it still seems like a great idea to me, while committing directly to master does not seem to have any advantage whatsoever.
Working from master is partly related, because they dropped the PR-based workflow in favour of pairing.
At Pivotal Labs we use branches, but sparingly. We commit to master because we test-drive all our code. Tests are written, tests fail, code is written, tests pass, code is refactored, tests pass. Pull from master, resolve merges, run full suite, push if it passes, fix if it doesn't.
The onus is always on the pushing pair to ensure that they don't break master.
When you go off into long-running feature branches, additional work is required to integrate your changes -- so in practice it doesn't happen. You get a hidden cartesian join of different versions of the software, which makes integration testing substantially more difficult as schedule pressure builds up.
We keep the coordination cost down by simply disallowing divergence in the first place. Branches are reserved for WIPs and spikes.
Comments
This seems to be much more about pair programming than killing off code reviews. Yes, they eliminated code reviews, but even with pair programming, that isn't necessary. They are not opposites. One can still use feature branches with or without code review and do pair programming. I'd be interested to know if not branching led to any problems for the other teams and/or releases. Creating a branch with modern version control systems like git is a snap, so even if you're not going to do a code review, it still seems like a great idea to me, while committing directly to master does not seem to have any advantage whatsoever.
Working from master is partly related, because they dropped the PR-based workflow in favour of pairing.
At Pivotal Labs we use branches, but sparingly. We commit to master because we test-drive all our code. Tests are written, tests fail, code is written, tests pass, code is refactored, tests pass. Pull from master, resolve merges, run full suite, push if it passes, fix if it doesn't.
The onus is always on the pushing pair to ensure that they don't break master.
When you go off into long-running feature branches, additional work is required to integrate your changes -- so in practice it doesn't happen. You get a hidden cartesian join of different versions of the software, which makes integration testing substantially more difficult as schedule pressure builds up.
We keep the coordination cost down by simply disallowing divergence in the first place. Branches are reserved for WIPs and spikes.