Update template.md

Author: samselikoff

tests/dummy/app/pods/docs/deploying/template.md

@@ -4,13 +4,7 @@ Deploying your documentation site can involve a lot of moving parts, but Ember C
 
 Once everything is set up, you'll be able to visit <u>https://**[user]**.github.io/**[repo]**</u> to see the docs for the latest release of your addon, and your CI builds will automatically keep it up to date.
 
-- [Deployment Using `ember-cli-deploy`](#deployment-using-ember-cli-deploy)
-- [Versioning Your Content](#versioning-your-content)
-- [Automating Deploys](#automating-deploys)
-- [Customizing Deploys](#customizing-deploys)
-- [Removing a Deployed Version](#removing-a-deployed-version)
-
-## Deployment Using `ember-cli-deploy`
+## Deploying your docs site
 
 To deploy your docs site to GitHub pages, you'll need to go through a few steps of first-time setup:
 
@@ -42,29 +36,29 @@ Let's break down what each of those items is doing.
 
 If you were to make a change to your dummy app and run `ember deploy production` again right now, the entry for `[current-branch]` in `version.json` and the entire contents of the `[current-branch]` directory would be replaced with the updated version of your site. Next we'll talk about how to manage keeping published documentation around for multiple versions of your addon.
 
-## Versioning Your Content
+## Versioning your content
 
 Whenever you deploy your documentation site with Addon Docs, it places the compiled application in a subdirectory based on the current state of your git repository. All of this behavior [is customizable](#customizing-deploys), but we expect the out-of-the-box configuration should be a good place to get started.
 
-### Tag Deploys
+### Tag deploys
 
 When you run `ember deploy` at a commit that has a git tag associated with it, the app will wind up in a directory named after that tag. For example, if you've just published version 1.2.3 of your addon (creating tag `v1.2.3` in your git repository), your deployed site will be available at <u>https://**[user]**.github.io/**[repo]**/v1.2.3</u>.
 
 By default, deploying from a tagged commit also places a copy of your app under a special directory called `/latest`. As mentioned above, the `index.html` that Addon Docs sets up at the root redirects to `/latest`, so <u>https://**[user]**.github.io/**[repo]**</u> will always bring developers to the documentation for the most recent stable release of your addon.
 
 Note that this only applies to non-prerelease tags, so `v1.2.3` would update `/latest`, but `v2.0.0-beta.1` would not. Check out the documentation for [node-semver](https://github.com/npm/node-semver) for the exact details on what constitutes a prerelease version.
 
-### Branch Deploys
+### Branch deploys
 
 When you deploy from a commit at the head of a branch that _doesn't_ have a tag associated with it, the compiled app will land in a folder named after that branch, as in our "getting started" example above. Unlike tag deploys, branch deploys will never automatically update `/latest`.
 
 The main use case for branch deploys is tracking development work since your last stable release. If you run `ember deploy` after successful builds on `master`, you'll always have documentation available for the bleeding edge of your addon's features. Since branch deploys don't update `/latest`, though, developers looking at your docs will still hit your most recent stable tag by default, so there won't be any confusion about things that have drifted since the last release.
 
-## Automating Deploys
+## Automating deploys
 
 While you _can_ just run `ember deploy production` yourself after every commit to `master` and each new release of your addon, you can simplify life a bit by automating the process as part of your CI setup. The process described here details the configuration for [Travis CI](https://travis-ci.org/), which Ember addons are configured to work with out of the box, but the setup should be very similar for other CI providers.
 
-### Generate a Deploy Key
+### Generate a deploy key
 
 The first step you'll need to take is to generate a _deploy key_. This is a special SSH key that will only have write access to a single git repository: the one for your addon.
 
@@ -76,21 +70,21 @@ ssh-keygen -t rsa -b 4096 -N '' -f deploy_key
 
 This will produce two files in your current directory: `deploy_key` (the private key) and `deploy_key.pub` (the public key). **Do not commit these files to your repository.**
 
-### Configure the Public Key with GitHub
+### Configure the public key with GitHub
 
 On GitHub, open the page for your repo and navigate to _Settings_ -> _Deploy keys_ (or just directly visit <u>https://github.com/**[user]**/**[repo]**/settings/keys)</u> and click "Add deploy key".
 
 Enter a name for your key and then paste the contents of your public key (`id_rsa.pub`) into the big textarea. Make sure you check the **Allow write access** box, then click "Add key" and you're all set.
 
-### Configure the Private Key with Travis
+### Configure the private key with Travis
 
 Now that GitHub knows that this public key is allowed to push commits to your repo, we need to set up Travis to use the corresponding private key. Because the keyfile contains newlines, the easiest way to do this is using the [Travis CLI](https://github.com/travis-ci/travis.rb#installation) tool.
 
 ```sh
 travis env set -- DEPLOY_KEY "$(cat deploy_key)"
 ```
 
-### Deploy After Successful Builds
+### Deploy after successful builds
 
 All that's left now is to set up Travis to run your deploys for you. The simplest way to do this is to add this `after_success` script to the end of your `.travis.yml`:
 
@@ -111,7 +105,7 @@ stages:
     script: node_modules/.bin/ember deploy production
 ```
 
-## Customizing Deploys
+## Customizing deploys
 
 When you install Addon Docs, a `config/addon-docs.js` file will automatically be created for you that looks something like this:
 
@@ -149,7 +143,7 @@ If instead, however, you want to [set up a CNAME for your project](https://help.
 
 **Note**: if you change this configuration after you've already deployed copies of your docs site, you'll need to check out your `gh-pages` branch and find/replace your previous root URL in those copies in order for them to continue to function in their new location.
 
-## Removing a Deployed Version
+## Removing a deployed version
 
 Deploying a version of your documentation does two things: it copies the `dist` directory of your built docs app into a particular place on your `gh-pages` branch, and it adds or updates an entry in the `versions.json` manifest in the root of that branch. To remove a version, then, you just need to undo those two things.