diff --git a/_quarto.yml b/_quarto.yml
index 236ed45..1a42ad8 100644
--- a/_quarto.yml
+++ b/_quarto.yml
@@ -18,6 +18,7 @@ book:
     - index.qmd
     - contributing.qmd
     - style.qmd
+    - gitflow.qmd
     - part: codereview.qmd
       chapters:
         - codereview-dasl.qmd
diff --git a/gitflow.qmd b/gitflow.qmd
new file mode 100644
index 0000000..e3edcd7
--- /dev/null
+++ b/gitflow.qmd
@@ -0,0 +1,57 @@
+# Gitflow {{< iconify fa6-solid code-branch >}} {#sec-gitflow}
+
+[Git][git] is the version control system that underlies GitHub. Gitflow is an alternative git branching model that uses feature branches and multiple primary branches (vs one primary branch, e.g., "main").
+
+Gitflow was originally proposed by [Vincent Driessen in 2010 on his blog][gitflowblog]. [A tutorial][gitflowtut] by the tech company Atlassian has a nice overview of Gitflow.
+
+In Gitflow there are two primary branches: `main` and `dev` (see diagram below). Feature branches always branch off of `dev`. After feature branches merge back into `dev`, then `dev` is merged into `main`.
+
+```{mermaid}
+%%{init: { 'logLevel': 'debug', 'theme': 'default', 'themeVariables': {
+  'git0': '#57bfd3',
+  'git1': '#5F9157',
+  'git2': '#f4b840',
+  'git3': '#D26D6D'
+} } }%%
+gitGraph
+   commit tag: "v1.0"
+   commit
+   branch dev
+   checkout dev
+   commit
+   branch feature1
+   checkout feature1
+   commit
+   commit
+   checkout dev
+   branch feature2
+   checkout feature2
+   commit
+   commit
+   checkout dev
+   merge feature1
+   checkout main
+   merge dev
+   commit tag: "v2.0"
+```
+
+There are formal tools for using a Gitflow model, e.g., [nvie/gitflow](https://github.com/nvie/gitflow). However, we aren't using that tool or any others at the moment.
+
+There is one component of Gitflow that we do not use right now: release branches.
+
+## Further reading
+
+(Taken from <https://github.com/nvie/gitflow>)
+
+Reading: <http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/>
+
+Screen casts:
+
+* [How to use a scalable Git branching model called git-flow](http://buildamodule.com/video/change-management-and-version-control-deploying-releases-features-and-fixes-with-git-how-to-use-a-scalable-git-branching-model-called-gitflow) (by Build a Module)
+* [A short introduction to git-flow](http://vimeo.com/16018419) (by Mark Derricutt)
+
+
+
+[git]: https://git-scm.com/
+[gitflowblog]: https://nvie.com/posts/a-successful-git-branching-model/
+[gitflowtut]: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
diff --git a/maintenance.qmd b/maintenance.qmd
index 80caf46..33af8b7 100644
--- a/maintenance.qmd
+++ b/maintenance.qmd
@@ -92,7 +92,7 @@ Overall the branching lifecycle can be summed up by the following:
 4. Whenever project leads want to create a new release, they merge the `dev` branch into the `main` branch and tag a new release.
 5. Urgent fixes to the `main` branch can be made by creating a branch from `main` that begins with the hotfix- prefix, which is then merged directly into `main` via pull request and code review. The `dev` branch will then be updated to reflect the changes on `main` via pull request. We should do our best to avoid this pattern. Since this changes the `main` branch, there will be a new tagged release.
 
-We try to follow the principles set out in [Git Flow](https://nvie.com/posts/a-successful-git-branching-model/) with a few modifications:
+We try to follow the principles set out in Gitflow (@sec-gitflow) with a few modifications:
 
   - We use the `main` branch instead of the `master` branch, and we use the `dev` branch instead of the `develop` branch.
   - We don’t use release branches, we create release tags from the `main` branch. Therefore we shouldn’t use the `release-` prefix at all.