Make capitalization of git/Git consistent (#109)

**Pull Request Description**

Capitalizes Git anytime it is not used in a command (e.g. `git status`).

Closes #55 

---

**Licensing Certification**

GitKit is a [Free Cultural Work](https://freedomdefined.org/Definition)
and all accepted contributions are licensed as described in the
LICENSE.md file. This requires that the contributor holds the rights to
do so. By submitting this pull request **I certify that I satisfy the
terms of the [Developer Certificate of
Origin](https://developercertificate.org/)** for its contents.

Author: braughtg

README.md

@@ -224,6 +224,9 @@ Use text styling consistently throughout the document as follows:
   - The first use of a new term.
 - `"..."` (quotations)
   - GitHub / VSCode / Linux UI elements (buttons / menus / text in output / etc)
+- Git vs `git`
+  - Use `git` only when writing a command (e.g. `git status`).
+  - Use Git in all other instances.
 
 #### Escaping Characters
 

source/ch-communities-and-collaboration/ch-communities-and-collaboration.ptx

@@ -8,11 +8,11 @@
 
   <introduction>
     <p>
-      The exercises in this chapter focus on FOSS communities.  They explore what they are, how they are organized, the principles on which they operate and the roles that the community members take on.  They also begin to look at some of the tools and processes that these communities use to support those principles and coordinate their work. You will see how git and GitHub work together to allow FOSS communities to share their work and to collaborate.  In particular, you will create a fork and clone, and see how they make it possible for a diverse and distributed group of contributors to work asynchronously and to contribute useful changes back to the upstream.  
+      The exercises in this chapter focus on FOSS communities.  They explore what they are, how they are organized, the principles on which they operate and the roles that the community members take on.  They also begin to look at some of the tools and processes that these communities use to support those principles and coordinate their work. You will see how Git and GitHub work together to allow FOSS communities to share their work and to collaborate.  In particular, you will create a fork and clone, and see how they make it possible for a diverse and distributed group of contributors to work asynchronously and to contribute useful changes back to the upstream.  
     </p>
 
     <p>
-      In this and the next several chapters you will use a copy of the FarmData2 project repository to gain hands-on experience using use git and GitHub.  This experience will strengthen your understanding of git, GitHub and FOSS communities.
+      In this and the next several chapters you will use a copy of the FarmData2 project repository to gain hands-on experience using use Git and GitHub.  This experience will strengthen your understanding of Git, GitHub and FOSS communities.
     </p>
 
     <p>

source/ch-communities-and-collaboration/sec-cloning-your-origin.ptx

@@ -421,19 +421,19 @@
   </p>
 
   <p>
-    The command <c>git remote</c> on its own will show you the <em>names</em> of the remotes that git knows about, but not their URLS.
+    The command <c>git remote</c> on its own will show you the <em>names</em> of the remotes that Git knows about, but not their URLS.
   </p>
 
   <p>
-    If you want to have git display the URLs of the remotes as well, you will need to add the <c>-v</c> or <c>--verbose</c> flag: <c>git remote -v</c>
+    If you want to have Git display the URLs of the remotes as well, you will need to add the <c>-v</c> or <c>--verbose</c> flag: <c>git remote -v</c>
   </p>
 
   <exercises>
   <title />
   <exercise xml:id="ex-check-remotes-a" label="ex-check-remotes-a">
     <statement>
       <p>
-        Which command will show you the URL(s) of the remote(s) that git knows about?
+        Which command will show you the URL(s) of the remote(s) that Git knows about?
       </p>
     </statement>
 
@@ -490,7 +490,7 @@
 
         <feedback>
           <p>
-            <c>git url</c> is not a git command.
+            <c>git url</c> is not a Git command.
           </p>
         </feedback>
       </choice>

source/ch-communities-and-collaboration/sec-development-environment.ptx

@@ -422,7 +422,7 @@
       <statement>
         <p>
           The <c>git config --global user.name "&lt;name&gt;"</c> command sets the name that Git will associate with your changes.
-          Throughout this book, &lt; &gt; will be used to indicate a part of a git command that you must enter.
+          Throughout this book, &lt; &gt; will be used to indicate a part of a Git command that you must enter.
           For example, if you want your name to appear as Jane D.
           the command would be <c>git config --global user.name "Jane D."</c>.
         </p>
@@ -438,7 +438,7 @@
       <setup> <var> <condition string='^git config --global user\.name "[^&lt;].+[^&gt;]"$'>
       <feedback>
         <p>
-          This command will set the name associated with your changes in git.
+          This command will set the name associated with your changes in Git.
         </p>
       </feedback>
       </condition> <condition string='^git config --global user\.name ["]*&lt;.+&gt;["]*$'>
@@ -483,7 +483,7 @@
       <setup> <var> <condition string='^git config --global user\.email "[^&lt;].+@.+[^&gt;]"$'>
       <feedback>
         <p>
-          This command will set the email associated with your changes in git.
+          This command will set the email associated with your changes in Git.
         </p>
       </feedback>
       </condition> <condition string='^git config --global user\.email "[^&lt;][^@]+[^&gt;]"$'>

source/ch-communities-and-collaboration/sec-extra-practice.ptx

@@ -166,7 +166,7 @@
 
     <hint>
       <p>
-        The origin URL should be the one from your git clone command.
+        The origin URL should be the one from your Git clone command.
       </p>
     </hint>
   </exercise>

source/ch-communities-and-collaboration/sec-farmdata2.ptx

@@ -6,7 +6,7 @@
   <introduction>
     <p>
       Git and GitHub were designed to support the collaborative work of the FOSS communities that you learned about in class and in <xref text='type-global-title' ref='topic-foss-communities' />.
-      In this section you'll learn a little about the FarmData2 project that GitKit as the basis for the activities you'll be completing as you learn the basics of git and GitHub.
+      In this section you'll learn a little about the FarmData2 project that GitKit as the basis for the activities you'll be completing as you learn the basics of Git and GitHub.
     </p>
   </introduction>
 

source/ch-communities-and-collaboration/sec-git-command-summary.ptx

@@ -13,14 +13,13 @@
   </introduction>
 
   <exercises>
-    <title />
-    <exercise xml:id="ex-git-commands-summary-communities"
-      label="ex-git-commands-summary-communities">
-      <statement>
-        <p>
-          Match the tasks on the right with the appropriate git command listed on the left.
-        </p>
-      </statement>
+  <title />
+  <exercise xml:id="ex-git-commands-summary-communities" label="ex-git-commands-summary-communities">
+    <statement>
+      <p>
+        Match the tasks on the right with the appropriate Git command listed on the left.
+      </p>
+    </statement>
 
       <cardsort>
         <match>

source/ch-instructor-guide/sec-instructor-communities.ptx

@@ -125,16 +125,16 @@
         <li>
           <title>Slides 6-8</title>
           <p>
-            <term>Version control</term> and <term>repository hosting</term> are defined as collaboration tools and a distinction is drawn between them. A number of different examples of each, e.g. svn/mercurial for version control and GitLab/SourceForge for repository hosting, are mentioned for breadth. This can also help to emphasize that while the GitKit focuses on git and GitHub, that the concepts being covered apply to a broad range of similar tools. While the distinction between version control and repository hosting is a useful one, it is far less clear in practice and this can cause confusion for some students - particularly those with prior git/GitHub experience. For example, most repository hosting services provide access to some aspects of the underlying version control tools for the repositories that they host (e.g. it is possible to create branches and commit changes via the GitHub user interface).
+            <term>Version control</term> and <term>repository hosting</term> are defined as collaboration tools and a distinction is drawn between them. A number of different examples of each, e.g. svn/mercurial for version control and GitLab/SourceForge for repository hosting, are mentioned for breadth. This can also help to emphasize that while the GitKit focuses on Git and GitHub, that the concepts being covered apply to a broad range of similar tools. While the distinction between version control and repository hosting is a useful one, it is far less clear in practice and this can cause confusion for some students - particularly those with prior Git/GitHub experience. For example, most repository hosting services provide access to some aspects of the underlying version control tools for the repositories that they host (e.g. it is possible to create branches and commit changes via the GitHub user interface).
           </p>
         </li>
         <li>
           <title>Slides 10-15</title>
           <p>
-            The GitKit uses sequences of diagrams to visualize key concepts and processes related to the use of git and GitHub and the forking workflow. Diagrams in the same style are used throughout all of the GitKit topics. A key to success with the GitKit, for both faculty and students, is understanding these diagrams and being able to connect what they depict to the git/GitHub commands used in the forking workflow.
+            The GitKit uses sequences of diagrams to visualize key concepts and processes related to the use of Git and GitHub and the forking workflow. Diagrams in the same style are used throughout all of the GitKit topics. A key to success with the GitKit, for both faculty and students, is understanding these diagrams and being able to connect what they depict to the Git/GitHub commands used in the forking workflow.
           </p>
           <p>
-            The first series of diagrams show the relationship between the three copies of a FOSS project's repository that a developer interacts with (upstream, origin and local). They also illustrate the connection between these three copies and the git and GitHub commands that create them (fork and clone).  A distinction is also made between remote copies of the repository, those residing in the cloud (the upstream and origin), and the local copy that resides in the student's development environment.  Note, that when using a KitClient the development environment is running via GitHub Codespaces and not on the student's physical machine.  This can be a source of confusion and it is worth spending some time clarifying this relationship.
+            The first series of diagrams show the relationship between the three copies of a FOSS project's repository that a developer interacts with (upstream, origin and local). They also illustrate the connection between these three copies and the Git and GitHub commands that create them (fork and clone).  A distinction is also made between remote copies of the repository, those residing in the cloud (the upstream and origin), and the local copy that resides in the student's development environment.  Note, that when using a KitClient the development environment is running via GitHub Codespaces and not on the student's physical machine.  This can be a source of confusion and it is worth spending some time clarifying this relationship.
           </p>
           <p>
             The hands-on activities provide detailed instructions for creating a fork in GitHub, starting the KitClient and creating a local clone.  However, if time allows it may be also be helpful to demonstrate these actions in class.
@@ -143,7 +143,7 @@
         <li>
           <title>Slides 17-20</title>
           <p>
-            A second series of diagrams introduce a basic FOSS workflow that illustrates how upstreaming works. Note that this is not the full forking workflow, as it does not include the use of feature branches and ignores the details of staging and committing changes. The primary purpose of this sequence of diagrams is to illustrate how the concept of upstreaming from the Cookie video is implemented using git/GitHub. Additional details of the forking workflow (branch, edit, stage, commit) are added in the second topic and revisited in the third topic.
+            A second series of diagrams introduce a basic FOSS workflow that illustrates how upstreaming works. Note that this is not the full forking workflow, as it does not include the use of feature branches and ignores the details of staging and committing changes. The primary purpose of this sequence of diagrams is to illustrate how the concept of upstreaming from the Cookie video is implemented using Git/GitHub. Additional details of the forking workflow (branch, edit, stage, commit) are added in the second topic and revisited in the third topic.
           </p>
         </li>
         <li>

source/ch-instructor-guide/sec-instructor-merge-conflicts.ptx

@@ -10,7 +10,7 @@
       At the start of this chapter students will have made pull requests for the "Round 2" issues. Initially GitHub will report that these PRs can be merged automatically. However, the instructor will begin this topic by introducing changes to the upstream <c>main</c> that create merge conflicts with the fixes to each of the "Round 2" issues.  Students will then observe that their PRs go from being able to be merged automatically to containing conflicts.
     </p>
     <p>
-      This chapter then focuses on the resolution of merge conflicts.  The concepts of merge commits, common ancestors, best common ancestor, and non-conflicting and conflicting changes are introduced. The topic then covers the process of merging main into a feature branch, git's raw conflict information and the use of a basic merge tool.  The hands-on activity concludes with the students having resolved the merge conflict in their "Round 2" pull request.  Note that these PRs are never merged into the upstream as part of the GitKit activities.    
+      This chapter then focuses on the resolution of merge conflicts.  The concepts of merge commits, common ancestors, best common ancestor, and non-conflicting and conflicting changes are introduced. The topic then covers the process of merging main into a feature branch, Git's raw conflict information and the use of a basic merge tool.  The hands-on activity concludes with the students having resolved the merge conflict in their "Round 2" pull request.  Note that these PRs are never merged into the upstream as part of the GitKit activities.    
     </p>
     <p>
       The exercises in this chapter have the students perform the following major tasks:
@@ -89,7 +89,7 @@
             Uses a text based example to introduce the concepts of <term>common ancestors</term> and <term>best common ancestor</term>, and then uses those to identify <term>conflicting changes</term> and <term>non-conflicting changes</term>.  One way to identify these changes is first to compare the feature branch to the best common ancestor and highlight all changes in the feature branch.  Then repeat, but compare the <code>main</code> branch to the best common ancestor and highlight all differences in the <code>main</code> branch.  Then any lines that are highlighted in both the feature branch and the <code>main</code> branch are conflicting changes. All other highlighted lines are non-conflicting changes.
           </p>
           <p>
-            Note that in these examples the identification of conflicting changes is simplified to be <em>line based</em>.  That is, if a change is found, the entire line is marked as containing a change.  Similarly, if a line is changed in both the feature branch and the <code>main</code> branch, the entire line is marked as a conflict.  The algorithm used by git is more complex than this simplified approach, but the concept is sufficiently the same for the purposes of these activities.
+            Note that in these examples the identification of conflicting changes is simplified to be <em>line based</em>.  That is, if a change is found, the entire line is marked as containing a change.  Similarly, if a line is changed in both the feature branch and the <code>main</code> branch, the entire line is marked as a conflict.  The algorithm used by Git is more complex than this simplified approach, but the concept is sufficiently the same for the purposes of these activities.
           </p>
         </li>
         <li>
@@ -132,7 +132,7 @@
             Slide 20
           </title>
           <p>
-            Shows the <code>raw merge conflict</code> information that is produced by git when a merge creates a conflict.  This information can be edited manually in any text editor.  However, it is often difficult to identify exactly what changes exist.  This is good motivation for the use of a <term>graphical merge tool</term> that makes it easier to see what changes have been made and where the conflicts exist.
+            Shows the <code>raw merge conflict</code> information that is produced by Git when a merge creates a conflict.  This information can be edited manually in any text editor.  However, it is often difficult to identify exactly what changes exist.  This is good motivation for the use of a <term>graphical merge tool</term> that makes it easier to see what changes have been made and where the conflicts exist.
           </p>
         </li>
         <li>