Merge pull request #1848 from petk/patch-images

Sync image alt descriptions with captions

Author: ben

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 diagram
 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 diagram
 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 diagram
 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.

book/01-introduction/sections/installing.asc

@@ -48,7 +48,7 @@ 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
+.Git macOS installer
 image::images/git-osx-installer.png[Git macOS installer]
 
 ==== Installing on Windows

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

@@ -86,7 +86,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
-image::images/areas.png["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.
 These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify.

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

@@ -151,20 +151,20 @@ Suppose you clone from a central server and then do some work off that.
 Your commit history looks like this:
 
 .Clone a repository, and base some work on it
-image::images/perils-of-rebasing-1.png["Clone a repository, and base some work on it."]
+image::images/perils-of-rebasing-1.png["Clone a repository, and base some work on it"]
 
 Now, someone else does more work that includes a merge, and pushes that work to the central server.
 You fetch it and merge the new remote branch into your work, making your history look something like this:
 
 .Fetch more commits, and merge them into your work
-image::images/perils-of-rebasing-2.png["Fetch more commits, and merge them into your work."]
+image::images/perils-of-rebasing-2.png["Fetch more commits, and merge them into your work"]
 
 Next, the person who pushed the merged work decides to go back and rebase their work instead; they do a `git push --force` to overwrite the history on the server.
 You then fetch from that server, bringing down the new commits.
 
 [[_pre_merge_rebase_work]]
 .Someone pushes rebased commits, abandoning commits you've based your work on
-image::images/perils-of-rebasing-3.png["Someone pushes rebased commits, abandoning commits you've based your work on."]
+image::images/perils-of-rebasing-3.png["Someone pushes rebased commits, abandoning commits you've based your work on"]
 
 Now you're both in a pickle.
 If you do a `git pull`, you'll create a merge commit which includes both lines of history, and your repository will look like this:

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

@@ -28,7 +28,7 @@ If you run `git clone -o booyah` instead, then you will have `booyah/master` as
 ====
 
 .Server and local repositories after cloning
-image::images/remote-branches-1.png[Server and local repositories after cloning.]
+image::images/remote-branches-1.png[Server and local repositories after cloning]
 
 If you do some work on your local `master` branch, and, in the meantime, someone else pushes to `git.ourcompany.com` and updates its `master` branch, then your histories move forward differently.
 Also, as long as you stay out of contact with your `origin` server, your `origin/master` pointer doesn't move.
@@ -40,7 +40,7 @@ To synchronize your work with a given remote, you run a `git fetch <remote>` com
 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-tracking branches]
 
 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`.
@@ -54,7 +54,7 @@ Now, you can run `git fetch teamone` to fetch everything the remote `teamone` se
 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

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

@@ -334,7 +334,7 @@ image::images/merging-workflows-4.png[After a topic branch merge]
 
 [[merwf_e]]
 .After a project release
-image::images/merging-workflows-5.png[After a topic branch release]
+image::images/merging-workflows-5.png[After a project release]
 
 This way, when people clone your project's repository, they can either check out `master` to build the latest stable version and keep up to date on that easily, or they can check out `develop`, which is the more cutting-edge content.
 You can also extend this concept by having an `integrate` branch where all the work is merged together.

book/06-github/sections/1-setting-up-account.asc

@@ -37,7 +37,7 @@ image::images/account-settings.png[The “Account settings” link]
 
 Then select the "`SSH keys`" section along the left-hand side.
 
-.The "`SSH keys`" link.
+.The "`SSH keys`" link
 image::images/ssh-keys.png[The “SSH keys” link]
 
 From there, click the "`Add an SSH key`" button, give your key a name, paste the contents of your `~/.ssh/id_rsa.pub` (or whatever you named it) public-key file into the text area, and click "`Add key`".
@@ -59,7 +59,7 @@ image::images/your-profile.png[The “Profile” link]
 
 We'll choose a copy of the Git logo that is on our hard drive and then we get a chance to crop it.
 
-.Crop your avatar
+.Crop your uploaded avatar
 image::images/avatar-crop.png[Crop your uploaded avatar]
 
 Now anywhere you interact on the site, people will see your avatar next to your username.
@@ -72,7 +72,7 @@ The way that GitHub maps your Git commits to your user is by email address.
 If you use multiple email addresses in your commits and you want GitHub to link them up properly, you need to add all the email addresses you have used to the Emails section of the admin section.
 
 [[_add_email_addresses]]
-.Add email addresses
+.Add all your email addresses
 image::images/email-settings.png[Add all your email addresses]
 
 In <<_add_email_addresses>> we can see some of the different states that are possible.

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

@@ -135,7 +135,7 @@ It is almost always worthwhile to put some effort into this, since a good descri
 We also see a list of the commits in our topic branch that are "`ahead`" of the `master` branch (in this case, just the one) and a unified diff of all the changes that will be made should this branch get merged by the project owner.
 
 .Pull Request creation page
-image::images/blink-03-pull-request-open.png[Pull Request creation]
+image::images/blink-03-pull-request-open.png[Pull Request creation page]
 
 When you hit the 'Create pull request' button on this screen, the owner of the project you forked will get a notification that someone is suggesting a change and will link to a page that has all of this information on it.
 
@@ -154,22 +154,22 @@ Where this conversation may take place over email in the workflows presented in
 The project owner can review the unified diff and leave a comment by clicking on any of the lines.
 
 .Comment on a specific line of code in a Pull Request
-image::images/blink-04-pr-comment.png[PR line comment]
+image::images/blink-04-pr-comment.png[Comment on a specific line of code in a Pull Request]
 
 Once the maintainer makes this comment, the person who opened the Pull Request (and indeed, anyone else watching the repository) will get a notification.
 We'll go over customizing this later, but if he had email notifications turned on, Tony would get an email like this:
 
 [[_email_notification]]
 .Comments sent as email notifications
-image::images/blink-04-email.png[Email notification]
+image::images/blink-04-email.png[Comments sent as email notifications]
 
 Anyone can also leave general comments on the Pull Request.
 In <<_pr_discussion>> we can see an example of the project owner both commenting on a line of code and then leaving a general comment in the discussion section.
 You can see that the code comments are brought into the conversation as well.
 
 [[_pr_discussion]]
 .Pull Request discussion page
-image::images/blink-05-general-comment.png[PR discussion page]
+image::images/blink-05-general-comment.png[Pull Request discussion page]
 
 Now the contributor can see what they need to do in order to get their change accepted.
 Luckily this is very straightforward.
@@ -180,7 +180,7 @@ Adding commits to an existing Pull Request doesn't trigger a notification, so on
 
 [[_pr_final]]
 .Pull Request final
-image::images/blink-06-final.png[PR final]
+image::images/blink-06-final.png[Pull Request final]
 
 An interesting thing to notice is that if you click on the "`Files Changed`" tab on this Pull Request, you'll get the "`unified`" diff -- that is, the total aggregate difference that would be introduced to your main branch if this topic branch was merged in.
 In `git diff` terms, it basically automatically shows you `git diff master...<branch>` for the branch this Pull Request is based on.
@@ -229,7 +229,7 @@ GitHub will test this for you and let you know at the bottom of every Pull Reque
 
 [[_pr_fail]]
 .Pull Request does not merge cleanly
-image::images/pr-01-fail.png[PR merge failure]
+image::images/pr-01-fail.png[Pull Request does not merge cleanly]
 
 If you see something like <<_pr_fail>>, you'll want to fix your branch so that it turns green and the maintainer doesn't have to do extra work.
 
@@ -287,7 +287,7 @@ Once you do that, the Pull Request will be automatically updated and re-checked
 
 [[_pr_merge_fix]]
 .Pull Request now merges cleanly
-image::images/pr-02-merge-fix.png[PR fixed]
+image::images/pr-02-merge-fix.png[Pull Request now merges cleanly]
 
 One of the great things about Git is that you can do that continuously.
 If you have a very long-running project, you can easily merge from the target branch over and over again and only have to deal with conflicts that have arisen since the last time that you merged, making the process very manageable.
@@ -314,13 +314,13 @@ We can fill out the description just like <<_pr_references>>.
 
 [[_pr_references]]
 .Cross references in a Pull Request
-image::images/mentions-01-syntax.png[PR references]
+image::images/mentions-01-syntax.png[Cross references in a Pull Request]
 
 When we submit this pull request, we'll see all of that rendered like <<_pr_references_render>>.
 
 [[_pr_references_render]]
 .Cross references rendered in a Pull Request
-image::images/mentions-02-render.png[PR references rendered]
+image::images/mentions-02-render.png[Cross references rendered in a Pull Request]
 
 Notice that the full GitHub URL we put in there was shortened to just the information needed.
 
@@ -330,7 +330,7 @@ The link will look something like <<_pr_closed>>.
 
 [[_pr_closed]]
 .Link back to the new Pull Request in the closed Pull Request timeline
-image::images/mentions-03-closed.png[PR closed]
+image::images/mentions-03-closed.png[Link back to the new Pull Request in the closed Pull Request timeline]
 
 In addition to issue numbers, you can also reference a specific commit by SHA-1.
 You have to specify a full 40 character SHA-1, but if GitHub sees that in a comment, it will link directly to the commit.
@@ -346,7 +346,7 @@ See <<_example_markdown>> for an example of how comments or text can be written
 
 [[_example_markdown]]
 .An example of GitHub Flavored Markdown as written and as rendered
-image::images/markdown-01-example.png[Example Markdown]
+image::images/markdown-01-example.png[An example of GitHub Flavored Markdown as written and as rendered]
 
 The GitHub flavor of Markdown adds more things you can do beyond the basic Markdown syntax.
 These can all be really useful when creating useful Pull Request or Issue comments or descriptions.
@@ -370,7 +370,7 @@ If we include this in the description of our Pull Request or Issue, we'll see it
 
 [[_eg_task_lists]]
 .Task lists rendered in a Markdown comment
-image::images/markdown-02-tasks.png[Example Task List]
+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.
 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.
@@ -382,7 +382,7 @@ You can see an example of this in <<_task_list_progress>>.
 
 [[_task_list_progress]]
 .Task list summary in the Pull Request list
-image::images/markdown-03-task-summary.png[Example Task List]
+image::images/markdown-03-task-summary.png[Task list summary in the Pull Request list]
 
 These are incredibly useful when you open a Pull Request early and use it to track your progress through the implementation of the feature.
 
@@ -409,7 +409,7 @@ In the case of the above example, it would end up rendering like <<_md_code>>.
 
 [[_md_code]]
 .Rendered fenced code example
-image::images/markdown-04-fenced-code.png[Rendered fenced code]
+image::images/markdown-04-fenced-code.png[Rendered fenced code example]
 
 ===== Quoting
 
@@ -431,7 +431,7 @@ Once rendered, the comment will look like <<_md_quote>>.
 
 [[_md_quote]]
 .Rendered quoting example
-image::images/markdown-05-quote.png[Rendered quoting]
+image::images/markdown-05-quote.png[Rendered quoting example]
 
 ===== Emoji
 
@@ -442,7 +442,7 @@ If you are typing a comment and you start with a `:` character, an autocompleter
 
 [[_md_emoji_auto]]
 .Emoji autocompleter in action
-image::images/markdown-06-emoji-complete.png[Emoji autocompleter]
+image::images/markdown-06-emoji-complete.png[Emoji autocompleter in action]
 
 Emojis take the form of `:<name>:` anywhere in the comment.
 For instance, you could write something like this:
@@ -462,7 +462,7 @@ When rendered, it would look something like <<_md_emoji>>.
 
 [[_md_emoji]]
 .Heavy emoji commenting
-image::images/markdown-07-emoji.png[Emoji]
+image::images/markdown-07-emoji.png[Heavy emoji commenting]
 
 Not that this is incredibly useful, but it does add an element of fun and emotion to a medium that is otherwise hard to convey emotion in.
 
@@ -482,7 +482,7 @@ In addition to adding Markdown image links to comments, which can be difficult t
 
 [[_md_drag]]
 .Drag and drop images to upload them and auto-embed them
-image::images/markdown-08-drag-drop.png[Drag and drop images]
+image::images/markdown-08-drag-drop.png[Drag and drop images to upload them and auto-embed them]
 
 If you look at <<_md_drag>>, you can see a small "`Parsed as Markdown`" hint above the text area.
 Clicking on that will give you a full cheat sheet of everything you can do with Markdown on GitHub.