Update branch and baseline docs

src/content/ci/azure-pipelines.md

@@ -311,7 +311,7 @@ If the builds are a result of direct commits to `main`, you will need to accept
 
 #### Azure squash/rebase merge and the "main" branch
 
-Azure's squash/rebase merge functionality creates new commits that have no association to the branch being merged. If you are already using this option, then we will automatically detect this situation and bring baselines over (see [Branching and Baselines](/docs/branching-and-baselines#squash-and-rebase-merging) for more details).
+Azure's squash/rebase merge functionality creates new commits that have no association to the branch being merged. If you are already using this option, then we will automatically detect this situation and bring baselines over (see [Branching and Baselines](/docs/branching-and-baselines#how-do-baselines-get-preserved-during-squash-and-rebase-merging) for more details).
 
 If you’re using this functionality but notice the incoming changes were not accepted as baselines in Chromatic, then you'll need to adjust the pipeline and include the `--auto-accept-changes` flag. For example:
 

src/content/ci/bitbucket-pipelines.md

@@ -232,7 +232,7 @@ If the builds are a result of direct commits to `main`, you will need to accept
 
 #### BitBucket squash/rebase merge and the "main" branch
 
-BitBucket's squash/rebase merge functionality creates new commits that have no association to the branch being merged. If you are already using this option, then we will automatically detect this situation and bring baselines over (see [Branching and Baselines](/docs/branching-and-baselines#squash-and-rebase-merging) for more details).
+BitBucket's squash/rebase merge functionality creates new commits that have no association to the branch being merged. If you are already using this option, then we will automatically detect this situation and bring baselines over (see [Branching and Baselines](/docs/branching-and-baselines#how-do-baselines-get-preserved-during-squash-and-rebase-merging) for more details).
 
 If you’re using this functionality but notice the incoming changes were not accepted as baselines in Chromatic, then you'll need to adjust the pipeline and include the `--auto-accept-changes` flag. For example:
 
@@ -296,7 +296,7 @@ Including the `--ignore-last-build-on-branch` flag ensures the latest build for
 
 #### BitBucket pipelines and patch builds
 
