Rewriting branching and hotfix patterns sections

public/docs/img/deployments/patterns/images/branching-diagram-with-ephemeral-environments.png.json

@@ -0,0 +1 @@
+{"width":2219,"height":1091}

public/docs/img/deployments/patterns/images/recommended-octopus-channels.png.json

@@ -0,0 +1 @@
+{"width":2033,"height":1055}

public/docs/img/deployments/patterns/images/recommended-octopus-lifecycles.png.json

@@ -0,0 +1 @@
+{"width":1951,"height":558}

src/pages/docs/releases/lifecycles/index.mdx

@@ -46,7 +46,7 @@ When adding an environment to a phase, you can choose whether you want deploymen
 
 1. If tenanted deployments are allowed, attempt to enqueue a new deployment for each tenant connected to the automatic-environment(s), taking the following into consideration:
    1. Filter the tenants by any Tenant filter defined on the Channel for the Release being considered for deployment.
-   2. Further, filter the tenants based on promotion rules (e.g. deploy to UAT before Production for this tenant)
+   2. Further, filter the tenants based on promotion rules (e.g. deploy to UAT before production for this tenant)
 2. If untenanted deployments are allowed, attempt to enqueue the untenanted deployment to the automatic-environment(s).
 
 ### Phases without environments
@@ -150,7 +150,7 @@ This phase has the default option to manually deploy to the environment set. The
 Phase names usually match the environment it contains. While this is a good practice, it's not a rule.
 :::
 
-You can repeat this process to create extra phases. In this example, we are creating a phase for Testing, Staging, and Production.
+You can repeat this process to create extra phases. In this example, we are creating a phase for testing, staging, and production.
 
 :::figure
 ![Default lifecycle phases added](/docs/img/releases/lifecycles/images/default-lifecycle-phases-added.png)
@@ -162,15 +162,18 @@ This allows you to explicitly configure the default lifecycle for deploying your
 
 In this section, we cover some lifecycle examples and their included phases.
 
-### Hotfix lifecycle
+### Default and release lifecycle
 
-A hotfix lifecycle is useful when you have a critical bug-fix that needs to be deployed quickly. In this scenario, lower environments such as Development and Testing are skipped.
+By default, Octopus Deploy will include all environments in the default lifecycle, for example, development → test → staging → production.  That only works if all changes are made directly on the main or primary branch and there are no other branches.
 
-It's recommended to follow good deployment practices and validate any changes before pushing them to production. To match this, a hotfix lifecycle usually has just two phases, Staging and Production. Software with the bug fix is validated in Staging and then promoted to Production. Your lifecycle may be different to reflect how you decide to handle hotfixes.
+However, most developers do their work in a branch and then merge those changes in via a pull request.  For that workflow, create two [lifecycles](/docs/releases/lifecycles/):
 
-:::figure
-![Hotfix lifecycle](/docs/img/releases/lifecycles/images/hotfix-lifecycle.png)
-:::
+- **Default:** development only
+- **Release:** test → staging → production
+
+**Disclaimer:** Include all static testing environments in the Release lifecycle required to reach production.  If only test → production are required, then only include two environments.  Never include the development environment.  Development is for testing changes from branches.
+
+The **Default** lifecycle represents unfinished work in a branch.  The **Release** lifecycle represents the main or primary branch.  Unfinished work should never have a path to production.  For more information please see [branching in Octopus Deploy](/docs/deployments/patterns/branching).
 
 ### Maintenance lifecycle
 
@@ -180,7 +183,7 @@ It's recommended to follow good deployment practices and validate any changes be
 
 A Maintenance lifecycle can be used for projects that run maintenance tasks such as backups or software upgrades. This lifecycle can be used for any tasks that you want to run regularly with the same benefits that Octopus provides for your application deployments.
 
-It typically consists of just one phase and one environment, also called Maintenance. You can include this environment in all deployment targets you want to run these tasks against. You can also split them up into the Development, Testing, Staging, and Production environments if you want to run the tasks for targets in those environments at different times.
+It typically consists of just one phase and one environment, also called Maintenance. You can include this environment in all deployment targets you want to run these tasks against. You can also split them up into the development, testing, staging, and production environments if you want to run the tasks for targets in those environments at different times.
 
 :::figure
 ![Maintenance lifecycle](/docs/img/releases/lifecycles/images/maintenance-lifecycle.png)