Even though we strongly advocate in favor of CI rather than Gitflow, we know that committing straight to the trunk and running the CI on a master branch can be ineffective if the team is too big, the builds are slow or flaky, or the team lacks the discipline to run the full test suite locally. In this situation a red build can block multiple devs or pairs of devs. Instead of fixing the underlying root cause — slow builds, the inability to run tests locally or monolithic architectures that necessitate many people working in the same area — teams usually rely on feature branches to bypass these issues. We discourage feature branches, given they may require significant effort to resolve merge conflicts, and they introduce longer feedback loops and potential bugs during conflict resolution. Instead, we propose using preflight builds as an alternative: these are pull request–based builds for “micro branches” that live only for the duration of the pipeline run, with the branch opened for every commit. To help automate this workflow, we've come across bots such as Bors, which automates merging to master and branch deletion in case the mini branch build succeeds. We're assessing this flow, and you should too; but don't use this to solve the wrong problem, as it can lead to misuse of branches and may cause more harm than benefit.