-If you're creating a [patch build](/docs/branching-and-baselines#patch-builds) in Chromatic to fix a missing pull request comparison, you'll need to adjust your existing pipeline to the following:
+If you're creating a [patch build](/docs/branching-and-baselines#what-happens-when-the-merge-base-build-isnt-found-patch-builds) in Chromatic to fix a missing pull request comparison, you'll need to adjust your existing pipeline to the following:
 
 ```yml
 # bitbucket-pipelines.yml

src/content/ci/circleci.md

@@ -234,7 +234,7 @@ If the builds are a result of direct commits to `main`, you will need to accept
 
 #### Squash/rebase merge and the "main" branch
 
-We use GitHub, GitLab, and Bitbucket APIs respectively to detect squashing and rebasing so your baselines match your expectations no matter your Git workflow (see [Branching and Baselines](/docs/branching-and-baselines#squash-and-rebase-merging) for more details).
+We use GitHub, GitLab, and Bitbucket APIs respectively to detect squashing and rebasing so your baselines match your expectations no matter your Git workflow (see [Branching and Baselines](/docs/branching-and-baselines#how-do-baselines-get-preserved-during-squash-and-rebase-merging) for more details).
 
 If you’re using this functionality but notice the incoming changes were not accepted as baselines in Chromatic, then you'll need to adjust the `chromatic` command and include the `--auto-accept-changes` flag. For example:
 

src/content/ci/custom-ci-provider.md

@@ -161,7 +161,7 @@ If the builds are a result of direct commits to `main`, you will need to accept
 
 #### Squash/rebase merge and the "main" branch
 
-We use GitHub, GitLab, and Bitbucket APIs respectively to detect squashing and rebasing so your baselines match your expectations no matter your Git workflow (see [Branching and Baselines](/docs/branching-and-baselines#squash-and-rebase-merging) for more details).
+We use GitHub, GitLab, and Bitbucket APIs respectively to detect squashing and rebasing so your baselines match your expectations no matter your Git workflow (see [Branching and Baselines](/docs/branching-and-baselines#how-do-baselines-get-preserved-during-squash-and-rebase-merging) for more details).
 
 If you’re using this functionality but notice the incoming changes were not accepted as baselines in Chromatic, then you'll need to adjust the `chromatic` command and include the `--auto-accept-changes` flag. For example:
 

src/content/ci/github-actions.md

@@ -535,7 +535,7 @@ If the builds result from direct commits to `main`, you must accept changes to k
 
 #### GitHub squash/rebase merge and the "main" branch
 
-GitHub's squash/rebase merge functionality creates new commits that have no association with the branch being merged. If you've enabled our GitHub application in the [UI Review](/docs/review) workflow, then we will automatically detect this situation and bring baselines over (see [Branching and Baselines](/docs/branching-and-baselines#squash-and-rebase-merging) for more details).
+GitHub's squash/rebase merge functionality creates new commits that have no association with the branch being merged. If you've enabled our GitHub application in the [UI Review](/docs/review) workflow, then we will automatically detect this situation and bring baselines over (see [Branching and Baselines](/docs/branching-and-baselines#how-do-baselines-get-preserved-during-squash-and-rebase-merging) for more details).
 
 If you’re using this functionality but notice the incoming changes were not accepted as baselines in Chromatic, then you'll need to adjust the workflow to include a new step with the `autoAcceptChanges` option. For example:
 

src/content/ci/gitlab.md

@@ -248,7 +248,7 @@ If the builds are a result of direct commits to `main`, you will need to accept
 
 #### GitLab squash/rebase merge and the "main" branch
 
-GitLab's squash/rebase merge functionality creates new commits that have no association to the branch being merged. If you are already using this option, then we will automatically detect this situation and bring baselines over (see [Branching and Baselines](/docs/branching-and-baselines#squash-and-rebase-merging) for more details).
+GitLab's squash/rebase merge functionality creates new commits that have no association to the branch being merged. If you are already using this option, then we will automatically detect this situation and bring baselines over (see [Branching and Baselines](/docs/branching-and-baselines#how-do-baselines-get-preserved-during-squash-and-rebase-merging) for more details).
 
 If you’re using this functionality but notice the incoming changes were not accepted as baselines in Chromatic, then you'll need to adjust the pipeline and include the `--auto-accept-changes` flag. For example:
 

src/content/ci/jenkins.md

@@ -317,7 +317,7 @@ If the builds are a result of direct commits to `main`, you will need to accept
 
 #### Squash/rebase merge and the "main" branch
 
-We use GitHub, GitLab, and Bitbucket APIs respectively to detect squashing and rebasing so your baselines match your expectations no matter your Git workflow (see [Branching and Baselines](/docs/branching-and-baselines#squash-and-rebase-merging) for more details).
+We use GitHub, GitLab, and Bitbucket APIs respectively to detect squashing and rebasing so your baselines match your expectations no matter your Git workflow (see [Branching and Baselines](/docs/branching-and-baselines#how-do-baselines-get-preserved-during-squash-and-rebase-merging) for more details).
 
 If you’re using this functionality but notice the incoming changes were not accepted as baselines in Chromatic, then you'll need to adjust the pipeline and include a new Chromatic stage using the `--auto-accept-changes` flag. For example:
 

src/content/ci/travisci.md

@@ -221,7 +221,7 @@ If the builds are a result of direct commits to `main`, you will need to accept
 
 #### Squash/rebase merge and the "main" branch
 
-We use GitHub, GitLab, and Bitbucket APIs respectively to detect squashing and rebasing so your baselines match your expectations no matter your Git workflow (see [Branching and Baselines](/docs/branching-and-baselines#squash-and-rebase-merging) for more details).
+We use GitHub, GitLab, and Bitbucket APIs respectively to detect squashing and rebasing so your baselines match your expectations no matter your Git workflow (see [Branching and Baselines](/docs/branching-and-baselines#how-do-baselines-get-preserved-during-squash-and-rebase-merging) for more details).
 
 If you’re using this functionality but notice the incoming changes were not accepted as baselines in Chromatic, then you'll need to adjust the workflow and include a new Chromatic job with the `--auto-accept-changes` flag. For example:
 

src/content/getStarted/test.md

@@ -7,7 +7,7 @@ sidebar: { order: 3, label: "UI Tests" }
 
 # UI Tests
 
-UI tests pinpoint visual changes and verify user [interactions](/docs/interactions). They capture a [snapshot](/docs/snapshots) of every story in a cloud browser environment. Whenever you push code, Chromatic generates a new set of snapshots and compares them against [baseline snapshots](/docs/branching-and-baselines#baselines). If there are changes, you verify that they're intentional. If there are test errors, you get notified to fix them.
+UI tests pinpoint visual changes and verify user [interactions](/docs/interactions). They capture a [snapshot](/docs/snapshots) of every story in a cloud browser environment. Whenever you push code, Chromatic generates a new set of snapshots and compares them against [baseline snapshots](/docs/branching-and-baselines#whats-a-baseline). If there are changes, you verify that they're intentional. If there are test errors, you get notified to fix them.
 
 ![UI test](../../images/workflow-uitest.png)
 

src/content/getStarted/workflow.md

@@ -33,7 +33,7 @@ We recommend running Chromatic on every push. This ensures that Chromatic is reg
 
 Each snapshot is associated with a commit. That enables you to pinpoint the particular commit where a change was introduced.
 
-It also allows you to [visualize baseline history](/docs/branching-and-baselines#visualize-baseline-history). You can review the commits to see how a component changes over time.
+It also allows you to [visualize baseline history](/docs/branching-and-baselines#how-do-i-visualize-baseline-history-for-a-story). You can review the commits to see how a component changes over time.
 
 Not running Chromatic on every commit makes it harder to review diffs and increases the risk of missing changes.
 
@@ -84,7 +84,7 @@ To debug, you can launch the published Storybook to reproduce the exact state of
 
 </details>
 
-UI Tests are similar to other types of testing (unit, E2E, etc.), in that they enable developers to catch and fix regressions. UI Tests compare the snapshot of a story with the previously accepted [baseline](/docs/branching-and-baselines#branches-and-baselines) in your git history (typically on the same branch). If there are changes, you'll get a diff of the changes. If the changes are intentional, press the accept button to update the baselines.
+UI Tests are similar to other types of testing (unit, E2E, etc.), in that they enable developers to catch and fix regressions. UI Tests compare the snapshot of a story with the previously accepted [baseline](/docs/branching-and-baselines#whats-a-baseline) in your git history (typically on the same branch). If there are changes, you'll get a diff of the changes. If the changes are intentional, press the accept button to update the baselines.
 
 Once all changes are approved, the UI is considered “ready” and you can move to the UI Review phase.