Line edits

Author: lootle1

learn-pr/azure-devops/implement-code-workflow/includes/2-choose-a-code-flow-strategy.md

@@ -54,7 +54,7 @@ What's cool about Azure DevOps is that it works well both with centralized versi
 
 ## How do I work with Git?
 
-**Mara:** Like I mentioned before, with distributed systems, developers are free to access any file they need without affecting other developers' work, because they have their own copy of the repository. A _clone_ is your local copy of a repository.
+**Mara:** Like I mentioned before, with distributed systems, developers are free to access any file they need without affecting other developers' work because they have their own copy of the repository. A _clone_ is your local copy of a repository.
 
 When we work on a feature or a bug fix, we usually want to try out different approaches until we find the best solution. However, trying out code on your copy of the main code base isn't a good idea, because you might not want to keep the first few tries.
 
@@ -94,7 +94,7 @@ Before you make changes to a file, you check out a new branch so that you know y
  :::row:::
     :::column span="8":::
 **Step 3**:
-You're now safe to make whatever changes you want, because these changes are only in your branch. As you work, you can _commit_ your changes to your branch to ensure that you don't lose any work, and to provide a way to roll back any changes you've made to earlier versions. Before you can commit changes, you need to stage your files so that Git knows which ones you're ready to commit.
+You're now safe to make whatever changes you want because these changes are only in your branch. As you work, you can _commit_ your changes to your branch to ensure that you don't lose any work. This also provides a way to roll back any changes you've made to earlier versions. Before you can commit changes, you need to stage your files so that Git knows which ones you're ready to commit.
     :::column-end:::
     :::column:::
         :::image type="content" source="../media/2-github-paths-3.png" border="false" alt-text="Diagram of the commits being made to the local branch.":::
@@ -112,7 +112,7 @@ The next step is to _push_, or upload, your local branch up to the remote reposi
 :::row:::
     :::column span="8":::
 **Step 5**:
-This step is a common one, but not required. When you're satisfied that your code is working as you want it to, you can _pull_, or merge, the remote `main` branch back into your local `main` branch. Changes have been taking place there that your local `main` branch doesn't have yet. After you've synchronized the remote `main` branch with yours, merge your local `main` branch into your working branch and test your build again.
+This step is a common one but not required. When you're satisfied that your code is working as you want it to, you can _pull_, or merge, the remote `main` branch back into your local `main` branch. Changes have been taking place there that your local `main` branch doesn't have yet. After you've synchronized the remote `main` branch with yours, merge your local `main` branch into your working branch and test your build again.
 
 This process helps ensure that your feature works with the latest code. It also helps ensure that your work will integrate smoothly when you submit your pull request.
     :::column-end:::

learn-pr/azure-devops/implement-code-workflow/includes/3-set-up-environment.md

@@ -27,7 +27,7 @@ To run the template, on the Azure DevOps Demo Generator site, do the following:
 1. Select **Yes, I want to fork this repository**, then select **Authorize**. If a window appears, authorize access to your GitHub account.
 
     > [!IMPORTANT]
-    > You need to select this option for the template to connect to your GitHub repository. Select it even if you've already forked the _Space Game_ website project. The template uses your existing fork.
+    > You need to select this option for the template to connect to your GitHub repository. Select it even if you've already forked the *Space Game* website project. The template uses your existing fork.
 
 1. Select **Create Project**.
 
@@ -43,7 +43,7 @@ To run the template, on the Azure DevOps Demo Generator site, do the following:
 
 ## Move the work item to Doing
 
-In this section, you'll assign yourself a work item that relates to this module on Azure Boards. You'll also move the work item to the **Doing** state. In practice, you and your team would create work items at the start of each sprint, or work iteration.
+In this section, you'll assign yourself a work item that relates to this module on Azure Boards. You'll also move the work item to the **Doing** state. In practice, you and your team would create work items at the start of each sprint or work iteration.
 
 Assigning work in this way gives you a checklist from which to work. It gives others on your team visibility into what you're working on and how much work is left. It also helps the team enforce work in process (WIP) limits so that the team doesn't take on too much work at one time.
 

learn-pr/azure-devops/implement-code-workflow/includes/4-create-pull-request.md

@@ -8,7 +8,7 @@ Recall that a *pull request* tells the other developers that you have code ready
 
 Before we start, let's check in with Mara and Andy.
 
