diff --git a/src/content/daily-email/2023-09-26.md b/src/content/daily-email/2023-09-26.md
new file mode 100644
index 00000000..3e5f9322
--- /dev/null
+++ b/src/content/daily-email/2023-09-26.md
@@ -0,0 +1,36 @@
+---
+title: >
+  Which branch should be in which environment?
+pubDate: 2023-09-26
+permalink: >
+  archive/2023/09/26/which-branch-should-be-in-which-environment
+tags:
+  - software-development
+  - git
+  - trunk-based-development
+  - feature-flags
+---
+
+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.