Fix typos

Fix some typos and reword a few things.

docs/community/git-workflow.md

@@ -1,6 +1,6 @@
 # Git Workflow
 
-The general process for working with Polly is:
+Our recommended process for working with Polly is:
 
 1. [Fork](https://docs.github.com/get-started/quickstart/fork-a-repo) our repository on GitHub
 2. Clone your fork locally
@@ -20,26 +20,26 @@ For an introduction to Git, check out [GitHub's _Git Guide_](https://github.com/
 
 ## Handling Updates from the default branch
 
-While you're working away in your branch, it's possible that one or new commits have been added to the Polly repository's default branch. If this happens you should:
+While you're working away in your branch, it's possible that one or more new commits have been added to the repository's default branch. If this happens you shoul
 
 1. [Stash](https://git-scm.com/book/en/v2/Git-Tools-Stashing-and-Cleaning) any uncommitted changes you need to
 2. `git checkout main`
 3. `git pull upstream main`
 4. `git checkout my-branch`
 5. `git rebase main`
-6. [Sync your fork](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork) (optional) - this this makes sure your remote main branch is up to date
+6. [Sync your fork](https://docs.github.com/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork) (optional) - this makes sure your remote main branch is up to date
 
 This ensures that your history is "clean" i.e. you have one branch off from `main` followed by your changes in a straight line. Failing to do this ends up with several "messy" merges in your history, which we don't want. This is the reason why you should always work in a branch and you should never be working in, or sending pull requests from, `main`.
 
-Rebasing public commits is [considered to be bad](https://git-scm.com/book/en/v2/Git-Branching-Rebasing#The-Perils-of-Rebasing), which is why we ask you to rebase any updates from `upstream/main`.
+Rebasing public commits is [considered to be bad practice](https://git-scm.com/book/en/v2/Git-Branching-Rebasing#The-Perils-of-Rebasing), which is why we ask you to rebase any updates from `upstream/main`.
 
 If you're working on a long running feature then you may want to do this quite often, rather than run the risk of potential merge issues further down the line.
 
 ## Sending a Pull Request
 
-While working on your feature you may well create several branches, which is fine, but before you send a pull request you should ensure that you have rebased back to a single "Feature branch" - we care about your commits, and we care about your feature branch; but we don't care about how many or which branches you created while you were working on it.
+While working on your feature you may well create several branches, which is fine, but before you send a pull request you should ensure that you have rebased back to a single "feature branch" - we care about your commits, and we care about your feature branch; but we don't care about how many or which branches you created while you were working on it.
 
-When you're ready to go you should confirm that you are up to date and rebased with upstream (see _"Handling Updates from the default branch"_ above), and then:
+When you're ready to go you should confirm that you are up-to-date and rebased with upstream (see _"Handling Updates from the default branch"_ above), and then:
 
 1. `git push origin my-branch`
 1. Send a descriptive [Pull Request][create-a-pr] on GitHub - making sure you have selected the correct branch in the GitHub UI.