-**Andy:** Hi, Mara. I know you've got a build pipeline running on Azure. I'm adding a feature to the website and I want to see the build process for myself. Are we ready to do that?
+**Andy:** Hi, Mara. I know you've got a build pipeline running on Azure. I'm adding a feature to the website, and I want to see the build process for myself. Are we ready to do that?
 
 **Mara:** Absolutely. I created the pipeline on a branch. Why don't we create a pull request and get it merged into `main` so you can use the pipeline, too?
 
@@ -167,7 +167,7 @@ Here, you'll create a pull request for your branch:
 
     :::image type="content" source="../media/4-github-delete-branch.png" alt-text="Screenshot of GitHub showing the location of the Delete branch button.":::
 
-    It's completely safe to delete a branch from GitHub after you've merged your pull request. In fact, it's a common practice, because the branch is no longer needed. The changes are merged and you can still find the details about the changes on GitHub or from the command line. Deleting a merged branch also helps others see only the work that's currently active.
+    It's completely safe to delete a branch from GitHub after you've merged your pull request. In fact, it's a common practice, because the branch is no longer needed. The changes are merged, and you can still find the details about the changes on GitHub or from the command line. Deleting a merged branch also helps others see only the work that's currently active.
 
     Git branches are meant to be short-lived. After you merge a branch, you don't push additional commits onto it or merge it a second time. In most cases, every time you start on a new feature or bug fix, you start with a clean branch that's based on the `main` branch.
 

learn-pr/azure-devops/implement-code-workflow/includes/5-push-a-change.md

@@ -5,12 +5,12 @@ Mara has been given the task of changing some text on the home page of the websi
 Let's briefly review the steps to follow to complete the task:
 
 > [!div class="checklist"]
-> * Synchronize your local repository with the latest `main` branch on GitHub
-> * Create a branch to hold your changes
-> * Make the code changes you need, and verify them locally
-> * Push your branch to GitHub
-> * Merge any recent changes from the `main` branch on GitHub into your local working branch, and verify that your changes still work
-> * Push up any remaining changes, watch Azure Pipelines build the application, and submit your pull request
+> * Synchronize your local repository with the latest `main` branch on GitHub.
+> * Create a branch to hold your changes.
+> * Make the code changes you need, and verify them locally.
+> * Push your branch to GitHub.
+> * Merge any recent changes from the `main` branch on GitHub into your local working branch, and verify that your changes still work.
+> * Push up any remaining changes, watch Azure Pipelines build the application, and submit your pull request.
 
 ## Fetch the latest main branch
 
@@ -71,7 +71,7 @@ You should see this:
 
 You can interact with the page, including the leaderboard. When you select a player's name, you see details about that player.
 
-When you're finished, return to the terminal window and select <kbd>Ctrl+C</kbd> to stop the running application.
+When you're finished, return to the terminal window, and select <kbd>Ctrl+C</kbd> to stop the running application.
 
 ## Create a feature branch
 
@@ -173,9 +173,9 @@ As an optional step, trace the build as it moves through the pipeline, and verif
 
 While you were busy working on your feature, changes might have been made to the remote `main` branch. Before you create a pull request, it's common practice to get the latest from the remote `main` branch.
 
-To do this, first check out, or switch to, the `main` branch, then merge the remote `main` branch with your local `main` branch.
+To do this, first check out, or switch to, the `main` branch. Then, merge the remote `main` branch with your local `main` branch.
 
-Next, check out your feature branch, then merge your feature branch with the `main` branch.
+Next, check out your feature branch, and then merge your feature branch with the `main` branch.
 
 Let's try the process now.
 

learn-pr/azure-devops/implement-code-workflow/includes/8-require-reviewer.md

@@ -26,7 +26,7 @@ In this section, you'll set up a rule on GitHub that requires at least one revie
 1. Select the **Settings** tab near the top of the page.
 1. On the left menu, select **Branches**.
 1. Make sure that **main** is selected as your default branch.
-1. Select **Add branch protection rule**.
+1. Select **Add classic branch protection rule**.
 1. Under **Branch name pattern**, enter **main**.
 1. Select the **Require a pull request before merging** check box.
 1. Select the **Require approvals** check box.

learn-pr/azure-devops/implement-code-workflow/includes/9-clean-up-environment.md

@@ -36,7 +36,7 @@ To disable the pipeline:
 1. Select the ellipsis (**...**), then select **Settings**:
 
     :::image type="content" source="../../shared/media/azure-pipelines-settings-button.png" alt-text="Screenshot of Azure Pipelines showing the location of the Settings menu.":::
-1. Under **Processing of new run requests**, select **Disabled**, then select **Save**.
+1. Under **Processing of new run requests**, select **Disabled**, and then select **Save**.
 
     Your pipeline will no longer process build requests.