[Fix] remove period from text present in square bracket

There is no need for period mark at end of text, present in square
bracket; and removing it also make syntax consistent across whole
project.

Author: Vipul Kumar

book/01-introduction/sections/installing.asc

@@ -49,7 +49,7 @@ If you want a more up to date version, you can also install it via a binary inst
 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.]
+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.

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

@@ -12,7 +12,7 @@ Conceptually, most other systems store information as a list of file-based chang
 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.]
+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.
@@ -21,7 +21,7 @@ To be efficient, if files have not changed, Git doesn't store the file again, ju
 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.]
+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.

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

@@ -14,7 +14,7 @@ As you edit files, Git sees them as modified, because you've changed them since
 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.]
+image::images/lifecycle.png[The lifecycle of the status of your files]
 
 [[_checking_status]]
 ==== Checking the Status of Your Files

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:

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.

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

@@ -10,14 +10,14 @@ In this section you'll learn what rebasing is, how to do it, why it's a pretty a
 If you go back to an earlier example from <<_basic_merging>>, you can see that you diverged your work and made commits on two different branches.
 
 .Simple divergent history
-image::images/basic-rebase-1.png[Simple divergent history.]
+image::images/basic-rebase-1.png[Simple divergent history]
 
 The easiest way to integrate the branches, as we've already covered, is the `merge` command.
 It performs a three-way merge between the two latest branch snapshots (`C3` and `C4`) and the most recent common ancestor of the two (`C2`), creating a new snapshot (and commit).
 
 [[rebasing-merging-example]]
 .Merging to integrate diverged work history
-image::images/basic-rebase-2.png[Merging to integrate diverged work history.]
+image::images/basic-rebase-2.png[Merging to integrate diverged work history]
 
 However, there is another way: you can take the patch of the change that was introduced in `C4` and reapply it on top of `C3`.
 In Git, this is called _rebasing_.
@@ -36,7 +36,7 @@ Applying: added staged command
 This operation works by going to the common ancestor of the two branches (the one you're on and the one you're rebasing onto), getting the diff introduced by each commit of the branch you're on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn.
 
 .Rebasing the change introduced in `C4` onto `C3`
-image::images/basic-rebase-3.png[Rebasing the change introduced in `C4` onto `C3`.]
+image::images/basic-rebase-3.png[Rebasing the change introduced in `C4` onto `C3`]
 
 At this point, you can go back to the `master` branch and do a fast-forward merge.
 
@@ -47,7 +47,7 @@ $ git merge experiment
 ----
 
 .Fast-forwarding the `master` branch
-image::images/basic-rebase-4.png[Fast-forwarding the `master` branch.]
+image::images/basic-rebase-4.png[Fast-forwarding the `master` branch]
 
 Now, the snapshot pointed to by `C4'` is exactly the same as the one that was pointed to by `C5` in <<rebasing-merging-example,the merge example>>.
 There is no difference in the end product of the integration, but rebasing makes for a cleaner history.
@@ -70,7 +70,7 @@ Finally, you went back to your server branch and did a few more commits.
 
 [[rbdiag_e]]
 .A history with a topic branch off another topic branch
-image::images/interesting-rebase-1.png[A history with a topic branch off another topic branch.]
+image::images/interesting-rebase-1.png[A history with a topic branch off another topic branch]
 
 Suppose you decide that you want to merge your client-side changes into your mainline for a release, but you want to hold off on the server-side changes until it's tested further.
 You can take the changes on `client` that aren't on `server` (`C8` and `C9`) and replay them on your `master` branch by using the `--onto` option of `git rebase`:
@@ -84,7 +84,7 @@ This basically says, ``Take the `client` branch, figure out the patches since it
 It's a bit complex, but the result is pretty cool.
 
 .Rebasing a topic branch off another topic branch
-image::images/interesting-rebase-2.png[Rebasing a topic branch off another topic branch.]
+image::images/interesting-rebase-2.png[Rebasing a topic branch off another topic branch]
 
 Now you can fast-forward your `master` branch (see <<rbdiag_g>>):
 
@@ -96,7 +96,7 @@ $ git merge client
 
 [[rbdiag_g]]
 .Fast-forwarding your `master` branch to include the client branch changes
