fix typo

docs/tools/github/Reverting-in-main-with-an-integration-branch.md

@@ -12,11 +12,11 @@ In the event it is not an emergency and you've got some code that got pushed to
 The best approach is to open a new branch with a base of main, create a single commit that is the revert of your merge to main `git revert ${sha}`, and then push. Now create a new branch with a base of integration, merge your "-main" branch you just created in to preserve the git history. **DO NOT CHERRY PICK THIS COMMIT**. Then make a new pull request to the integration environment with that single commit. Then advise the developer channel (not just your team) that you need to get a revert to main and need to get it through integration first. Once approved and your revert is in the integration branch, immediately open up a similar pull request to main with that branch you initially made.
 
 ## How does this work
-If you were to revert from main first and not integration under the assumption that since it's in integration it's fine, it doesn't need to be reverted there, then the moment another developer merges their main branch into their integration branch things will begin to fall apart. At worst it will pull in your revert and break everything in integration, or at best cause annoying merge conflicts not just for one developer, but any and all developers actively merging main to integration before as resolution has been pushed.
+If you were to revert from main first and not integration under the assumption that since it's in integration it's fine, it doesn't need to be reverted there, then the moment another developer merges their main branch into their integration branch things will begin to fall apart. At worst it will pull in your revert and break everything in integration, or at best cause annoying merge conflicts not just for one developer, but any and all developers actively merging main to integration before a resolution has been pushed.
 
 By making a revert on main and merging it into integration, you are getting ahead of the conflicts and saving other developers while preserving git history.
 
 This cleans the slate of any faulty code and allows you, as the developer, to make a new branch that will re-enable your code and introduce fixes for the deployment pipeline.
 
 ## How to re-enable what you reverted
-Just like how you reverted the code in the first place, revert your revert and push it through the pipeline. If you need to fix your code, your first commit in your development branch will be `git revert ${sha}`, with that sha being your initial revert. This reintroduces your changes while preserving git history. Then your new branch will start with re-enabling the code that was removed, then followed by commits that fix whatever was broken.
+Just like how you reverted the code in the first place, revert your revert and push it through the pipeline. If you need to fix your code, your first commit in your development branch will be `git revert ${sha}`, with that sha being your initial revert. This reintroduces your changes while preserving git history. Then your new branch will start with re-enabling the code that was removed, then followed by commits that fix whatever was broken.