wording changes

Git stuff
I have to do swerve and packages now

Author: cbgpenguin

src/FRC/course/Swerve.md

@@ -1,3 +1,7 @@
 # Swerve Drive
 
-todo!
+Our robot uses a swerve drive. A swerve drive is four swerve modules of two motors each. One changes the angle of the wheel and one changes the speed. It is similar to a shopping cart where all the wheels swivel to move the shopping cart any direction regardless of where the front of the cart is. The robot can spin but go straight. In this way the rotation of the robot and the direction the robot is going in is not connected.
+
+## Modules
+
+### Motors

src/Git/course/Installing-Git.md

@@ -59,15 +59,15 @@
 
 <hr>
 
-# **Installing GitKraken** (Alt)
-To maintain consistency, use GitKraken only if GitHub GUI failed to install or you are on an unsupported device such as a Linux operating system.
+# **Installing GitKraken** (Alternative to GitHub Desktop)
+
 ## Windows & Mac
-The process is as self explanatory as installing GitHub GUI, just using a different installation URL. Please use the *standard* GitHub GUI installation unless this is required as per your individual setup. 
+The process is as self explanatory as installing GitHub GUI, just using a different installation URL.
 
->Go to [https://www.gitkraken.com/download](https://www.gitkraken.com/download) and select for your operating system, and run the installation proccess following the directions on screen. 
+>Go to [https://www.gitkraken.com/download](https://www.gitkraken.com/download) and select for your operating system, and run the installation process following the directions on screen. 
 
 ## Linux
-Depending on your distro, download the according file, whether that be a `.rpm` / `.deb` / `.tar.gz`  (or use Snap Package Manager, depending on your support and prior installation of it). This proccess should be familiar to you if you are already familar with Linux.
+Depending on your distro, download the according file, whether that be a `.rpm` / `.deb` / `.tar.gz`  (or use Snap Package Manager, depending on your support and prior installation of it). This process should be familiar to you if you are already familiar with Linux.
 
 **.deb File**
 >Run (in the same directory as the downloaded file)
@@ -102,7 +102,7 @@ Real alphas don't need convenient things like applications. (Just kidding!) But
 >```
 
 Breakdown of this Powershell line:
-We are telling `winget`, the preinstalled package manager on windows, to search for Git from Microsoft offical records and to then install it (and to also verify that it is indeed the only Git in the Microsoft record)
+We are telling `winget`, the preinstalled package manager on windows, to search for Git from Microsoft official records and to then install it (and to also verify that it is indeed the only Git in the Microsoft record)
 
 >On either device, run `git --version` to verify successful installation of Git. 
 To see the exact file location on Windows, type ```where git```, and on Mac & Linux, ```which git```

src/Git/course/Usage.md

@@ -21,39 +21,29 @@ Keep in mind the following when working with Git:
 
 - **Repo/Codebase**: Short for *repository*; A repository is where the code of a project is stored, and can exist locally or remotely. 
 
-- **Remote Repository**: A repository hosted on the web. Git can sync the repository across different devices and users. Our code is available on **GitHub** (https://github.com/MontclairRobotics), which is a *website that hosts Git repositories on the web*. Other websites include [GitLab](https://gitlab.com), [Bitbucket](https://bitbucket.org), and [Amazon's own Git offering](https://aws.amazon.com/codecommit/), but [GitHub](https://github.com/) is the de facto standard.
+- **Remote Repository**: A repository hosted on the web. Git can sync the repository across different devices and users. Our code is available on **GitHub** (https://github.com/MontclairRobotics), which is a *website that hosts Git repositories on the web*.
 
-- **Commit**: A commit is a snapshot of your local repository that gets compared and evaluated to the remote repository in its current state (before your changes). The record of your modifications from the original is permanently saved to the project's history and stays accessible. The permanence of a commit is unimaginably helpful, but this means that each *character* of code must be written with meaning and significance. 
+- **Commit**: A singular *saved version* of the repository. When a programer is ready they can *commit* the code so it is saved within git. A snapshot of the project that records the changes that were made since the last commit. It is a permanently saved record in the projects history. You can think of it as one saved version like in a google doc.
 
 - **Stage**: Adding what file changes you want to include in your commit and what changes/files you want to leave out.
 
-- **Push/Pull**: After a commit, you *push* your commits and other changes to the remote repository, and *pull* changes made to the remote onto your computer. Simply put, this syncs your local repository to the remote one. Pull gets changes from the remote repository and *merges* the changes in to your local repository. Pushing sends local changes to the remote repository. Make sure to pull before you commit and push so you can resolve any **[conflicts] (link)** before they occur.
+- **Push/Pull**: After a commit, you *push* your commits and other changes to the remote repository, and *pull* changes made to the remote onto your computer. Simply put, this syncs your local repository to the remote one. Pull gets changes from the remote repository and *merges* the changes in to your local repository. Pushing sends local changes to the remote repository. Make sure to pull before you commit and push so you can resolve any conflicts before they occur.
 
 - **Clone**: Cloning is the process of putting a remote repository on a local device, and allows the Git on your computer to have a copy of the repository and all its history. This can now be edited directly on your computer, and this instance of the repository is referred to as a "**local**" repository.
 
-- **Fork**: Similar to cloning a repository, but the history of committed changes is no longer associated to the original repository. Most likely not using this feature. Your changes are not synced to *their* cloud repository, and their changes will not be shown to your repository. A fork is duplicating or backing up a repository at a given moment, and the two repositories can differ and are not associated after the split. 
+- **Merge**: *The action of taking two versions of code and combining them into one.* For example, if changes have been made to the code since you started editing it, you will need to *merge* the code you wrote with the new version of the code. Simply put you need to merge two different versions of the same code into a singe version. If the changes each version made do not interfere with each other, then Git will usually be able to merge automatically. However if you need to merge to versions with changes that do interfere with each other, that is called a **merge conflict**. You will need to manually select which lines from each version will be combined into the final version. This can be done with two commits (often from different *branches*) or with a commit and uncommitted changes. The end result is a single version of the codebases that combines the two sets of changes.
 
-- **Merge**: If code has been written and pushed since you have started editing it, then you'll have to merge. The files you have on your computer just don't line up with the ones in the remote repository. If the changes each version made do not interfere with each other, then Git will be able to merge automatically. However, if you need to merge two versions with changes that *do* interfere with each other, that is a **merge conflict**. You'll manually select which lines from each file to be combined to the final version. This can be done with two commits (often from different *branches*) or uncommitted changes. 
-
-- **Branch**: A github branch is a way to work on the repository without modifying an existing version. Branches are released on the same level as each other, and existing "parallel-ly" to each other. Branches are useful for experimentation, when working on a bug fix or a new feature, testing the new solution in a new environment whilst keeping the existing version active in the chance that the new solution fails to be more effective, or multiple projects inside the same repository. Branches do not need to necessarily have the same files, and do not necessarily cross-reference each other, but they can have the same files, especially if they are different versions of the final project. In the GitHub GUI, it is easy to switch branches, just change the "current branch" dropdown, and then fetch (this may overwrite your device's local copy of the repository so handle modified code properly.).
-<br> To switch in the CLI to a branch that already exists: <br>
-   ```git switch branch-name.```<br>
-If the branch doesn’t exist locally but exists on GitHub (remote), use:
-<br>
-    ```
-    git fetch
-    git switch branch-name
-    ```
-<br>
+- **Branch**: A branch is an independent line of development within a repository. You can take a commit and create a branch that comes out of it. There you can create changes and commits that are unaffected by the main branch. They allow developers to diverge from the main branch of work and make changes without affecting the main branch. Branches can also be merged back in. As a commit can be thought of as just a list of changes, these changes can be merged into the main branch again. Branches are useful for keeping things organized. You can have a branch that is focused on a specific thing. In this way the development of that thing does not interfere with the main branch. It is easy to switch branches, just change the "current branch" dropdown, and then fetch. (This will overwrite your device's local copy of the repository.) Below is a basic image of how the development of a project could look while using git branches.
 
+&emsp; <img src="../../assets/UnMergedBranch.png" style="width:5.4in;height:2.3in" /> &emsp; <img src="../../assets/GitBranches.png" style="width:4.6in;height:2.5in" />
 
-- **Pull Request**: A request to modify the main branch of the repository with your modifications. In the GitHub GUI, every modified file is marked, and a reviewer can see where you deleted, added, or modified files, and then decide accordingly if the modified code is effective or ineffective. Unlike a direct pull/push, a pull **request** allows for collaboration in independently-written code, in that someone else **must** read the code before it becomes part of the team's code. You are requesting a branch to pull from your branch by merging its changes.
+- **Pull Request**: A request for a branch to pull from your branch and merge your branches changes into itself. This is often, a request to modify the main branch of the repository with your modifications. Unlike a direct pull/push, a pull **request** allows for collaboration in independently-written code, in that someone else **must** read the code before it becomes part of the team's code. Another person can review your code and accept the pull request.
 
-- **Code Review**: The process of a single team member's code being read by another. Similar to peer review in tests, this ensures that the code is being seen by more eyes. Two heads are better than one. 
+- **Code Review**: The process of a single team member's code being read by another. Similar to a peer review, this ensures that the code is being seen by more eyes. Two heads are better than one. 
 
-- **Stash**: ```git stash``` tells Git to save your work in its current state, but only locally. By saving using stash, the programmer can proceed to work on another project or another branch, without having to sync to the cloud if the code is not complete or ready. ```git stash pop``` reads the last locally saved stash back. Currently, ```stash``` and ```pop``` are not accessible through the GitHub GUI, so you will need the CLI (and will probably use through VSCode terminal.)
+- **Stash**: ```git stash``` tells Git to save your work in its current state temporarily. It turns your changes into a stash which is like a temporary and local commit that you can turn back into changes and continue working on. By saving using stash, the programmer can proceed to work on another project or another branch. ```git stash pop``` turns the stash back into changes in your working directory.
 
-- **Origin**: Refers to the remote repository in its existing state. 
+- **Origin**: Refers to the remote repository. 
 
 - **Git States**: In Git, any file can be in any of four states. 
 
@@ -76,13 +66,13 @@ If the branch doesn’t exist locally but exists on GitHub (remote), use:
     Committed -
     >Saved to Git/GitHub history ```git status``` executed in the CLI will show files to the terminal in their state.  (No local changes beyond the last commit.)
 
-- **HEAD**: Head is where the user is at the current moment. Head moves as you move between branches. Head by default points to the latest commit of that branch. However, Head notation allows us to specify where we are. Where HEAD points to your current commit or branch, HEAD~1 is one commit before HEAD.
+- **HEAD**: Head is where the user is at the current moment. Head moves as you move between branches. Head by default points to the latest commit of the branch you are on.
 
-- **Checkout**: Can allow the programmer to change the working directory to be compared to match the latest commit of a branch, by passing ```git checkout (branch-name)```, allowing for an attached head, or the same can be applied to an existing commit hash, ```git checkout (commit_hash)```, working in a detached head state. ```git restore (filename)``` discards all modifications to file, going back to the latest version where you are. 
+- **Checkout**: Change the working directory (the local files) to a different commit or branch. As commits are permanently saved versions of the code, you can check any of them out any time. If you have uncommitted changes you will need to *stash* or commit them first.
 
-- **Detached HEAD**: A HEAD that points to a commit and not a branch. Git History is checking your code to that commit in the past, and not a current live branch. Using checkout, the specific commit gets its own branch to the repository, with an attached head and can be pushed/pulled from origin.
+- **Detached HEAD**: A HEAD that points to a commit and not a branch. Git History is checking your code to that commit in the past, and not a current live branch.
 
-- **GitHub Issues**: Allows us to plan our progress, by planning, prioritizing, and designating different incomplete tasks to different programmers. We can use this to communicate to collaborators where we are in the project's timeline, and link code to a discussion space easily. 
+- **GitHub Issues**: Allows us to plan our progress, by planning, prioritizing, and designating different incomplete tasks to different programmers. We can use this to communicate to collaborators where we are in the project's timeline, and link code to a discussion space easily. This for really organized people so I'm not sure how useful it is to us when we can communicate using basecamp but it is good to know.
 
 - **GitHub Actions**: *This won't be nessasary for working on the robot*. Custom scripts that run automatically after an event such as pushes, pull requests, issue creation, or even on a schedule. These can be used for testing, building, deploying, or any automated task. A sample action, located in the ```.github/workflows``` as a YAML file
     ```YAML
@@ -103,3 +93,4 @@ If the branch doesn’t exist locally but exists on GitHub (remote), use:
     ```
     This sample action runs after every push to the repository. It occurs on an ubuntu cloud computer, allocated to us for limited usage. It takes the steps of running npm install, and then it runs a sample test. In this way, if the automated action fails, then this push would be rejected. While this is a simple sample, GitHub actions can be so much more powerful. 
 
+- **Fork**: You will not need to use this feature. Similar to cloning a repository, but the history of committed changes is no longer associated to the original repository. You are duplicating the repository for yourself to be independent of the original repository. Your changes are not synced to *their* cloud repository, and their changes will not be shown to your repository. A fork is duplicating or backing up a repository at a given moment, and the two repositories can differ and are not associated after the split.