We've long been advocates of short-lived developer branches that are merged frequently into the main code branch, which is kept ready for deployment. This practice of trunk-based development goes hand-in-hand with continuous integration and, when conditions permit, results in the fastest feedback cycles and most efficient developer flow. However, not everyone favors this approach, and we frequently adapt our style to accommodate our clients’ practices. Sometimes this includes long-lived feature branches followed by pull requests that must be manually reviewed and approved before they're merged into the main branch. In these situations, we use the new GitHub merge queue feature. It allows us to automatically queue up incoming pull requests and merge them into a special branch in the order they were received. We then have the option of automating our own "merge checks" to prevent incompatible commits. This essentially simulates trunk-based development (even though PRs have not been merged into the main code branch yet) and allows developers to test their features in context without having to wait for the pull request to be approved. With GitHub merge queue, you get the benefits of trunk-based development even when you're not able to fully commit to it.
