chore(rover): adds step to fetch updated tags before a release (#410)

Co-authored-by: Irina Shestak <shestak.irina@gmail.com>

Author: EverlastingBugstopper

RELEASE_CHECKLIST.md

@@ -18,7 +18,6 @@ If you are releasing a beta or a release candidate, no official changelog is nee
 1. Go through the closed PRs in the milestone. Each should have a changelog
    label indicating if the change is documentation, feature, fix, or maintenance. If
    there is a missing label, please add one. If it is a breaking change, also add a changelog - BREAKING label.
-1. Choose an emoji for the release. Try to make it semi-related to something that's been included in the release.
 1. Add this release to the `CHANGELOG.md`. Use the structure of previous
    entries.
 
@@ -52,6 +51,7 @@ This part of the release process is handled by GitHub Actions, and our binaries
 
 1. Have your PR merged to `main`.
 1. Once merged, checkout `main` branch locally and pull latest changes.
+1. Sync your local tags with the remote tags by running `git tag -d $(git tag) && git fetch --tags`
 1. Tag the commit by running either `git tag -a v#.#.# -m "#.#.#"` (release), or `git tag -a v#.#.#-rc.# -m "#.#.#-rc.#"` (release candidate)
 1. Run `git push --tags`.
 1. Wait for CI to pass.
@@ -63,7 +63,7 @@ After CI builds the release binaries and they appear on the [releases page](http
 #### If this is a stable release (not a release candidate)
 
 1. Paste the current release notes from `CHANGELOG.md` into the release body.
-1. Update the *title* of the release (not the tag itself) to include the emoji for the current release
+1. Update the _title_ of the release (not the tag itself) to include the emoji for the current release
 1. Be sure to add any missing link definitions to the release.
 
 #### If this is a release candidate
@@ -96,7 +96,7 @@ We don't publish release candidates to crates.io because they don't (as of this
 
 Full releases are tagged `latest`. Release candidates are tagged `beta`. If for some reason you mix up the commands below, follow the troubleshooting guide.
 
-1. If this is a full release, `cd installers/npm && npm publish`. 
+1. If this is a full release, `cd installers/npm && npm publish`.
 1. If it is a release candidate, `cd installers/npm && npm publish --tag beta`
 
 ## Troubleshooting a release
@@ -107,49 +107,49 @@ Mistakes happen. Most of these release steps are recoverable if you mess up.
 
 Tags and releases can be removed in GitHub. First, [remove the remote tag](https://stackoverflow.com/questions/5480258/how-to-delete-a-remote-tag):
 
-``` console
+```console
 git push --delete origin vX.X.X
 ```
 
 This will turn the release into a `draft` and you can delete it from the edit page.
 
 Make sure you also delete the local tag:
 
-``` console
+```console
 git tag --delete vX.X.X
 ```
 
 ## I forgot to add the `beta` tag to my RC when I ran `npm publish`
 
 Never fear! We can fix this by updating npm tags. First, add a beta tag for the version you just published:
 
-``` console
+```console
 npm dist-tag add @apollo/rover@x.x.x-rc.x beta
 ```
 
 once you add the beta tag, you can list your tags
 
-``` console
+```console
 npm dist-tag ls @apollo/rover
 ```
 
 You should now see two tags pointing to the version you just pushed; for example if you had tried to push v0.1.0-rc.0:
 
-``` console
+```console
 $ npm dist-tag ls @apollo/rover
 beta: 0.1.0-rc.0
 latest: 0.1.0-rc.0
 ```
 
 Go back to the Changelog or GitHub releases, find the _actual_ latest version, and re-tag it as latest:
 
-``` console
+```console
 npm dist-tag add @apollo/rover@x.x.x latest
 ```
 
 List tags again and you should see the latest restored, and your new release candidate as beta (e.g. 0.1.0-rc.0 is beta and 0.0.0 was last stable version)
 
-``` console
+```console
 npm dist-tag ls @apollo/rover
 beta: 0.1.0-rc.0
 latest: 0.0.0