Fix shell-snippet formatting

Author: piki

_planetscale/docs/README.md

@@ -21,23 +21,36 @@ We do not need to keep both branches indefinitely.  Once we begin deploying imag
 [`planetscale/mysql-server`](https://github.com/planetscale/mysql-server) is a public member of the `mysql/mysql-server` network.  This is where GPL releases go.  The commits we push to this public fork are squashed and omit meaningful history.  This is a "code dumps" approach to open source.  Nothing at PlanetScale is built or deployed from this repo.
 
 The public repo has only one branch, `8.0`, which is a fork of the upstream `8.0` with our changes applied as squash merges.  Exclude PlanetScale-specific content when creating squash commits for the public repo.  For example:
-`git co -- README; rm -r .buildkite/ .dockerignore Dockerfile.* _planetscale/ build.sh docker-compose.yml`
+
+```sh
+git co -- README
+rm -r .buildkite/ .dockerignore Dockerfile.* _planetscale/ build.sh docker-compose.yml
+```
 
 The public repo has one tag per image that we have deployed broadly, with the format `8.0.23-ps1`.  In general, create a commit only when rolling out a new image, which means there will be one tag per commit.  The semver in each tag is the upstream version the build is based on.  The final number (`1` in `ps1`) in each tag is sequential and has no semantic (i.e., compatibility) meaning.
 
 # Developing
 
 Clone the private repository, which will be `origin`:
-`git clone [email protected]:planetscale/mysql-server-private`
+
+```sh
+git clone [email protected]:planetscale/mysql-server-private
+```
 
 Add remotes for the public and upstream repositories:
-`git remote add public [email protected]:planetscale/mysql-server`
-`git remote add upstream https://github.com/mysql/mysql-server`
+
+```sh
+git remote add public [email protected]:planetscale/mysql-server
+git remote add upstream https://github.com/mysql/mysql-server
+```
 
 Create your development branches and PRs off of `8.0.23`, for now.
 
 Create a local branch for public releases:
-`git fetch public 8.0:public-8.0`
+
+```sh
+git fetch public 8.0:public-8.0
+```
 
 Every PR gets built in CI and pushed to the ECR registry at `997601596833.dkr.ecr.us-east-1.amazonaws.com/branch/`.  These are candidate builds, and you can deploy them to individual database branches using the [admin](https://admin.planetscale.com/admin/) page. 
 
@@ -50,9 +63,12 @@ For more about container management, see [`registry.md`](registry.md).
 Anytime there are changes worth deploying, do an open-source code dump, and update all the release channels.
 
 For the open-source code dump, cherry-pick or squash-merge commits (minus PlanetScale-specific content) onto your `public-8.0` branch, and then push it and tag it:
-`git push public public-8.0:8.0`
-`git tag 8.0.NN-psN`
-`git push public 8.0.NN-psN`
+
+```sh
+git push public public-8.0:8.0
+git tag 8.0.NN-psN
+git push public 8.0.NN-psN
+```
 
 For the release channels, read the Vitess docs [here](https://coda.io/d/Vitess-Upgrades_dy3xDEfjOx5/Vitess-Upgrades_sui49), and do the MySQL equivalents.  In short, create an api-bb PR to update `MYSQLD_VERSIONS` in [`database_branch.rb`](https://github.com/planetscale/api-bb/blob/main/app/models/database_branch.rb#L174), disable the [`update_mysqld_image_version`](https://admin.planetscale.com/admin/feature-flags/update_mysqld_image_version) feature flag, merge the api-bb PR, and slowly increment the feature flag to 100%.  Normally, new code goes to the `next` channel only.  Repeat the process with `stable` and `oldstable` a day or a week later until all branches are running the desired version of MySQL.