fix: improve clarity and grammar in lesson steps

.github/steps/1-step.md

@@ -1,8 +1,8 @@
 ## Step 1: Introduction to Git Version Control
 
-You've been working on a project and realized organizing backups has become difficult. And, since everyone shares updates differently, collaborating with them is very confusing.
+You've been working on a project and realized that organizing backups has become difficult. Since everyone shares updates differently, collaborating with them is very confusing.
 
-After some quick searching, you learned about [Git](https://git-scm.com/). Supposedly, it makes keeping track of changes and collaborating with others easy. It removes the confusion of older methods like file naming conventions, share drives, and emailed copies of files.
+After some quick searching, you learned about [Git](https://git-scm.com/). Supposedly, it makes keeping track of changes and collaborating with others easier. It removes the confusion of older methods like file naming conventions, share drives, and emailed copies of files.
 
 > [!IMPORTANT]
 > This exercise teaches Git usage on a machine with it already installed.
@@ -97,11 +97,11 @@ To start practicing Git, let's first open a pre-configured development environme
 
 Let's start with using Git in the command line interface (CLI). This is the source of all Git functionality and most powerful option.
 
-1. If the integrated terminal is not already available, open it using `Ctrl+Shift+P` then searching for and selecting `View: Toggle Terminal`
+1. If the integrated terminal is not already available, open it by pressing `Ctrl+Shift+P`, then search for `View: Toggle Terminal` and press `Enter`.
 
    <img width="500px" src="https://github.com/user-attachments/assets/4bbf918a-f87c-4875-b7fd-61d8b16a70e1"/>
 
-1. Show the currently installed version of Git, to verify it is installed.
+1. Show the installed version of Git to verify that it is installed.
 
    ```bash
    git --version
@@ -122,17 +122,17 @@ Let's start with using Git in the command line interface (CLI). This is the sour
 Before we can start versioning our game, let's provide Git our identity so it can associate us as the author for any changes.
 
 > [!WARNING]
-> Git stores the author name and email in the history, which is visible to anyone with access to the repository. GitHub provides an optional [noreply email address](https://docs.github.com/en/account-and-profile/reference/email-addresses-reference#your-noreply-email-address) you may enable from your account [email settings](https://github.com/settings/emails).
+> Git stores the author name and email in the history, which is visible to anyone with access to the repository. GitHub provides an optional [noreply email address](https://docs.github.com/en/account-and-profile/reference/email-addresses-reference#your-noreply-email-address) that you can enable from your account [email settings](https://github.com/settings/emails).
 
-1. Set your display name.
+1. Set your Git author name.
 
    ⚠️ Don't forget to replace `First` and `Last`!
 
    ```bash
    git config --global user.name "First Last"
    ```
 
-1. Set your email address. For additional privacy, consider enabling your noreply address in your account [email settings](https://github.com/settings/emails) to keep your personal email private.
+1. Set your Git email address. For additional privacy, consider enabling your noreply address in your account [email settings](https://github.com/settings/emails) to keep your personal email private.
 
    ⚠️ Don't forget to replace `me@example.com`!
 
@@ -148,10 +148,10 @@ Before we can start versioning our game, let's provide Git our identity so it ca
 
    <img width="500px" src="https://github.com/user-attachments/assets/62688039-3601-4a23-8f61-408210faff0a"/>
 
-1. With your author details configured, Mona should already be busy checking your work. Give her a moment and keep watch in the comments. You will see her respond with progress info and the next steps.
+1. With your Git identity configured, Mona should already be busy checking your work. Give her a moment and keep watch in the comments. You will see her respond with progress info and the next steps.
 
 > [!TIP]
-> You can also change your username and email per project, if you have multiple accounts. On an **existing** project repository, use `--local` instead of `--global`.
+> You can also change your username and email per project if you have multiple accounts. On an **existing** project repository, use `--local` instead of `--global`.
 
 <details>
 <summary>Having trouble? 🤷</summary><br/>

.github/steps/2-step.md

@@ -6,9 +6,9 @@ Now that we are familiar with the sample project and informed Git who we are, le
 
 The Git workflow involves three main areas:
 
-- **Working Directory**: Your project files where you are making changes.
-- **Staging Area (Index)**: A preparation area for grouping changes you want to save to history.
-- **Repository**: The permanent records of your project's development history.
+- **Working Directory**: Your project files where changes are made.
+- **Staging Area (Index)**: A preparation area for grouping changes to be committed to history.
+- **Repository**: The permanent record of your project's development history.
 
 ```mermaid
 graph LR
@@ -17,19 +17,19 @@ graph LR
   C -->|git checkout| A
 ```
 
-### What are the important Git commands?
+### Essential Git Commands
 
-Git has many operations, but there are a few you will use the most for local projects.
+Git has many commands, but there are a few you will use most often when working on local projects:
 
-- `git init` - Start a new repository to enable versioning.
-- `git add` - Group related changes together in the staging area, in preparation to "commit" them to history.
-- `git commit` - Save or "commit" the changes in the staging area to the project's history.
-  - commit message - A short description of the changes to help keep the history organized.
-- `git status` - View the current state of your working directory and staging area.
-- `git checkout` - Change your working directory to a different version from the repository history.
+- `git init` - Initializes a new Git repository to enable version control.
+- `git add` - Adds changes to the staging area before committing them to history.
+- `git commit` - Commits changes in the staging area to the project's history.
+  - Commit message - A short description of the changes to help keep the project history organized.
+- `git status` - Shows the status of the working directory and staging area.
+- `git checkout` - Switches to a different branch or version of the project.
 
 > [!TIP]
-> Don't undervalue the commit message! A clear, concise, descriptive, and non-generic message will make your project history much easier to understand (and help find those future bugs)!
+> Don’t underestimate commit messages! A clear, concise, and descriptive message will make your project history easier to understand and help you find future bugs!.
 
 ### ⌨️ Activity 1: Initialize a project repository (using the CLI)
 
@@ -47,15 +47,15 @@ Let's add version control to our game and commit the current version.
    git init
    ```
 
-1. Check repository status. Notice it says "No commits yet" and the tip to use `git add`.
+1. Check the repository status. Notice that it says "No commits yet" and suggests using `git add`.
 
    ```bash
    git status
    ```
 
    <img width="500px" src="https://github.com/user-attachments/assets/b15dbbde-057c-4508-a9c5-73681cc1ad19"/>
 
-1. Promote the game files to the staging area. This will create a locked copy, preparing them for committing to the repository history.
+1. Add the game files to the staging area. This prepares them for committing to the repository history.
 
    ```bash
    git add src/index.html
@@ -70,23 +70,23 @@ Let's add version control to our game and commit the current version.
    git add src/*
    ```
 
-1. Check the repository status again. Notice that each file is identified as `new file`.
+1. Check the repository status again. Each file is now marked as `new file`.
 
    ```bash
    git status
    ```
 
    <img width="500px" src="https://github.com/user-attachments/assets/77780813-7dbc-4aaa-8df8-d11938674b1f"/>
 
-1. Commit the changes to the repository history. Our project history is now started! :octocat:
+1. Commit the files to the repository history. Our project history has now been created! :octocat:
 
    ```bash
    git commit -m "Initial commit"
    ```
 
    <img width="500px" src="https://github.com/user-attachments/assets/da92ec36-8a89-4e8b-9592-c55e6f09b7af"/>
 
-1. Check repository status. Notice the "working tree clean" which means our current copy perfectly matches the history.
+1. Check the repository status again. It shows "working tree clean", meaning the working directory matches the repository history.
 
    ```bash
    git status
@@ -98,39 +98,35 @@ Let's add version control to our game and commit the current version.
 
 Let's also try adding files with our code editor, in this case the documentation for our game.
 
-1. In the file explorer, click the **New File...** icon to start a README file with the following name. Make sure it is inside the `./stack-overflown/` folder.
-
-   ```txt
-   README.md
-   ```
+1. In the file explorer, click the **New File...** icon to create a `README.md` file inside the `./stack-overflown/` folder.
 
    <img width="350px" src="https://github.com/user-attachments/assets/df391b20-6df5-4195-a03a-55975da30b46"/>
 
-1. Open the file and insert the following content.
+1. Open the `README.md` file and add the following content:
 
    ```md
    # Stack Overflown
 
    Organize the falling blocks into the current debug pattern before the stack overflows! ⏳
    ```
 
-1. In the left navigation, select the **Source Control** tab. Notice the `README.md` file is listed under the **Changes** area.
+1. In the left navigation, select the **Source Control** tab. Notice that the `README.md` file is listed under the **Changes** area.
 
    <img width="350px" src="https://github.com/user-attachments/assets/b31a12ac-ef3d-454b-8c94-7146abab0f99"/>
 
-1. Promote the file to the staging staging area by hovering over file and selecting the plus sign `+` button.
+1. Add the `README.md` file to the staging area by hovering over the file and selecting the `+` icon.
 
    <img width="350px" src="https://github.com/user-attachments/assets/5c2a7e4c-244f-406c-98d3-6e1934d754e7"/>
 
-1. Enter a commit message and press the **Commit** button.
+1. Enter a commit message in the input box and click the **Commit** button.
 
    ```txt
    Start game documentation
    ```
 
    <img width="350px" src="https://github.com/user-attachments/assets/fc80aa05-0f1f-4c68-8e8a-95cd9d41321b"/>
 
-1. For a second commit, also add the following content to `README.md`.
+1. For a second commit, update the `README.md` file by adding the following content:
 
    ```md
    ## How to Develop
@@ -141,7 +137,7 @@ Let's also try adding files with our code editor, in this case the documentation
    - `style.css` - the game formatting and styling
    ```
 
-1. Promote the change to staging and commit with the below message.
+1. Add the change to the staging area and commit with the following message:
 
    ```txt
    Start developer docs
@@ -154,6 +150,6 @@ Let's also try adding files with our code editor, in this case the documentation
 <details>
 <summary>Having trouble? 🤷</summary><br/>
 
-- If `git status` shows the wrong files, you can remove them from staging with `git restore --staged <filename>`
+- If `git status` shows the wrong files, you can unstage them with `git restore --staged <filename>`
 
 </details>

.github/steps/3-step.md

@@ -1,6 +1,6 @@
 ## Step 3: Exploring Git History
 
-With our game now tracked in Git, let's learn how to explore what changes were made, when they were made, and by whom.
+Now that our game is tracked in Git, let's learn how to explore what changes were made, when, and by whom.
 
 ### 📖 Theory: Understanding Git History
 
@@ -12,7 +12,7 @@ Git maintains a complete history of your project through commits. Each commit co
 - **Timestamp**: When the changes were applied.
 - **Commit message**: Description of the changes included in that commit.
 
-Additionally, the `HEAD` pointer is a special label that indicates your current position in the project history. Your project probably looks similar to the below diagram.
+Additionally, the `HEAD` pointer is a special label that indicates your current position in the project history. Your project probably looks similar to the below diagram:
 
 ```mermaid
 ---
@@ -25,15 +25,15 @@ gitGraph
    commit id: "762ac02 Start developer docs" tag: "HEAD"
 ```
 
-### What are the important Git commands?
+### Git History Commands
 
 Everyone prefers viewing the history in different ways, and the community has created many options.
-Here are a few of the common commands and options you will often use.
+Here are a few of the common commands and options you will often use:
 
-- `git log` - Display a detailed history of the project.
-  - `git log --oneline` - Show one commit per line, but with less detail.
-  - `git log --graph` - Show a visual diagram, useful for diverging paths.
-- `git checkout` - Move to a different point in the history (modifies files in your working directory).
+- `git log` - Displays a detailed history of the project.
+  - `git log --oneline` - Shows one commit per line, but with less detail.
+  - `git log --graph` - Shows a visual diagram, useful for diverging branches.
+- `git checkout` - Moves to a different point in the history (modifies files in your working directory).
 
 ### ⌨️ Activity 1: Explore the history (using the CLI)
 
@@ -53,7 +53,7 @@ Here are a few of the common commands and options you will often use.
 
    <img width="500px" src="https://github.com/user-attachments/assets/b49a6352-4233-4903-9254-18eaec569895"/>
 
-1. Show a visual graph of the full commit history.
+1. Show a visual graph of the commit history.
 
    ```bash
    git log --graph --oneline
@@ -101,7 +101,7 @@ Here are a few of the common commands and options you will often use.
 
    <img width="350px" src="https://github.com/user-attachments/assets/42310a18-84a4-4dca-8f45-18d589e187c0"/>
 
-1. With your exploration of the Git history finished, Mona should already be busy checking your work. Give her a moment and keep watch in the comments. You will see her respond with progress info and the next steps.
+1. With your exploration of the Git history complete, Mona should already be busy checking your work. Give her a moment and keep watch in the comments. You will see her respond with progress info and the next steps.
 
 <details>
 <summary>Having trouble? 🤷</summary><br/>

.github/steps/4-step.md

@@ -1,10 +1,10 @@
 ## Step 4: Comparing Changes
 
-Now that we understand how to "undo", let's make some real game changes! And more importantly, learn how Git can show us what was changed **before** we commit it to the repository history.
+Now that we understand how to "undo", let's make some real game changes and learn how Git can show us what was changed **before** we commit it to the repository history.
 
 Understanding file differences is crucial for reviewing your work and catching errors!
 
-### 📖 Theory: Understanding Diffs
+### 📖 Theory: Understanding Git Diffs
 
 Git uses symbols and coloring to show file changes:
 
@@ -19,28 +19,28 @@ Example:
 ```
 
 > [!TIP]
-> You can change Git's default comparison colors with the below commands.
+> You can change Git's default comparison colors with the below commands:
 >
 > ```bash
 > git config --global color.diff.old yellow
 > git config --global color.diff.new blue
 > ```
 
-### What are the important Git commands?
+### Git Diff Commands
 
 The `git diff` command shows differences between development states.
 
-- `git diff` - Differences between the working directory and the staging area.
-- `git diff --staged` - Differences between staging area and previous commit.
-- `git diff HEAD~1` - Differences between current commit and previous commit.
+- `git diff` - Shows differences between the working directory and the staging area.
+- `git diff --staged` - Shows differences between the staging area and the previous commit.
+- `git diff HEAD~1` - Shows differences between the current commit and the previous commit.
 
 ### ⌨️ Activity 1: View differences (using the CLI)
 
-Let's make some changes to the game then use the CLI to show the differences.
+Let's make some changes to the game, then use the CLI to show the differences.
 
 1. Open `src/index.html`.
 
-1. At `line 20`, replace the `info-section` area about scoring with the below example.
+1. On `line 20`, replace the `info-section` area about scoring with the below example:
 
    ```txt
    <div class="info-section">
@@ -65,7 +65,7 @@ Let's make some changes to the game then use the CLI to show the differences.
 
    <img width="500px" src="https://github.com/user-attachments/assets/f41d6917-1651-4549-bb7b-5441a1832e38"/>
 
-1. Promote the changes into the staging area.
+1. Add the changes to the staging area.
 
    ```bash
    git add src/index.html
@@ -85,7 +85,7 @@ Let's make some changes to the game then use the CLI to show the differences.
 
    <img width="500px" src="https://github.com/user-attachments/assets/f6aad38c-56fa-49ed-8209-9fe249c209ff"/>
 
-1. Commit the changes with the following message.
+1. Commit the changes with the following message:
 
    ```md
    git commit -m "Add element for showing high score"
@@ -95,11 +95,11 @@ Let's make some changes to the game then use the CLI to show the differences.
 
 ### ⌨️ Activity 2: View differences (using VS Code)
 
-Let's make some more changes to the game then use the VS Code to show the differences.
+Let's make some more changes to the game, then use the VS Code to show the differences.
 
 1. Open `src/patterns.js`.
 
-1. At `line 3`, replace the `Null Pointer` area with the below example to change the pattern.
+1. On `line 3`, replace the `Null Pointer` area with the below example to change the pattern:
 
    ```txt
    {
@@ -114,33 +114,33 @@ Let's make some more changes to the game then use the VS Code to show the differ
    },
    ```
 
-1. In the **File Explorer**, notice the file name `patterns.js` changed color and now has an `M` indicating it is modified.
+1. In the **File Explorer**, notice that the file name `patterns.js` has changed color and now has an `M`, indicating that it has been modified.
 
    <img width="350px" src="https://github.com/user-attachments/assets/93a8f34c-9b16-4783-bc46-81532cdeffdf"/>
 
-1. Open the **Source Control** tab. In the **Changes** list, double-click the `patterns.js` file to open the Diff (comparison) view.
+1. Open the **Source Control** tab. In the **Changes** list, click `patterns.js` to open the diff (comparison) view.
 
    <img width="350px" src="https://github.com/user-attachments/assets/4dce9e42-caca-4c6e-a6fe-8d83d58cd06d"/><br/>
 
    <img width="500px" src="https://github.com/user-attachments/assets/4c410689-2a53-462f-9200-79d21bddbf2c"/>
 
    > 💡 **Tip**: You can modify the content in the comparison view for live feedback!
 
-1. Promote the the file to the **staging** area. ⚠️ Don't commit yet!
+1. Add the file to the **staging** area. ⚠️ Don't commit yet!
 
    Notice the comparison view stopped showing changes since the current file matches the staging area.
 
    <img width="500px" src="https://github.com/user-attachments/assets/b1274ece-2b03-42d2-88e8-9f3aaaa8f2c5"/>
 
-1. In the **Staged Changes** list, double-click the `patterns.js` file to open the Diff (comparison) view.
+1. In the **Staged Changes** list, click `patterns.js` to open the diff (comparison) view.
 
-   Notice that you can't make changes now. The staging area is locked in preparation for committing.
+   Notice that you can't make changes here. The staging area is locked in preparation for committing.
 
    <img width="350px" src="https://github.com/user-attachments/assets/da306727-49f1-4f73-9f38-3a0e5d406cef"/><br/>
 
    <img width="500px" src="https://github.com/user-attachments/assets/de1448eb-d0dd-4ec5-89a2-74fb4aa1cf5f"/>
 
-1. Commit the change with the following message.
+1. Commit the change with the following message:
 
    ```txt
    Make null pointer pattern easier to complete