Continuous Delivery in the Wild

Chapter 2. Branch Management and Code Review

Continuous Delivery builds upon the practice of Continuous Integration, which is defined by the frequent integration of work into a shared branch (with “frequent” often interpreted as “at least daily.”¹) All participants I interviewed adhere to these principles, avoiding long-lived feature branches almost entirely.

However, many participants are not meeting the strict definition of Continuous Integration. Several reported that feature branches have a typical lifetime of a few days to a week before being integrated into their shared master branch.²

GitHub Flow

The majority of participants use a variant of the GitHub flow branching model.³ Engineers create a short-lived feature branch for each change they are implementing, and create a pull request (or merge request) once their work is ready to be integrated into master. That pull request typically also serves as a mechanism for coordinating code review. Once a change has been approved it is merged into master.

Participants using pull requests also typically leverage their Continuous Integration infrastructure to run premerge validation, running the same types of automated checks against the feature branch as they would run against master once the branch is merged. Feedback from these automated checks is then available for reviewers of the change within the pull request UI.

Trunk-Based Development

Some participants forgo the use of branches entirely and work directly on master, a practice ...