-image::images/interesting-rebase-3.png[Fast-forwarding your `master` branch to include the client branch changes.]
+image::images/interesting-rebase-3.png[Fast-forwarding your `master` branch to include the client branch changes]
 
 Let's say you decide to pull in your server branch as well.
 You can rebase the `server` branch onto the `master` branch without having to check it out first by running `git rebase <basebranch> <topicbranch>` -- which checks out the topic branch (in this case, `server`) for you and replays it onto the base branch (`master`):
@@ -110,7 +110,7 @@ This replays your `server` work on top of your `master` work, as shown in <<rbdi
 
 [[rbdiag_h]]
 .Rebasing your server branch on top of your `master` branch
-image::images/interesting-rebase-4.png[Rebasing your server branch on top of your `master` branch.]
+image::images/interesting-rebase-4.png[Rebasing your server branch on top of your `master` branch]
 
 Then, you can fast-forward the base branch (`master`):
 
@@ -130,7 +130,7 @@ $ git branch -d server
 
 [[rbdiag_i]]
 .Final commit history
-image::images/interesting-rebase-5.png[Final commit history.]
+image::images/interesting-rebase-5.png[Final commit history]
 
 [[_rebase_peril]]
 ==== The Perils of Rebasing
@@ -171,7 +171,7 @@ If you do a `git pull`, you'll create a merge commit which includes both lines o
 
 [[_merge_rebase_work]]
 .You merge in the same work again into a new merge commit
-image::images/perils-of-rebasing-4.png[You merge in the same work again into a new merge commit.]
+image::images/perils-of-rebasing-4.png[You merge in the same work again into a new merge commit]
 
 If you run a `git log` when your history looks like this, you'll see two commits that have the same author, date, and message, which will be confusing.
 Furthermore, if you push this history back up to the server, you'll reintroduce all those rebased commits to the central server, which can further confuse people.
@@ -199,7 +199,7 @@ So instead of the result we see in <<_merge_rebase_work>>, we would end up with
 
 [[_rebase_rebase_work]]
 .Rebase on top of force-pushed rebase work
-image::images/perils-of-rebasing-5.png[Rebase on top of force-pushed rebase work.]
+image::images/perils-of-rebasing-5.png[Rebase on top of force-pushed rebase work]
 
 This only works if `C4` and `C4'` that your partner made are almost exactly the same patch.
 Otherwise the rebase won't be able to tell that it's a duplicate and will add another C4-like patch (which will probably fail to apply cleanly, since the changes would already be at least somewhat there).

book/03-git-branching/sections/remote-branches.asc

@@ -34,27 +34,27 @@ If you do some work on your local `master` branch, and, in the meantime, someone
 Also, as long as you stay out of contact with your `origin` server, your `origin/master` pointer doesn't move.
 
 .Local and remote work can diverge
-image::images/remote-branches-2.png[Local and remote work can diverge.]
+image::images/remote-branches-2.png[Local and remote work can diverge]
 
 To synchronize your work with a given remote, you run a `git fetch <remote>` command (in our case, `git fetch origin`).
 This command looks up which server ``origin'' is (in this case, it's `git.ourcompany.com`), fetches any data from it that you don't yet have, and updates your local database, moving your `origin/master` pointer to its new, more up-to-date position.
 
 .`git fetch` updates your remote-tracking branches
-image::images/remote-branches-3.png[`git fetch` updates your remote references.]
+image::images/remote-branches-3.png[`git fetch` updates your remote references]
 
 To demonstrate having multiple remote servers and what remote branches for those remote projects look like, let's assume you have another internal Git server that is used only for development by one of your sprint teams.
 This server is at `git.team1.ourcompany.com`.
 You can add it as a new remote reference to the project you're currently working on by running the `git remote add` command as we covered in <<ch02-git-basics-chapter#ch02-git-basics-chapter>>.
 Name this remote `teamone`, which will be your shortname for that whole URL.
 
 .Adding another server as a remote
-image::images/remote-branches-4.png[Adding another server as a remote.]
+image::images/remote-branches-4.png[Adding another server as a remote]
 
 Now, you can run `git fetch teamone` to fetch everything the remote `teamone` server has that you don't have yet.
 Because that server has a subset of the data your `origin` server has right now, Git fetches no data but sets a remote-tracking branch called `teamone/master` to point to the commit that `teamone` has as its `master` branch.
 
 .Remote-tracking branch for `teamone/master`
-image::images/remote-branches-5.png[Remote tracking branch for `teamone/master`.]
+image::images/remote-branches-5.png[Remote tracking branch for `teamone/master`]
 
 [[_pushing_branches]]
 ==== Pushing