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
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.