1.6 KiB
| title | pubDate | permalink | tags | ||||
|---|---|---|---|---|---|---|---|
| Which branch should be in which environment? | 2023-09-26 | daily/2023/09/26/which-branch-should-be-in-which-environment |
|
A common question is which [Git] branch should be on which environment.
Most projects I've worked on have two or more environments: production, staging (or test) and development.
Earlier in my career, we used Git Flow heavily. A Git branching workflow based on having different branches - i.e. develop, master and any arbitrary short-lived feature, hotfix and release branches.
These matched nicely with our three environments.
Usually, the develop branch would be used in the development environment. The master branch would be on staging and a tagged release from master on production.
What about now?
I prefer trunk-based development, where there is one long-lived branch to which everyone commits their changes.
There's only one branch, so you can either follow continuous deployment and use the same branch for all environments - including production - or separate production using a dedicated branch or tag if you need more control.
The mainline branch is used in all pre-production environments, such as staging and development.
What about differences between the environments?
What if we need differences, such as a feature that must be enabled in a particular environment if the same code is on both?
My go-to approach is feature flagging, and this approach is something I'll describe more in tomorrow's email.