progit · ben · Jul 3, 2020 · Jun 24, 2020 · Jun 26, 2020 · Jun 25, 2020
diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md
@@ -12,7 +12,7 @@ assignees: ''
 <!-- * This bug report is about a single actionable bug. -->
 <!-- * This bug is about the Pro Git book, version 2, English language. -->
 <!-- * This bug is about the book as found on the [website](https://www.git-scm.com/book/en/v2) or the pdf. -->
-<!-- * If you found a issue in the pdf/epub/mobi files, you've checked if the problem is also present in the Pro Git book on the [website](https://www.git-scm.com/book/en/v2). -->
+<!-- * If you found an issue in the pdf/epub/mobi files, you've checked if the problem is also present in the Pro Git book on the [website](https://www.git-scm.com/book/en/v2). -->
 <!-- * This bug is **not** about a translation, if so please file a bug with the translation project. You can find a table of translation projects here: [progit2/TRANSLATING.md](https://github.com/progit/progit2/blob/master/TRANSLATING.md) -->
 <!-- * This bug is **not** about the git-scm.com site, if so please file a bug here: [git-scm.com/issues/new](https://github.com/git/git-scm.com/issues/new) -->
 <!-- * This bug is **not** about git the program itself, if so please file a bug here: [git-scm.com/community](https://git-scm.com/community) -->
@@ -58,7 +58,7 @@ assignees: ''
 - Browser/application version:
 
 **E-book reader:**
-<!-- If you've used a e-book reader to access the content, please fill in this form. -->
+<!-- If you've used an e-book reader to access the content, please fill in this form. -->
 <!-- Example: Amazon Kindle Paperwhite 10th generation, software update 5.11.1 -->
 - Device:
 - Software Update:
diff --git a/book/01-introduction/sections/about-version-control.asc b/book/01-introduction/sections/about-version-control.asc
@@ -19,7 +19,7 @@ It is easy to forget which directory you're in and accidentally write to the wro
 
 To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control.
 
-.Local version control.
+.Local version control
 image::images/local.png[Local version control diagram]
 
 One of the most popular VCS tools was a system called RCS, which is still distributed with many computers today.
@@ -33,7 +33,7 @@ To deal with this problem, Centralized Version Control Systems (CVCSs) were deve
 These systems (such as CVS, Subversion, and Perforce) have a single server that contains all the versioned files, and a number of clients that check out files from that central place. (((CVS)))(((Subversion)))(((Perforce)))
 For many years, this has been the standard for version control.
 
-.Centralized version control.
+.Centralized version control
 image::images/centralized.png[Centralized version control diagram]
 
 This setup offers many advantages, especially over local VCSs.
@@ -54,7 +54,7 @@ In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don't just check ou
 Thus, if any server dies, and these systems were collaborating via that server, any of the client repositories can be copied back up to the server to restore it.
 Every clone is really a full backup of all the data.
 
-.Distributed version control.
+.Distributed version control
 image::images/distributed.png[Distributed version control diagram]
 
 Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project.

diff --git a/book/01-introduction/sections/help.asc b/book/01-introduction/sections/help.asc
@@ -10,7 +10,7 @@ $ git <verb> --help
 $ man git-<verb>
 ----
 
-For example, you can get the manpage help for the `git config` command by running(((git commands, help)))
+For example, you can get the manpage help for the `git config` command by running this:(((git commands, help)))
 
 [source,console]
 ----

diff --git a/book/01-introduction/sections/installing.asc b/book/01-introduction/sections/installing.asc
@@ -48,8 +48,8 @@ If you don't have it installed already, it will prompt you to install it.
 If you want a more up to date version, you can also install it via a binary installer.
 A macOS Git installer is maintained and available for download at the Git website, at https://git-scm.com/download/mac[].
 
-.Git macOS Installer.
-image::images/git-osx-installer.png[Git macOS installer.]
+.Git macOS Installer
+image::images/git-osx-installer.png[Git macOS installer]
 
 You can also install it as part of the GitHub for macOS install.
 Their GUI Git tool has an option to install command line tools as well.
@@ -114,7 +114,7 @@ If you're using a RPM-based distribution (Fedora/RHEL/RHEL-derivatives), you als
 $ sudo dnf install getopt
 ----
 
-Additionally, if you're using Fedora/RHEL/RHEL-derivatives, you need to do this
+Additionally, if you're using Fedora/RHEL/RHEL-derivatives, you need to do this:
 
 [source,console]
 ----

diff --git a/book/01-introduction/sections/what-is-git.asc b/book/01-introduction/sections/what-is-git.asc
@@ -11,17 +11,17 @@ The major difference between Git and any other VCS (Subversion and friends inclu
 Conceptually, most other systems store information as a list of file-based changes.
 These other systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they store as a set of files and the changes made to each file over time (this is commonly described as _delta-based_ version control).
 
-.Storing data as changes to a base version of each file.
-image::images/deltas.png[Storing data as changes to a base version of each file.]
+.Storing data as changes to a base version of each file
+image::images/deltas.png[Storing data as changes to a base version of each file]
 
 Git doesn't think of or store its data this way.
 Instead, Git thinks of its data more like a series of snapshots of a miniature filesystem.
 With Git, every time you commit, or save the state of your project, Git basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot.
 To be efficient, if files have not changed, Git doesn't store the file again, just a link to the previous identical file it has already stored.
 Git thinks about its data more like a *stream of snapshots*.
 
-.Storing data as snapshots of the project over time.
-image::images/snapshots.png[Git stores data as snapshots of the project over time.]
+.Storing data as snapshots of the project over time
+image::images/snapshots.png[Git stores data as snapshots of the project over time]
 
 This is an important distinction between Git and nearly all other VCSs.
 It makes Git reconsider almost every aspect of version control that most other systems copied from the previous generation.
@@ -84,7 +84,7 @@ Git has three main states that your files can reside in: _modified_, _staged_, a
 
 This leads us to the three main sections of a Git project: the working tree, the staging area, and the Git directory.
 
-.Working tree, staging area, and Git directory.
+.Working tree, staging area, and Git directory
 image::images/areas.png["Working tree, staging area, and Git directory."]
 
 The working tree is a single checkout of one version of the project.

diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc
@@ -13,8 +13,8 @@ When you first clone a repository, all of your files will be tracked and unmodif
 As you edit files, Git sees them as modified, because you've changed them since your last commit.
 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.]
+.The lifecycle of the status of your files
+image::images/lifecycle.png[The lifecycle of the status of your files]
 
 [[_checking_status]]
 ==== Checking the Status of Your Files

diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc
@@ -5,7 +5,7 @@ After you have created several commits, or if you have cloned a repository with
 The most basic and powerful tool to do this is the `git log` command.
 
 These examples use a very simple project called ``simplegit''.
-To get the project, run
+To get the project, run:
 
 [source,console]
 ----

diff --git a/book/03-git-branching/sections/basic-branching-and-merging.asc b/book/03-git-branching/sections/basic-branching-and-merging.asc
@@ -22,7 +22,7 @@ You'll do the following:
 First, let's say you're working on your project and have a couple of commits already on the `master` branch.
 
 .A simple commit history
-image::images/basic-branching-1.png[A simple commit history.]
+image::images/basic-branching-1.png[A simple commit history]
 
 You've decided that you're going to work on issue #53 in whatever issue-tracking system your company uses.
 To create a new branch and switch to it at the same time, you can run the `git checkout` command with the `-b` switch:
@@ -42,7 +42,7 @@ $ git checkout iss53
 ----
 
 .Creating a new branch pointer
-image::images/basic-branching-2.png[Creating a new branch pointer.]
+image::images/basic-branching-2.png[Creating a new branch pointer]
 
 You work on your website and do some commits.
 Doing so moves the `iss53` branch forward, because you have it checked out (that is, your `HEAD` is pointing to it):
@@ -54,7 +54,7 @@ $ git commit -a -m 'Create new footer [issue 53]'
 ----
 
 .The `iss53` branch has moved forward with your work
-image::images/basic-branching-3.png[The `iss53` branch has moved forward with your work.]
+image::images/basic-branching-3.png[The `iss53` branch has moved forward with your work]
 
 Now you get the call that there is an issue with the website, and you need to fix it immediately.
 With Git, you don't have to deploy your fix along with the `iss53` changes you've made, and you don't have to put a lot of effort into reverting those changes before you can work on applying your fix to what is in production.
@@ -89,7 +89,7 @@ $ git commit -a -m 'Fix broken email address'
 ----
 
 .Hotfix branch based on `master`
-image::images/basic-branching-4.png[Hotfix branch based on `master`.]
+image::images/basic-branching-4.png[Hotfix branch based on `master`]
 
 You can run your tests, make sure the hotfix is what you want, and finally merge the `hotfix` branch back into your `master` branch to deploy to production.
 You do this with the `git merge` command:(((git commands, merge)))
@@ -111,7 +111,7 @@ To phrase that another way, when you try to merge one commit with a commit that
 Your change is now in the snapshot of the commit pointed to by the `master` branch, and you can deploy the fix.
 
 .`master` is fast-forwarded to `hotfix`
-image::images/basic-branching-5.png[`master` is fast-forwarded to `hotfix`.]
+image::images/basic-branching-5.png[`master` is fast-forwarded to `hotfix`]
 
 After your super-important fix is deployed, you're ready to switch back to the work you were doing before you were interrupted.
 However, first you'll delete the `hotfix` branch, because you no longer need it -- the `master` branch points at the same place.
@@ -136,7 +136,7 @@ $ git commit -a -m 'Finish the new footer [issue 53]'
 ----
 
 .Work continues on `iss53`
-image::images/basic-branching-6.png[Work continues on `iss53`.]
+image::images/basic-branching-6.png[Work continues on `iss53`]
 
 It's worth noting here that the work you did in your `hotfix` branch is not contained in the files in your `iss53` branch.
 If you need to pull it in, you can merge your `master` branch into your `iss53` branch by running `git merge master`, or you can wait to integrate those changes until you decide to pull the `iss53` branch back into `master` later.
@@ -165,13 +165,13 @@ Because the commit on the branch you're on isn't a direct ancestor of the branch
 In this case, Git does a simple three-way merge, using the two snapshots pointed to by the branch tips and the common ancestor of the two.
 
 .Three snapshots used in a typical merge
-image::images/basic-merging-1.png[Three snapshots used in a typical merge.]
+image::images/basic-merging-1.png[Three snapshots used in a typical merge]
 
 Instead of just moving the branch pointer forward, Git creates a new snapshot that results from this three-way merge and automatically creates a new commit that points to it.
 This is referred to as a merge commit, and is special in that it has more than one parent.
 
 .A merge commit
-image::images/basic-merging-2.png[A merge commit.]
+image::images/basic-merging-2.png[A merge commit]
 
 Now that your work is merged in, you have no further need for the `iss53` branch.
 You can close the issue in your issue-tracking system, and delete the branch:

diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc
@@ -23,12 +23,12 @@ Git then creates a commit object that has the metadata and a pointer to the root
 Your Git repository now contains five objects: three _blobs_ (each representing the contents of one of the three files), one _tree_ that lists the contents of the directory and specifies which file names are stored as which blobs, and one _commit_ with the pointer to that root tree and all the commit metadata.
 
 .A commit and its tree
-image::images/commit-and-tree.png[A commit and its tree.]
+image::images/commit-and-tree.png[A commit and its tree]
 
 If you make some changes and commit again, the next commit stores a pointer to the commit that came immediately before it.
 
 .Commits and their parents
-image::images/commits-and-parents.png[Commits and their parents.]
+image::images/commits-and-parents.png[Commits and their parents]
 
 A branch in Git is simply a lightweight movable pointer to one of these commits.
 The default branch name in Git is `master`.
@@ -43,7 +43,7 @@ The only reason nearly every repository has one is that the `git init` command c
 ====
 
 .A branch and its commit history
-image::images/branch-and-history.png[A branch and its commit history.]
+image::images/branch-and-history.png[A branch and its commit history]
 
 [[_create_new_branch]]
 ==== Creating a New Branch
@@ -62,7 +62,7 @@ $ git branch testing
 This creates a new pointer to the same commit you're currently on.
 
 .Two branches pointing into the same series of commits
-image::images/two-branches.png[Two branches pointing into the same series of commits.]
+image::images/two-branches.png[Two branches pointing into the same series of commits]
 
 How does Git know what branch you're currently on?
 It keeps a special pointer called `HEAD`.
@@ -72,7 +72,7 @@ In this case, you're still on `master`.
 The `git branch` command only _created_ a new branch -- it didn't switch to that branch.
 
 .HEAD pointing to a branch
-image::images/head-to-master.png[HEAD pointing to a branch.]
+image::images/head-to-master.png[HEAD pointing to a branch]
 
 You can easily see this by running a simple `git log` command that shows you where the branch pointers are pointing.
 This option is called `--decorate`.
@@ -102,7 +102,7 @@ $ git checkout testing
 This moves `HEAD` to point to the `testing` branch.
 
 .HEAD points to the current branch
-image::images/head-to-testing.png[HEAD points to the current branch.]
+image::images/head-to-testing.png[HEAD points to the current branch]
 
 What is the significance of that?
 Well, let's do another commit:
@@ -114,7 +114,7 @@ $ git commit -a -m 'made a change'
 ----
 
 .The HEAD branch moves forward when a commit is made
-image::images/advance-testing.png[The HEAD branch moves forward when a commit is made.]
+image::images/advance-testing.png[The HEAD branch moves forward when a commit is made]
 
 This is interesting, because now your `testing` branch has moved forward, but your `master` branch still points to the commit you were on when you ran `git checkout` to switch branches.
 Let's switch back to the `master` branch:
@@ -137,7 +137,7 @@ To show all of the branches, add `--all` to your `git log` command.
 ====
 
 .HEAD moves when you checkout
-image::images/checkout-master.png[HEAD moves when you checkout.]
+image::images/checkout-master.png[HEAD moves when you checkout]
 
 That command did two things.
 It moved the HEAD pointer back to point to the `master` branch, and it reverted the files in your working directory back to the snapshot that `master` points to.
@@ -167,7 +167,7 @@ And you did all that with simple `branch`, `checkout`, and `commit` commands.
 
 [[divergent_history]]
 .Divergent history
-image::images/advance-master.png[Divergent history.]
+image::images/advance-master.png[Divergent history]
 
 You can also see this easily with the `git log` command.
 If you run `git log --oneline --decorate --graph --all` it will print out the history of your commits, showing where your branch pointers are and how your history has diverged.