Wording/grammar/clarification tweaks to "Recording Changes" section

No major changes, just some rewording and clarification where I thought
it was useful.

Author: robertpjday

book/02-git-basics/sections/recording-changes.asc

@@ -1,15 +1,16 @@
 === Recording Changes to the Repository
 
-You have a bona fide Git repository and a checkout or working copy of the files for that project.
-You need to make some changes and commit snapshots of those changes into your repository each time the project reaches a state you want to record.
+At this point, you should have a _bona fide_ Git repository on your local machine, and a checkout or _working copy_ of all of its files in front of you.
+Typically, you'll want to start making changes and committing snapshots of those changes into your repository each time the project reaches a state you want to record.
+
+Remember that each file in your working directory can be in one of two states: _tracked_ or _untracked_.
+Tracked files are files that were in the last snapshot; they can be unmodified, modified, or staged; in short, tracked files are files that Git knows about.
 
-Remember that each file in your working directory can be in one of two states: tracked or untracked.
-Tracked files are files that were in the last snapshot; they can be unmodified, modified, or staged.
 Untracked files are everything else – any files in your working directory that were not in your last snapshot and are not in your staging area.
 When you first clone a repository, all of your files will be tracked and unmodified because Git just checked them out and you haven't edited anything.
 
 As you edit files, Git sees them as modified, because you've changed them since your last commit.
-You stage these modified files and then commit all your staged changes, and the cycle repeats.
+As you work, you selectively stage these modified files and then commit all those staged changes, and the cycle repeats.
 
 .The lifecycle of the status of your files.
 image::images/lifecycle.png[The lifecycle of the status of your files.]
@@ -213,12 +214,12 @@ $ cat .gitignore
 The first line tells Git to ignore any files ending in ``.o'' or ``.a'' – object and archive files that may be the product of building your code.
 The second line tells Git to ignore all files whose names end with a tilde (`~`), which is used by many text editors such as Emacs to mark temporary files.
 You may also include a log, tmp, or pid directory; automatically generated documentation; and so on.
-Setting up a `.gitignore` file before you get going is generally a good idea so you don't accidentally commit files that you really don't want in your Git repository.
+Setting up a `.gitignore` file for your new repository before you get going is generally a good idea so you don't accidentally commit files that you really don't want in your Git repository.
 
 The rules for the patterns you can put in the `.gitignore` file are as follows:
 
 *  Blank lines or lines starting with `#` are ignored.
-*  Standard glob patterns work.
+*  Standard glob patterns work, and will be applied recursively throughout the entire working tree.
 *  You can start patterns with a forward slash (`/`) to avoid recursivity.
 *  You can end patterns with a forward slash (`/`) to specify a directory.
 *  You can negate a pattern by starting it with an exclamation point (`!`).
@@ -231,7 +232,7 @@ Here is another example `.gitignore` file:
 
 [source]
 ----
-# no .a files
+# ignore all .a files
 *.a
 
 # but do track lib.a, even though you're ignoring .a files above