Modified the wording of some sections because some of it did not sit …

book/01-introduction/sections/about-version-control.asc

@@ -5,8 +5,8 @@ What is "`version control`", and why should you care?
 Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later.
 For the examples in this book, you will use software source code as the files being version controlled, though in reality you can do this with nearly any type of file on a computer.
 
-If you are a graphic or web designer and want to keep every version of an image or layout (which you would most certainly want to), a Version Control System (VCS) is a very wise thing to use.
-It allows you to revert selected files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more.
+It would be wise to be using a Version Control System (VCS), especially if you are a graphic or web designer and want to keep every version of an image or layout (which you would most certainly want to).
+A VCS allows you to revert selected files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more.
 Using a VCS also generally means that if you screw things up or lose files, you can easily recover.
 In addition, you get all this for very little overhead.
 

book/01-introduction/sections/first-time-setup.asc

@@ -80,7 +80,7 @@ If you are using another editor, or a 32-bit version, please find specific instr
 [WARNING]
 ====
 You may find, if you don't setup your editor like this, you get into a really confusing state when Git attempts to launch it.
-An example on a Windows system may include a prematurely terminated Git operation during a Git initiated edit.
+An example on a Windows system may include a prematurely terminated Git operation during a Git-initiated edit.
 ====
 
 [[_new_default_branch]]

book/01-introduction/sections/what-is-git.asc

@@ -37,7 +37,7 @@ Because you have the entire history of the project right there on your local dis
 
 For example, to browse the history of the project, Git doesn't need to go out to the server to get the history and display it for you -- it simply reads it directly from your local database.
 This means you see the project history almost instantly.
-If you want to see the changes introduced between the current version of a file and the file a month ago, Git can look up the file a month ago and do a local difference calculation, instead of having to either ask a remote server to do it or pull an older version of the file from the remote server to do it locally.
+If you want to see the changes introduced between the current version of a file and the file a month ago, Git can look up the file (as it looked like a month ago) and do a local difference calculation, instead of having to either ask a remote server to do it or pull an older version of the file from the remote server to do it locally.
 
 This also means that there is very little you can't do if you're offline or off VPN.
 If you get on an airplane or a train and want to do a little work, you can commit happily (to your _local_ copy, remember?) until you get to a network connection to upload.
@@ -63,7 +63,7 @@ A SHA-1 hash looks something like this:
 ----
 
 You will see these hash values all over the place in Git because it uses them so much.
-In fact, Git stores everything in its database not by file name but by the hash value of its contents.
+In fact, Git stores everything in its database not by filename but by the hash value of its contents.
 
 ==== Git Generally Only Adds Data
 

book/03-git-branching/sections/basic-branching-and-merging.asc

@@ -146,7 +146,7 @@ If you need to pull it in, you can merge your `master` branch into your `iss53`
 
 (((branches, merging)))(((merging)))
 Suppose you've decided that your issue #53 work is complete and ready to be merged into your `master` branch.
-In order to do that, you'll merge your `iss53` branch into `master`, much like you merged your `hotfix` branch earlier.
+In order to do that, you'll have to merge your `iss53` branch into `master`, much like when you merged your `hotfix` branch earlier.
 All you have to do is check out the branch you wish to merge into and then run the `git merge` command:
 
 [source,console]

book/03-git-branching/sections/branch-management.asc

@@ -133,14 +133,14 @@ Before you do this, make sure you consult with your collaborators.
 Also, make sure you do a thorough search through your repo and update any references to the old branch name in your code and scripts.
 ====
 
-Rename your local `master` branch into `main` with the following command:
+Rename your local `master` branch to `main` with the following command:
 
 [source,console]
 ----
 $ git branch --move master main
 ----
 
-There's no local `master` branch anymore, because it's renamed to the `main` branch.
+There's no local `master` branch anymore, because it's been renamed to `main`.
 
 To let others see the new `main` branch, you need to push it to the remote.
 This makes the renamed branch available on the remote.

book/03-git-branching/sections/rebasing.asc

@@ -2,7 +2,7 @@
 === Rebasing
 
 (((rebasing)))
-In Git, there are two main ways to integrate changes from one branch into another: the `merge` and the `rebase`.
+In Git, there are two main commands for integrating changes from one branch into another: `merge` and `rebase`.
 In this section you'll learn what rebasing is, how to do it, why it's a pretty amazing tool, and in what cases you won't want to use it.
 
 ==== The Basic Rebase

book/05-distributed-git/sections/contributing.asc

@@ -3,7 +3,7 @@
 
 (((contributing)))
 The main difficulty with describing how to contribute to a project are the numerous variations on how to do that.
-Because Git is very flexible, people can and do work together in many ways, and it's problematic to describe how you should contribute -- every project is a bit different.
+Because Git is very flexible, people can and will work together in many ways. It's difficult to describe how one should contribute to a given project, because every project is a bit different.
 Some of the variables involved are active contributor count, chosen workflow, your commit access, and possibly the external contribution method.
 
 The first variable is active contributor count -- how many users are actively contributing code to this project, and how often?

book/06-github/sections/2-contributing.asc

@@ -371,7 +371,7 @@ If we include this in the description of our Pull Request or Issue, we'll see it
 .Task lists rendered in a Markdown comment
 image::images/markdown-02-tasks.png[Task lists rendered in a Markdown comment]
 
-This is often used in Pull Requests to indicate what all you would like to get done on the branch before the Pull Request will be ready to merge.
+This is often used in Pull Requests to indicate what you would all like to get done on the branch before the Pull Request is ready to be merged.
 The really cool part is that you can simply click the checkboxes to update the comment -- you don't have to edit the Markdown directly to check tasks off.
 
 What's more, GitHub will look for task lists in your Issues and Pull Requests and show them as metadata on the pages that list them out.

book/introduction.asc

@@ -10,7 +10,7 @@ Then, we'll explain how to download Git and set it up for the first time if you
 
 In *Chapter 2*, we will go over basic Git usage -- how to use Git in the 80% of cases you'll encounter most often.
 After reading this chapter, you should be able to clone a repository, see what has happened in the history of the project, modify files, and contribute changes.
-If the book spontaneously combusts at this point, you should already be pretty useful wielding Git in the time it takes you to go pick up another copy.
+If the book spontaneously combusts at this point and you have to go pick up another copy, you should already be pretty skillful at wielding Git.
 
 *Chapter 3* is about the branching model in Git, often described as Git's killer feature.
 Here you'll learn what truly sets Git apart from the pack.