...
Branching is kept simple; there is no
developbranch or any release branches. The golden rule is thatmastermust always be in a production-ready state.Why? A code repository is meant for code, and continuous integration tools are meant for release management. While you can get creative with branching, mixing responsibilities creates a lot of unnecessary overhead and provides a false sense of security for developers to merge incomplete work.
Play is a full-stack team working in a monorepo with JIRA stories designed to be completed within a single branch for all components (API, apps, etc).
The goal is to be able to review a single pull request and be able to checkout and test that branch and easily. We want to be fully confident that the a branch is ready to be merged and the story is able to be considered done and so it can be shipped and we can move onto the next big thing.
Depending on the nature of the work, we may decide to gate functionality behind flags. This allows us to finely manage releases in the deployment process.
Some work inevitably needs to be done in stages, as we need to break up epics into more manageable stories. If it doesn’t make sense to expose a feature to users early on, or we only want to expose it in staging initially, flags are a useful tool to manage this.
When working on a story/branch, open a draft pull request early on! Once you’ve completed development, you can mark it as ready for review.
This provides opportunities for early and continuous feedback on your work, or to share code you’re working on with others to ask for help and collaborate together.