Add images

website/docs/guides/orchestration/set-up-ci/2-quick-setup.md

@@ -13,6 +13,9 @@ As part of your initial dbt Cloud setup, you should already have Development and
 
 In this guide, we're going to add a **Staging environment**, where proposed changes can be validated in the context of the entire project without impacting production systems. We will use a single set of deployment credentials (like the Prod environment), but staging models are built in a separate location to avoid impacting others (like the Dev environment).
 
+Your git flow will look like this:
+<Lightbox src="/img/guides/best-practices/environment-setup/one-branch-git.png" title="git flow diagram" />
+
 ## Step 1: Create a new Staging environment
 
 See [Create a new environment](/docs/dbt-cloud-environments#create-a-deployment-environment). The environment should be called **Staging**. Just like your existing Production environment, it will be a Deployment-type environment.
@@ -40,10 +43,8 @@ That's it! There are other steps you can take to be even more confident in your
 
 To test your new flow, create a new branch in the dbt Cloud IDE then add a new file or modify an existing one. Commit it, then create a new Pull Request (not a draft). Within a few seconds, you’ll see a new check appear in your git provider.
 
-## Collaborate without conflicts
-
-Things to keep in mind when developing:
+## Things to keep in mind
 
-- If you commit new code while a CI run based on older code is in progress, it will be automatically canceled and replaced with the fresh code.
+- If you make a new commit while a CI run based on older code is in progress, it will be automatically canceled and replaced with the fresh code.
 - An unlimited number of CI jobs can run at once. If 10 developers all commit code to different PRs at the same time, each person will get their own schema containing their changes. Once each PR is merged, dbt Cloud will drop that schema.
 - CI jobs will never block a production run.

website/docs/guides/orchestration/set-up-ci/5-multiple-checks.md

@@ -18,6 +18,9 @@ This section assumes you already have the **Development**, **Staging** and **Pro
 
 In this section, we will add a new **Release** environment. New features will branch off from and be merged back into the associated `release` branch, and a member of your team (the "Release Manager") will create a PR against `main` to be validated in the Staging environment before going live.
 
+The git flow will look like this:
+<Lightbox src="/img/guides/best-practices/environment-setup/many-branch-git.png" title="git flow diagram with an intermediary branch" />
+
 ## Create a `release` branch in your git repo
 
 As noted above, this branch will outlive any individual feature, and will be the base of all feature development for a period of time. Your team might choose to create a new branch for each sprint (`release/sprint-01`, `release/sprint-02`, etc), tie it to a version of your data product (`release/1.0`, `release/1.1`), or just have a single `release` branch which remains active indefinitely.