From 37ad532f84ec212f381cb5e5481724766ee0c2fe Mon Sep 17 00:00:00 2001 From: Vipul Kumar Date: Wed, 24 Jun 2020 06:33:20 +0000 Subject: [PATCH 1/9] [Fix] remove period mark from the figure captions If a paragraph ends with a figure caption, it ends with double period marks. One of them is due to figure caption, which itself ends with a period and other is for end of paragraph. So removing period from figure captions would be a good idea, as Ben has suggested[1]. Due to this commit, now some paragraphs don't have any period mark at end of paragraph. Those period are their because of caption, that's paragraphs itself don't end with any period, see [2]. [1]: https://github.com/progit/progit2/issues/1437#issuecomment-643633534 [2]: https://github.com/progit/progit2/pull/1444#issuecomment-648754034 Resolves: #1437 --- .../sections/about-version-control.asc | 6 ++-- book/01-introduction/sections/installing.asc | 2 +- book/01-introduction/sections/what-is-git.asc | 6 ++-- .../sections/recording-changes.asc | 2 +- book/03-git-branching/sections/rebasing.asc | 2 +- book/04-git-server/sections/gitlab.asc | 8 ++--- book/04-git-server/sections/gitweb.asc | 2 +- .../sections/contributing.asc | 32 +++++++++---------- .../sections/distributed-workflows.asc | 6 ++-- .../sections/maintaining.asc | 18 +++++------ .../sections/1-setting-up-account.asc | 8 ++--- book/06-github/sections/2-contributing.asc | 26 +++++++-------- book/06-github/sections/3-maintaining.asc | 32 +++++++++---------- .../sections/4-managing-organization.asc | 8 ++--- book/06-github/sections/5-scripting.asc | 14 ++++---- .../sections/revision-selection.asc | 2 +- .../sections/attributes.asc | 4 +-- book/08-customizing-git/sections/config.asc | 2 +- .../sections/client-p4.asc | 4 +-- .../sections/client-tfs.asc | 2 +- book/10-git-internals/sections/objects.asc | 6 ++-- book/10-git-internals/sections/refs.asc | 2 +- .../sections/bash.asc | 2 +- .../sections/eclipse.asc | 2 +- .../sections/guis.asc | 12 +++---- .../sections/jetbrainsides.asc | 2 +- .../sections/powershell.asc | 2 +- .../sections/visualstudio.asc | 4 +-- 28 files changed, 109 insertions(+), 109 deletions(-) diff --git a/book/01-introduction/sections/about-version-control.asc b/book/01-introduction/sections/about-version-control.asc index 0b0025803..630ee2345 100644 --- 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/installing.asc b/book/01-introduction/sections/installing.asc index 102bb787a..6f0a2730d 100644 --- a/book/01-introduction/sections/installing.asc +++ b/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.] You can also install it as part of the GitHub for macOS install. diff --git a/book/01-introduction/sections/what-is-git.asc b/book/01-introduction/sections/what-is-git.asc index f9792f8ba..47f904ec6 100644 --- a/book/01-introduction/sections/what-is-git.asc +++ b/book/01-introduction/sections/what-is-git.asc @@ -11,7 +11,7 @@ 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. +.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. @@ -20,7 +20,7 @@ With Git, every time you commit, or save the state of your project, Git basicall 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. +.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. @@ -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 index 60bfec591..ee76585af 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -13,7 +13,7 @@ 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. +.The lifecycle of the status of your files image::images/lifecycle.png[The lifecycle of the status of your files.] [[_checking_status]] diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc index 467a6102b..d69714f8b 100644 --- a/book/03-git-branching/sections/rebasing.asc +++ b/book/03-git-branching/sections/rebasing.asc @@ -198,7 +198,7 @@ For instance, in the previous scenario, if instead of doing a merge when we're a So instead of the result we see in <<_merge_rebase_work>>, we would end up with something more like <<_rebase_rebase_work>>. [[_rebase_rebase_work]] -.Rebase on top of force-pushed 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.] This only works if `C4` and `C4'` that your partner made are almost exactly the same patch. diff --git a/book/04-git-server/sections/gitlab.asc b/book/04-git-server/sections/gitlab.asc index a17d0e5d0..4b1696374 100644 --- a/book/04-git-server/sections/gitlab.asc +++ b/book/04-git-server/sections/gitlab.asc @@ -16,7 +16,7 @@ To get something up and running quickly, you can download a virtual machine imag One nice touch Bitnami has included is the login screen (accessed by typing alt+→); it tells you the IP address and default username and password for the installed GitLab. [[bitnami]] -.The Bitnami GitLab virtual machine login screen. +.The Bitnami GitLab virtual machine login screen image::images/bitnami.png[The Bitnami GitLab virtual machine login screen.] For anything else, follow the guidance in the GitLab Community Edition readme, which can be found at https://gitlab.com/gitlab-org/gitlab-ce/tree/master[]. @@ -31,7 +31,7 @@ The default username is `admin@local.host`, and the default password is `5iveL!f Once logged in, click the ``Admin area'' icon in the menu at the top right. [[gitlab_menu]] -.The ``Admin area'' item in the GitLab menu. +.The ``Admin area'' item in the GitLab menu image::images/gitlab-menu.png[The ``Admin area'' item in the GitLab menu.] ===== Users @@ -42,7 +42,7 @@ Each user account comes with a *namespace*, which is a logical grouping of proje If the user +jane+ had a project named +project+, that project's url would be `http://server/jane/project`. [[gitlab_users]] -.The GitLab user administration screen. +.The GitLab user administration screen image::images/gitlab-users.png[The GitLab user administration screen.] Removing a user can be done in two ways. @@ -59,7 +59,7 @@ A GitLab group is an assemblage of projects, along with data about how users can Each group has a project namespace (the same way that users do), so if the group +training+ has a project +materials+, its url would be `http://server/training/materials`. [[gitlab_groups]] -.The GitLab group administration screen. +.The GitLab group administration screen image::images/gitlab-groups.png[The GitLab group administration screen.] Each group is associated with a number of users, each of which has a level of permissions for the group's projects and the group itself. diff --git a/book/04-git-server/sections/gitweb.asc b/book/04-git-server/sections/gitweb.asc index b0c4572df..508858324 100644 --- a/book/04-git-server/sections/gitweb.asc +++ b/book/04-git-server/sections/gitweb.asc @@ -5,7 +5,7 @@ Now that you have basic read/write and read-only access to your project, you may Git comes with a CGI script called GitWeb that is sometimes used for this. [[gitweb]] -.The GitWeb web-based user interface. +.The GitWeb web-based user interface image::images/git-instaweb.png[The GitWeb web-based user interface.] If you want to check out what GitWeb would look like for your project, Git comes with a command to fire up a temporary instance if you have a lightweight web server on your system like `lighttpd` or `webrick`. diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index c09bfaeb2..34fac8c18 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -41,7 +41,7 @@ The Git project provides a document that lays out a number of good tips for crea First, your submissions should not contain any whitespace errors. Git provides an easy way to check for this -- before you commit, run `git diff --check`, which identifies possible whitespace errors and lists them for you. -.Output of `git diff --check`. +.Output of `git diff --check` image::images/git-diff-check.png[Output of `git diff --check`.] If you run that command before committing, you can tell if you're about to commit whitespace issues that may annoy other developers. @@ -184,7 +184,7 @@ From john@githost:simplegit At this point, John's local repository looks something like this: -.John's divergent history. +.John's divergent history image::images/small-team-1.png[John's divergent history.] Now John can merge Jessica's work that he fetched into his own local work: @@ -199,7 +199,7 @@ Merge made by the 'recursive' strategy. As long as that local merge goes smoothly, John's updated history will now look like this: -.John's repository after merging `origin/master`. +.John's repository after merging `origin/master` image::images/small-team-2.png[John's repository after merging `origin/master`.] At this point, John might want to test this new code to make sure none of Jessica's work affects any of his and, as long as everything seems fine, he can finally push the new merged work up to the server: @@ -214,13 +214,13 @@ To john@githost:simplegit.git In the end, John's commit history will look like this: -.John's history after pushing to the `origin` server. +.John's history after pushing to the `origin` server image::images/small-team-3.png[John's history after pushing to the `origin` server.] In the meantime, Jessica has created a new topic branch called `issue54`, and made three commits to that branch. She hasn't fetched John's changes yet, so her commit history looks like this: -.Jessica's topic branch. +.Jessica's topic branch image::images/small-team-4.png[Jessica's topic branch.] Suddenly, Jessica learns that John has pushed some new work to the server and she wants to take a look at it, so she can fetch all new content from the server that she does not yet have with: @@ -237,7 +237,7 @@ From jessica@githost:simplegit That pulls down the work John has pushed up in the meantime. Jessica's history now looks like this: -.Jessica's history after fetching John's changes. +.Jessica's history after fetching John's changes image::images/small-team-5.png[Jessica's history after fetching John's changes.] Jessica thinks her topic branch is ready, but she wants to know what part of John's fetched work she has to merge into her work so that she can push. @@ -298,7 +298,7 @@ Merge made by the 'recursive' strategy. Everything merges cleanly, and Jessica's history now looks like this: -.Jessica's history after merging John's changes. +.Jessica's history after merging John's changes image::images/small-team-6.png[Jessica's history after merging John's changes.] Now `origin/master` is reachable from Jessica's `master` branch, so she should be able to successfully push (assuming John hasn't pushed even more changes in the meantime): @@ -313,7 +313,7 @@ To jessica@githost:simplegit.git Each developer has committed a few times and merged each other's work successfully. -.Jessica's history after pushing all changes back to the server. +.Jessica's history after pushing all changes back to the server image::images/small-team-7.png[Jessica's history after pushing all changes back to the server.] That is one of the simplest workflows. @@ -321,7 +321,7 @@ You work for a while (generally in a topic branch), and merge that work into you When you want to share that work, you fetch and merge your `master` from `origin/master` if it has changed, and finally push to the `master` branch on the server. The general sequence is something like this: -.General sequence of events for a simple multiple-developer Git workflow. +.General sequence of events for a simple multiple-developer Git workflow image::images/small-team-flow.png[General sequence of events for a simple multiple-developer Git workflow.] ==== Private Managed Team @@ -388,7 +388,7 @@ $ git commit -am 'Add ls-files' Jessica's repository now looks like this: -.Jessica's initial commit history. +.Jessica's initial commit history image::images/managed-team-1.png[Jessica's initial commit history.] She's ready to push her work, but gets an email from Josie that a branch with some initial ``featureB'' work on it was already pushed to the server as the `featureBee` branch. @@ -480,20 +480,20 @@ To jessica@githost:simplegit.git Jessica's commit history now looks something like this: -.Jessica's history after committing on a feature branch. +.Jessica's history after committing on a feature branch image::images/managed-team-2.png[Jessica's history after committing on a feature branch.] At some point, Jessica, Josie, and John inform the integrators that the `featureA` and `featureBee` branches on the server are ready for integration into the mainline. After the integrators merge these branches into the mainline, a fetch will bring down the new merge commit, making the history look like this: -.Jessica's history after merging both her topic branches. +.Jessica's history after merging both her topic branches image::images/managed-team-3.png[Jessica's history after merging both her topic branches.] Many groups switch to Git because of this ability to have multiple teams working in parallel, merging the different lines of work late in the process. The ability of smaller subgroups of a team to collaborate via remote branches without necessarily having to involve or impede the entire team is a huge benefit of Git. The sequence for the workflow you saw here is something like this: -.Basic sequence of this managed-team workflow. +.Basic sequence of this managed-team workflow image::images/managed-team-flow.png[Basic sequence of this managed-team workflow.] [[_public_project]] @@ -590,7 +590,7 @@ $ git fetch origin Now, each of your topics is contained within a silo -- similar to a patch queue -- that you can rewrite, rebase, and modify without the topics interfering or interdepending on each other, like so: -.Initial commit history with `featureB` work. +.Initial commit history with `featureB` work image::images/public-small-1.png[Initial commit history with `featureB` work.] Let's say the project maintainer has pulled in a bunch of other patches and tried your first branch, but it no longer cleanly merges. @@ -606,7 +606,7 @@ $ git push -f myfork featureA This rewrites your history to now look like <>. [[psp_b]] -.Commit history after `featureA` work. +.Commit history after `featureA` work image::images/public-small-2.png[Commit history after `featureA` work.] Because you rebased the branch, you have to specify the `-f` to your push command in order to be able to replace the `featureA` branch on the server with a commit that isn't a descendant of it. @@ -632,7 +632,7 @@ Also the `--no-commit` option can be useful to delay the merge commit in case of At this point, you can notify the maintainer that you've made the requested changes, and that they can find those changes in your `featureBv2` branch. -.Commit history after `featureBv2` work. +.Commit history after `featureBv2` work image::images/public-small-3.png[Commit history after `featureBv2` work.] [[_project_over_email]] diff --git a/book/05-distributed-git/sections/distributed-workflows.asc b/book/05-distributed-git/sections/distributed-workflows.asc index 769c28e51..e07b6e7b9 100644 --- a/book/05-distributed-git/sections/distributed-workflows.asc +++ b/book/05-distributed-git/sections/distributed-workflows.asc @@ -14,7 +14,7 @@ In centralized systems, there is generally a single collaboration model -- the c One central hub, or _repository_, can accept code, and everyone synchronizes their work with it. A number of developers are nodes -- consumers of that hub -- and synchronize with that centralized location. -.Centralized workflow. +.Centralized workflow image::images/centralized_workflow.png[Centralized workflow.] This means that if two developers clone from the hub and both make changes, the first developer to push their changes back up can do so with no problems. @@ -52,7 +52,7 @@ The process works as follows (see <>): 6. The maintainer pushes merged changes to the main repository. [[wfdiag_b]] -.Integration-manager workflow. +.Integration-manager workflow image::images/integration-manager.png[Integration-manager workflow.] (((forking))) @@ -77,7 +77,7 @@ The process works like this (see <>): 4. Finally, the dictator pushes that `master` branch to the reference repository so the other developers can rebase on it. [[wfdiag_c]] -.Benevolent dictator workflow. +.Benevolent dictator workflow image::images/benevolent-dictator.png[Benevolent dictator workflow.] This kind of workflow isn't common, but can be useful in very big projects, or in highly hierarchical environments. diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index df1b879a6..1eb061bfd 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -310,11 +310,11 @@ When you have work in a topic branch that you think you've completed, or work th For instance, if we have a repository with work in two branches named `ruby_client` and `php_client` that looks like <>, and we merge `ruby_client` followed by `php_client`, your history will end up looking like <>. [[merwf_a]] -.History with several topic branches. +.History with several topic branches image::images/merging-workflows-1.png[History with several topic branches.] [[merwf_b]] -.After a topic branch merge. +.After a topic branch merge image::images/merging-workflows-2.png[After a topic branch merge.] That is probably the simplest workflow, but it can possibly be problematic if you're dealing with larger or more stable projects where you want to be really careful about what you introduce. @@ -325,15 +325,15 @@ You regularly push both of these branches to the public repository. Each time you have a new topic branch to merge in (<>), you merge it into `develop` (<>); then, when you tag a release, you fast-forward `master` to wherever the now-stable `develop` branch is (<>). [[merwf_c]] -.Before a topic branch merge. +.Before a topic branch merge image::images/merging-workflows-3.png[Before a topic branch merge.] [[merwf_d]] -.After a topic branch merge. +.After a topic branch merge image::images/merging-workflows-4.png[After a topic branch merge.] [[merwf_e]] -.After a project release. +.After a project release image::images/merging-workflows-5.png[After a topic branch 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. @@ -349,7 +349,7 @@ At this point, the topics are evaluated to determine whether they're safe and re If they're safe, they're merged into `next`, and that branch is pushed up so everyone can try the topics integrated together. [[merwf_f]] -.Managing a complex series of parallel contributed topic branches. +.Managing a complex series of parallel contributed topic branches image::images/large-merges-1.png[Managing a complex series of parallel contributed topic branches.] If the topics still need work, they're merged into `pu` instead. @@ -357,7 +357,7 @@ When it's determined that they're totally stable, the topics are re-merged into The `next` and `pu` branches are then rebuilt from the `master`. This means `master` almost always moves forward, `next` is rebased occasionally, and `pu` is rebased even more often: -.Merging contributed topic branches into long-term integration branches. +.Merging contributed topic branches into long-term integration branches image::images/large-merges-2.png[Merging contributed topic branches into long-term integration branches.] When a topic branch has finally been merged into `master`, it's removed from the repository. @@ -381,7 +381,7 @@ It takes the patch that was introduced in a commit and tries to reapply it on th This is useful if you have a number of commits on a topic branch and you want to integrate only one of them, or if you only have one commit on a topic branch and you'd prefer to cherry-pick it rather than run rebase. For example, suppose you have a project that looks like this: -.Example history before a cherry-pick. +.Example history before a cherry-pick image::images/rebasing-1.png[Example history before a cherry-pick.] If you want to pull commit `e43a6` into your `master` branch, you can run @@ -397,7 +397,7 @@ Finished one cherry-pick. This pulls the same change introduced in `e43a6`, but you get a new commit SHA-1 value, because the date applied is different. Now your history looks like this: -.History after cherry-picking a commit on a topic branch. +.History after cherry-picking a commit on a topic branch image::images/rebasing-2.png[History after cherry-picking a commit on a topic branch.] Now you can remove your topic branch and drop the commits you didn't want to pull in. diff --git a/book/06-github/sections/1-setting-up-account.asc b/book/06-github/sections/1-setting-up-account.asc index 76630eccb..da092eb33 100644 --- a/book/06-github/sections/1-setting-up-account.asc +++ b/book/06-github/sections/1-setting-up-account.asc @@ -4,7 +4,7 @@ The first thing you need to do is set up a free user account. Simply visit https://github.com[], choose a user name that isn't already taken, provide an email address and a password, and click the big green ``Sign up for GitHub'' button. -.The GitHub sign-up form. +.The GitHub sign-up form image::images/signup.png[The GitHub sign-up form.] The next thing you'll see is the pricing page for upgraded plans, but it's safe to ignore this for now. @@ -32,12 +32,12 @@ If you'd like to use SSH remotes, you'll need to configure a public key. (If you don't already have one, see <>.) Open up your account settings using the link at the top-right of the window: -.The ``Account settings'' link. +.The ``Account settings'' link 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''. @@ -54,7 +54,7 @@ You can name each of your keys (e.g. "My Laptop" or "Work Account") so that if y Next, if you wish, you can replace the avatar that is generated for you with an image of your choosing. First go to the ``Profile'' tab (above the SSH Keys tab) and click ``Upload new picture''. -.The ``Profile'' link. +.The ``Profile'' link 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. diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index e5bbb9d79..0ff2620d7 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -20,7 +20,7 @@ This opens up a discussion thread with code review, and the owner and the contri To fork a project, visit the project page and click the ``Fork'' button at the top-right of the page. -.The ``Fork'' button. +.The ``Fork'' button image::images/forkbutton.png[The ``Fork'' button.] After a few seconds, you'll be taken to your new project page, with your own writeable copy of the code. @@ -53,7 +53,7 @@ Let's walk through an example of proposing a change to an open source project ho Tony is looking for code to run on his Arduino programmable microcontroller and has found a great program file on GitHub at https://github.com/schacon/blink[]. -.The project we want to contribute to. +.The project we want to contribute to image::images/blink-01-start.png[The project we want to contribute to.] The only problem is that the blinking rate is too fast. @@ -306,13 +306,13 @@ We also want to reference an issue in the fork of the repository and an issue in We can fill out the description just like <<_pr_references>>. [[_pr_references]] -.Cross references in a Pull Request. +.Cross references in a Pull Request image::images/mentions-01-syntax.png[PR references] 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. +.Cross references rendered in a Pull Request image::images/mentions-02-render.png[PR references rendered] Notice that the full GitHub URL we put in there was shortened to just the information needed. @@ -322,7 +322,7 @@ This means that anyone who visits this Pull Request and sees that it is closed c The link will look something like <<_pr_closed>>. [[_pr_closed]] -.Link back to the new Pull Request in the closed Pull Request timeline. +.Link back to the new Pull Request in the closed Pull Request timeline image::images/mentions-03-closed.png[PR closed] In addition to issue numbers, you can also reference a specific commit by SHA-1. @@ -338,7 +338,7 @@ Markdown is like writing in plain text but which is rendered richly. See <<_example_markdown>> for an example of how comments or text can be written and then rendered using Markdown. [[_example_markdown]] -.An example of GitHub Flavored Markdown as written and as rendered. +.An example of GitHub Flavored Markdown as written and as rendered image::images/markdown-01-example.png[Example Markdown] The GitHub flavor of Markdown adds more things you can do beyond the basic Markdown syntax. @@ -362,7 +362,7 @@ You can create a task list like this: If we include this in the description of our Pull Request or Issue, we'll see it rendered like <<_eg_task_lists>> [[_eg_task_lists]] -.Task lists rendered in a Markdown comment. +.Task lists rendered in a Markdown comment image::images/markdown-02-tasks.png[Example Task List] 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. @@ -374,7 +374,7 @@ This helps people break down Pull Requests into subtasks and helps other people You can see an example of this in <<_task_list_progress>>. [[_task_list_progress]] -.Task list summary in the Pull Request list. +.Task list summary in the Pull Request list image::images/markdown-03-task-summary.png[Example Task 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. @@ -401,7 +401,7 @@ If you add a language name like we did there with 'java', GitHub will also try t In the case of the above example, it would end up rendering like <<_md_code>>. [[_md_code]] -.Rendered fenced code example. +.Rendered fenced code example image::images/markdown-04-fenced-code.png[Rendered fenced code] ===== Quoting @@ -423,7 +423,7 @@ How big are these slings and in particular, these arrows? Once rendered, the comment will look like <<_md_quote>>. [[_md_quote]] -.Rendered quoting example. +.Rendered quoting example image::images/markdown-05-quote.png[Rendered quoting] ===== Emoji @@ -434,7 +434,7 @@ There is even an emoji helper in GitHub. If you are typing a comment and you start with a `:` character, an autocompleter will help you find what you're looking for. [[_md_emoji_auto]] -.Emoji autocompleter in action. +.Emoji autocompleter in action image::images/markdown-06-emoji-complete.png[Emoji autocompleter] Emojis take the form of `::` anywhere in the comment. @@ -454,7 +454,7 @@ I :eyes: that :bug: and I :cold_sweat:. When rendered, it would look something like <<_md_emoji>>. [[_md_emoji]] -.Heavy emoji commenting. +.Heavy emoji commenting image::images/markdown-07-emoji.png[Emoji] 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. @@ -474,7 +474,7 @@ This isn't technically GitHub Flavored Markdown, but it is incredibly useful. In addition to adding Markdown image links to comments, which can be difficult to find and embed URLs for, GitHub allows you to drag and drop images into text areas to embed them. [[_md_drag]] -.Drag and drop images to upload them and auto-embed them. +.Drag and drop images to upload them and auto-embed them image::images/markdown-08-drag-drop.png[Drag and drop images] If you look at <<_md_drag>>, you can see a small ``Parsed as Markdown'' hint above the text area. diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index f174e15e9..66de8b5c7 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -8,16 +8,16 @@ Now that we're comfortable contributing to a project, let's look at the other si Let's create a new repository to share our project code with. Start by clicking the ``New repository'' button on the right-hand side of the dashboard, or from the `+` button in the top toolbar next to your username as seen in <<_new_repo_dropdown>>. -.The ``Your repositories'' area. +.The ``Your repositories'' area image::images/newrepo.png[The ``Your repositories'' area.] [[_new_repo_dropdown]] -.The ``New repository'' dropdown. +.The ``New repository'' dropdown image::images/new-repo.png[The ``new repository'' dropdown.] This takes you to the ``new repository'' form: -.The ``new repository'' form. +.The ``new repository'' form image::images/newrepoform.png[The ``new repository'' form.] All you really have to do here is provide a project name; the rest of the fields are completely optional. @@ -45,7 +45,7 @@ Doing so will give them ``push'' access, which means they have both read and wri Click the ``Settings'' link at the bottom of the right-hand sidebar. -.The repository settings link. +.The repository settings link image::images/reposettingslink.png[The repository settings link.] Then select ``Collaborators'' from the menu on the left-hand side. @@ -53,7 +53,7 @@ Then, just type a username into the box, and click ``Add collaborator.'' You can repeat this as many times as you like to grant access to everyone you like. If you need to revoke access, just click the ``X'' on the right-hand side of their row. -.Repository collaborators. +.Repository collaborators image::images/collaborators.png[The repository collaborators box.] ==== Managing Pull Requests @@ -72,7 +72,7 @@ Someone comes along and makes a change to your code and sends you a Pull Request You should get an email notifying you about the new Pull Request and it should look something like <<_email_pr>>. [[_email_pr]] -.Email notification of a new Pull Request. +.Email notification of a new Pull Request image::images/maint-01-email.png[Pull Request email notification] There are a few things to notice about this email. @@ -100,7 +100,7 @@ You can comment on specific lines of code, comment on whole commits or comment o Every time someone else comments on the Pull Request you will continue to get email notifications so you know there is activity happening. They will each have a link to the Pull Request where the activity is happening and you can also directly respond to the email to comment on the Pull Request thread. -.Responses to emails are included in the thread. +.Responses to emails are included in the thread image::images/maint-03-email-resp.png[Email response] Once the code is in a place you like and want to merge it in, you can either pull the code down and merge it locally, either with the `git pull ` syntax we saw earlier, or by adding the fork as a remote and fetching and merging. @@ -111,7 +111,7 @@ This means that no matter what, every time you hit the merge button, a merge com As you can see in <<_merge_button>>, GitHub gives you all of this information if you click the hint link. [[_merge_button]] -.Merge button and instructions for merging a Pull Request manually. +.Merge button and instructions for merging a Pull Request manually image::images/maint-02-merge.png[Merge button] If you decide you don't want to merge it, you can also just close the Pull Request and the person who opened it will be notified. @@ -230,7 +230,7 @@ When you go to open a Pull Request, there is a box at the top of the page that s If you hit the ``Edit'' button at the right of that box you can change not only the branches but also which fork. [[_pr_targets]] -.Manually change the Pull Request target fork and branch. +.Manually change the Pull Request target fork and branch image::images/maint-04-target.png[PR targets] Here you can fairly easily specify to merge your new branch into another Pull Request or another fork of the project. @@ -241,7 +241,7 @@ GitHub also has a pretty nice notifications system built in that can come in han In any comment you can start typing a `@` character and it will begin to autocomplete with the names and usernames of people who are collaborators or contributors in the project. -.Start typing @ to mention someone. +.Start typing @ to mention someone image::images/maint-05-mentions.png[Mentions] You can also mention a user who is not in that dropdown, but often the autocompleter can make it faster. @@ -254,7 +254,7 @@ If someone gets mentioned on a Pull Request or Issue, they will be ``subscribed' You will also be subscribed to something if you opened it, if you're watching the repository or if you comment on something. If you no longer wish to receive notifications, there is an ``Unsubscribe'' button on the page you can click to stop receiving updates on it. -.Unsubscribe from an Issue or Pull Request. +.Unsubscribe from an Issue or Pull Request image::images/maint-06-unsubscribe.png[Unsubscribe] ===== The Notifications Page @@ -262,7 +262,7 @@ image::images/maint-06-unsubscribe.png[Unsubscribe] When we mention ``notifications'' here with respect to GitHub, we mean a specific way that GitHub tries to get in touch with you when events happen and there are a few different ways you can configure them. If you go to the ``Notification center'' tab from the settings page, you can see some of the options you have. -.Notification center options. +.Notification center options image::images/maint-07-notifications.png[Notification center] The two choices are to get notifications over ``Email'' and over ``Web'' and you can choose either, neither or both for when you actively participate in things and for activity on repositories you are watching. @@ -273,7 +273,7 @@ Web notifications only exist on GitHub and you can only check them on GitHub. If you have this option selected in your preferences and a notification is triggered for you, you will see a small blue dot over your notifications icon at the top of your screen as seen in <<_not_center>>. [[_not_center]] -.Notification center. +.Notification center image::images/maint-08-notifications-page.png[Notification center] If you click on that, you will see a list of all the items you have been notified about, grouped by project. @@ -344,7 +344,7 @@ The other special file that GitHub recognizes is the `CONTRIBUTING` file. If you have a file named `CONTRIBUTING` with any file extension, GitHub will show <<_contrib_file>> when anyone starts opening a Pull Request. [[_contrib_file]] -.Opening a Pull Request when a CONTRIBUTING file exists. +.Opening a Pull Request when a CONTRIBUTING file exists image::images/maint-09-contrib.png[Contributing notice] The idea here is that you can specify specific things you want or don't want in a Pull Request sent to your project. @@ -359,7 +359,7 @@ Generally there are not a lot of administrative things you can do with a single If you are using a branch other than ``master'' as your default branch that you want people to open Pull Requests on or see by default, you can change that in your repository's settings page under the ``Options'' tab. [[_default_branch]] -.Change the default branch for a project. +.Change the default branch for a project image::images/maint-10-default-branch.png[Default branch] Simply change the default branch in the dropdown and that will be the default for all major operations from then on, including which branch is checked out by default when someone clones the repository. @@ -369,7 +369,7 @@ Simply change the default branch in the dropdown and that will be the default fo If you would like to transfer a project to another user or an organization in GitHub, there is a ``Transfer ownership'' option at the bottom of the same ``Options'' tab of your repository settings page that allows you to do this. [[_transfer_project]] -.Transfer a project to another GitHub user or Organization. +.Transfer a project to another GitHub user or Organization image::images/maint-11-transfer.png[Transfer] This is helpful if you are abandoning a project and someone wants to take it over, or if your project is getting bigger and want to move it into an organization. diff --git a/book/06-github/sections/4-managing-organization.asc b/book/06-github/sections/4-managing-organization.asc index f3137e5dc..42f1f1f72 100644 --- a/book/06-github/sections/4-managing-organization.asc +++ b/book/06-github/sections/4-managing-organization.asc @@ -11,7 +11,7 @@ Normally these accounts are used for Open Source groups (such as ``perl'' or ``r An organization is pretty easy to create; just click on the ``+'' icon at the top-right of any GitHub page, and select ``New organization'' from the menu. -.The ``New organization'' menu item. +.The ``New organization'' menu item image::images/neworg.png[The ``New organization'' menu item.] First you'll need to name your organization and provide an email address for a main point of contact for the group. @@ -40,7 +40,7 @@ Teams make this easy, without having to manage the collaborators for every indiv The Organization page shows you a simple dashboard of all the repositories, users and teams that are under this organization. [[_org_page]] -.The Organization page. +.The Organization page image::images/orgs-01-page.png[] To manage your Teams, you can click on the Teams sidebar on the right hand side of the page in <<_org_page>>. @@ -49,7 +49,7 @@ Each team can have read only, read/write or administrative access to the reposit You can change that level by clicking the ``Settings'' button in <<_team_page>>. [[_team_page]] -.The Team page. +.The Team page image::images/orgs-02-teams.png[] When you invite someone to a team, they will get an email letting them know they've been invited. @@ -66,7 +66,7 @@ Organizations also give owners access to all the information about what went on You can go to the 'Audit Log' tab and see what events have happened at an organization level, who did them and where in the world they were done. [[_the_audit_log]] -.The Audit log. +.The Audit log image::images/orgs-03-audit.png[] You can also filter down to specific types of events, specific places or specific people. diff --git a/book/06-github/sections/5-scripting.asc b/book/06-github/sections/5-scripting.asc index b85917d73..f27383bf5 100644 --- a/book/06-github/sections/5-scripting.asc +++ b/book/06-github/sections/5-scripting.asc @@ -16,7 +16,7 @@ Both the Hooks and Services integrations can be found in the Settings section of Under the ``Webhooks and Services'' tab you will see something like <<_services_hooks>>. [[_services_hooks]] -.Services and Hooks configuration section. +.Services and Hooks configuration section image::images/scripting-01-services.png[Services and hooks] There are dozens of services you can choose from, most of them integrations into other commercial and open source systems. @@ -25,7 +25,7 @@ We'll walk through setting up a very simple one, the Email hook. If you choose ``email'' from the ``Add Service'' dropdown, you'll get a configuration screen like <<_service_config>>. [[_service_config]] -.Email service configuration. +.Email service configuration image::images/scripting-02-email-service.png[Email service] In this case, if we hit the ``Add service'' button, the email address we specified will get an email every time someone pushes to the repository. @@ -46,7 +46,7 @@ To enable a hook, you click the ``Add webhook'' button in <<_services_hooks>>. This will bring you to a page that looks like <<_web_hook>>. [[_web_hook]] -.Web hook configuration. +.Web hook configuration image::images/scripting-03-webhook.png[Web hook] The configuration for a web hook is pretty simple. @@ -102,7 +102,7 @@ For each hook you can dig down into when it was delivered, if it was successful This makes it incredibly easy to test and debug your hooks. [[_web_hook_debug]] -.Web hook debugging information. +.Web hook debugging information image::images/scripting-04-webhook-debug.png[Webhook debug] The other great feature of this is that you can redeliver any of the payloads to test your service easily. @@ -175,7 +175,7 @@ You can use basic authentication with just your username and password, but gener You can generate this from the ``Applications'' tab of your settings page. [[_access_token]] -.Generate your access token from the ``Applications'' tab of your settings page. +.Generate your access token from the ``Applications'' tab of your settings page image::images/scripting-05-access-token.png[Access Token] It will ask you which scopes you want for this token and a description. @@ -218,7 +218,7 @@ $ curl -H "Content-Type: application/json" \ Now if you go to that issue, you can see the comment that we just successfully posted as in <<_api_comment>>. [[_api_comment]] -.A comment posted from the GitHub API. +.A comment posted from the GitHub API image::images/scripting-06-comment.png[API Comment] You can use the API to do just about anything you can do on the website -- creating and setting milestones, assigning people to Issues and Pull Requests, creating and changing labels, accessing commit data, creating new commits and branches, opening, closing or merging Pull Requests, creating and editing teams, commenting on lines of code in a Pull Request, searching the site and on and on. @@ -285,7 +285,7 @@ For example, a testing service may provide a status and a validation service lik If someone opens a new Pull Request on GitHub and this hook is set up, you may see something like <<_commit_status>>. [[_commit_status]] -.Commit status via the API. +.Commit status via the API image::images/scripting-07-status.png[Commit status] You can now see a little green check mark next to the commit that has a ``Signed-off-by'' string in the message and a red cross through the one where the author forgot to sign off. diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc index b17972dd1..79fccfea1 100644 --- a/book/07-git-tools/sections/revision-selection.asc +++ b/book/07-git-tools/sections/revision-selection.asc @@ -291,7 +291,7 @@ This basically asks Git to resolve a range of commits that are reachable from on For example, say you have a commit history that looks like <>. [[double_dot]] -.Example history for range selection. +.Example history for range selection image::images/double-dot.png[Example history for range selection.] Say you want to see what is in your `experiment` branch that hasn't yet been merged into your `master` branch. diff --git a/book/08-customizing-git/sections/attributes.asc b/book/08-customizing-git/sections/attributes.asc index 965cbbed5..6863c82f9 100644 --- a/book/08-customizing-git/sections/attributes.asc +++ b/book/08-customizing-git/sections/attributes.asc @@ -197,11 +197,11 @@ In the `.gitattributes` file, you can set a filter for particular paths and then These filters can be set to do all sorts of fun things. [[filters_a]] -.The ``smudge'' filter is run on checkout. +.The ``smudge'' filter is run on checkout image::images/smudge.png[The ``smudge'' filter is run on checkout.] [[filters_b]] -.The ``clean'' filter is run when files are staged. +.The ``clean'' filter is run when files are staged image::images/clean.png[The ``clean'' filter is run when files are staged.] The original commit message for this feature gives a simple example of running all your C source code through the `indent` program before committing. diff --git a/book/08-customizing-git/sections/config.asc b/book/08-customizing-git/sections/config.asc index 435366bf3..e4277734e 100644 --- a/book/08-customizing-git/sections/config.asc +++ b/book/08-customizing-git/sections/config.asc @@ -319,7 +319,7 @@ $ git diff 32d1776b1^ 32d1776b1 Instead of getting the diff output on the command line, Git fires up P4Merge, which looks something like this: -.P4Merge. +.P4Merge image::images/p4merge.png[P4Merge.] If you try to merge two branches and subsequently have merge conflicts, you can run the command `git mergetool`; it starts P4Merge to let you resolve the conflicts through that GUI tool. diff --git a/book/09-git-and-other-scms/sections/client-p4.asc b/book/09-git-and-other-scms/sections/client-p4.asc index 311aa0777..e6950fbda 100644 --- a/book/09-git-and-other-scms/sections/client-p4.asc +++ b/book/09-git-and-other-scms/sections/client-p4.asc @@ -25,7 +25,7 @@ You can get the virtual machine image from http://www.perforce.com/downloads/Per Upon first starting the machine, it asks you to customize the password for three Linux users (`root`, `perforce`, and `git`), and provide an instance name, which can be used to distinguish this installation from others on the same network. When that has all completed, you'll see this: -.The Git Fusion virtual machine boot screen. +.The Git Fusion virtual machine boot screen image::images/git-fusion-boot.png[The Git Fusion virtual machine boot screen.] You should take note of the IP address that's shown here, we'll be using it later on. @@ -288,7 +288,7 @@ To https://10.0.1.254/Jam Git thinks it worked. Let's take a look at the history of the `README` file from Perforce's point of view, using the revision graph feature of `p4v`: -.Perforce revision graph resulting from Git push. +.Perforce revision graph resulting from Git push image::images/git-fusion-perforce-graph.png[Perforce revision graph resulting from Git push.] If you've never seen this view before, it may seem confusing, but it shows the same concepts as a graphical viewer for Git history. diff --git a/book/09-git-and-other-scms/sections/client-tfs.asc b/book/09-git-and-other-scms/sections/client-tfs.asc index 2a2161514..fc697f325 100644 --- a/book/09-git-and-other-scms/sections/client-tfs.asc +++ b/book/09-git-and-other-scms/sections/client-tfs.asc @@ -379,7 +379,7 @@ PS> git tfs ct It looks a bit like this: -.The git-tfs checkin tool. +.The git-tfs checkin tool image::images/git-tfs-ct.png[The git-tfs checkin tool.] This will look familiar to TFS users, as it's the same dialog that's launched from within Visual Studio. diff --git a/book/10-git-internals/sections/objects.asc b/book/10-git-internals/sections/objects.asc index 8f793311c..e5be083e0 100644 --- a/book/10-git-internals/sections/objects.asc +++ b/book/10-git-internals/sections/objects.asc @@ -157,7 +157,7 @@ If you're using ZSH, the `^` character is used for globbing, so you have to encl Conceptually, the data that Git is storing looks something like this: -.Simple version of the Git data model. +.Simple version of the Git data model image::images/data-model-1.png[Simple version of the Git data model.] You can fairly easily create your own tree. @@ -238,7 +238,7 @@ $ git cat-file -p 3c4e9cd789d88d8d89c1073707c3585e41b0e614 If you created a working directory from the new tree you just wrote, you would get the two files in the top level of the working directory and a subdirectory named `bak` that contained the first version of the `test.txt` file. You can think of the data that Git contains for these structures as being like this: -.The content structure of your current Git data. +.The content structure of your current Git data image::images/data-model-2.png[The content structure of your current Git data.] [[_git_commit_objects]] @@ -347,7 +347,7 @@ $ find .git/objects -type f If you follow all the internal pointers, you get an object graph something like this: -.All the reachable objects in your Git directory. +.All the reachable objects in your Git directory image::images/data-model-3.png[All the reachable objects in your Git directory.] ==== Object Storage diff --git a/book/10-git-internals/sections/refs.asc b/book/10-git-internals/sections/refs.asc index bf22756dc..39f0faf29 100644 --- a/book/10-git-internals/sections/refs.asc +++ b/book/10-git-internals/sections/refs.asc @@ -59,7 +59,7 @@ fdf4fc3344e67ab068f836878b6c4951e3b15f3d First commit Now, your Git database conceptually looks something like this: -.Git directory objects with branch head references included. +.Git directory objects with branch head references included image::images/data-model-4.png[Git directory objects with branch head references included.] When you run commands like `git branch `, Git basically runs that `update-ref` command to add the SHA-1 of the last commit of the branch you're on into whatever new reference you want to create. diff --git a/book/A-git-in-other-environments/sections/bash.asc b/book/A-git-in-other-environments/sections/bash.asc index f2002b3e3..a317780c4 100644 --- a/book/A-git-in-other-environments/sections/bash.asc +++ b/book/A-git-in-other-environments/sections/bash.asc @@ -36,7 +36,7 @@ export PS1='\w$(__git_ps1 " (%s)")\$ ' The `\w` means print the current working directory, the `\$` prints the `$` part of the prompt, and `__git_ps1 " (%s)"` calls the function provided by `git-prompt.sh` with a formatting argument. Now your bash prompt will look like this when you're anywhere inside a Git-controlled project: -.Customized `bash` prompt. +.Customized `bash` prompt image::images/git-bash.png[Customized `bash` prompt.] Both of these scripts come with helpful documentation; take a look at the contents of `git-completion.bash` and `git-prompt.sh` for more information. diff --git a/book/A-git-in-other-environments/sections/eclipse.asc b/book/A-git-in-other-environments/sections/eclipse.asc index 76cfd9c5f..2facd117a 100644 --- a/book/A-git-in-other-environments/sections/eclipse.asc +++ b/book/A-git-in-other-environments/sections/eclipse.asc @@ -4,7 +4,7 @@ Eclipse ships with a plugin called Egit, which provides a fairly-complete interface to Git operations. It's accessed by switching to the Git Perspective (Window > Open Perspective > Other…, and select "Git"). -.Eclipse's EGit environment. +.Eclipse's EGit environment image::images/egit.png[Eclipse's EGit environment.] EGit comes with plenty of great documentation, which you can find by going to Help > Help Contents, and choosing the "EGit Documentation" node from the contents listing. diff --git a/book/A-git-in-other-environments/sections/guis.asc b/book/A-git-in-other-environments/sections/guis.asc index 840a74474..b046bd896 100644 --- a/book/A-git-in-other-environments/sections/guis.asc +++ b/book/A-git-in-other-environments/sections/guis.asc @@ -31,7 +31,7 @@ Gitk accepts many command-line options, most of which are passed through to the Probably one of the most useful is the `--all` flag, which tells gitk to show commits reachable from _any_ ref, not just HEAD. Gitk's interface looks like this: -.The `gitk` history viewer. +.The `gitk` history viewer image::images/gitk.png[The `gitk` history viewer.] On the top is something that looks a bit like the output of `git log --graph`; each dot represents a commit, the lines represent parent relationships, and refs are shown as colored boxes. @@ -49,7 +49,7 @@ $ git gui And it looks something like this: -.The `git-gui` commit tool. +.The `git-gui` commit tool image::images/git-gui.png[The `git-gui` commit tool.] On the left is the index; unstaged changes are on top, staged changes on the bottom. @@ -73,10 +73,10 @@ GitHub has created two workflow-oriented Git clients: one for Windows, and one f These clients are a good example of workflow-oriented tools – rather than expose _all_ of Git's functionality, they instead focus on a curated set of commonly-used features that work well together. They look like this: -.GitHub for macOS. +.GitHub for macOS image::images/github_mac.png[GitHub for macOS.] -.GitHub for Windows. +.GitHub for Windows image::images/github_win.png[GitHub for Windows.] They are designed to look and work very much alike, so we'll treat them like a single product in this chapter. @@ -116,12 +116,12 @@ We cover this in more detail in <>, but the genera Branch management is one of the areas where the two tools diverge. On macOS, there's a button at the top of the window for creating a new branch: -.``Create Branch'' button on macOS. +.``Create Branch'' button on macOS image::images/branch_widget_mac.png[``Create Branch'' button on macOS.] On Windows, this is done by typing the new branch's name in the branch-switching widget: -.Creating a branch on Windows. +.Creating a branch on Windows image::images/branch_widget_win.png[Creating a branch on Windows.] Once your branch is created, making new commits is fairly straightforward. diff --git a/book/A-git-in-other-environments/sections/jetbrainsides.asc b/book/A-git-in-other-environments/sections/jetbrainsides.asc index 7ad25833a..529d0754c 100644 --- a/book/A-git-in-other-environments/sections/jetbrainsides.asc +++ b/book/A-git-in-other-environments/sections/jetbrainsides.asc @@ -3,7 +3,7 @@ JetBrains IDEs (such as IntelliJ IDEA, PyCharm, WebStorm, PhpStorm, RubyMine, and others) ship with a Git Integration plugin. It provides a dedicated view in the IDE to work with Git and GitHub Pull Requests. -.Version Control ToolWindow in JetBrains IDEs. +.Version Control ToolWindow in JetBrains IDEs image::images/jb.png[Version Control ToolWindow in JetBrains IDEs.] The integration relies on the command-line git client, and requires one to be installed. diff --git a/book/A-git-in-other-environments/sections/powershell.asc b/book/A-git-in-other-environments/sections/powershell.asc index 41d92a911..67b404ce5 100644 --- a/book/A-git-in-other-environments/sections/powershell.asc +++ b/book/A-git-in-other-environments/sections/powershell.asc @@ -8,7 +8,7 @@ This also works if you're running PowerShell Core on Linux or macOS. A package called posh-git (https://github.com/dahlbyk/posh-git[]) provides powerful tab-completion facilities, as well as an enhanced prompt to help you stay on top of your repository status. It looks like this: -.PowerShell with Posh-git. +.PowerShell with Posh-git image::images/posh-git.png[PowerShell with Posh-git.] ==== Installation diff --git a/book/A-git-in-other-environments/sections/visualstudio.asc b/book/A-git-in-other-environments/sections/visualstudio.asc index 8ab664360..78902660d 100644 --- a/book/A-git-in-other-environments/sections/visualstudio.asc +++ b/book/A-git-in-other-environments/sections/visualstudio.asc @@ -8,7 +8,7 @@ Visual Studio 2013's Git support has been separated from this older feature, and To locate the feature, open a project that's controlled by Git (or just `git init` an existing project), and select View > Team Explorer from the menu. You'll see the "Connect" view, which looks a bit like this: -.Connecting to a Git repository from Team Explorer. +.Connecting to a Git repository from Team Explorer image::images/vs-1.png[Connecting to a Git repository from Team Explorer.] Visual Studio remembers all of the projects you've opened that are Git-controlled, and they're available in the list at the bottom. @@ -17,7 +17,7 @@ Double clicking on one of the local Git repositories leads you to the Home view, This is a hub for performing Git actions; when you're _writing_ code, you'll probably spend most of your time in the "Changes" view, but when it comes time to pull down changes made by your teammates, you'll use the "Unsynced Commits" and "Branches" views. [[vs_home]] -.The "Home" view for a Git repository in Visual Studio. +.The "Home" view for a Git repository in Visual Studio image::images/vs-2.png[The Home view for a Git repository in Visual Studio.] Visual Studio now has a powerful task-focused UI for Git. From b600691c4c5f938baa22befba05c50a95a3d1d95 Mon Sep 17 00:00:00 2001 From: Vipul Kumar Date: Fri, 26 Jun 2020 08:41:58 +0000 Subject: [PATCH 2/9] [Fix] add missing period mark - After removing period mark from figure captions; some paragraph left with no period because those paragraph has only one period and that's because of figure caption (see https://github.com/progit/progit2/pull/1444#issuecomment-648754034). - End all bullet points with a period. --- book/04-git-server/sections/hosted.asc | 2 +- book/06-github/sections/2-contributing.asc | 26 +++++++++---------- book/06-github/sections/5-scripting.asc | 2 +- book/07-git-tools/sections/replace.asc | 2 +- book/07-git-tools/sections/reset.asc | 10 +++---- book/07-git-tools/sections/submodules.asc | 10 +++---- .../sections/client-bzr.asc | 2 +- .../sections/powershell.asc | 8 +++--- .../sections/sublimetext.asc | 2 +- .../sections/visualstudiocode.asc | 4 +-- book/B-embedding-git/sections/dulwich.asc | 4 +-- 11 files changed, 36 insertions(+), 36 deletions(-) diff --git a/book/04-git-server/sections/hosted.asc b/book/04-git-server/sections/hosted.asc index 6828f64e5..c3ca6bc19 100644 --- a/book/04-git-server/sections/hosted.asc +++ b/book/04-git-server/sections/hosted.asc @@ -5,6 +5,6 @@ Doing so offers a number of advantages: a hosting site is generally quick to set Even if you set up and run your own server internally, you may still want to use a public hosting site for your open source code – it's generally easier for the open source community to find and help you with. These days, you have a huge number of hosting options to choose from, each with different advantages and disadvantages. -To see an up-to-date list, check out the GitHosting page on the main Git wiki at https://git.wiki.kernel.org/index.php/GitHosting[] +To see an up-to-date list, check out the GitHosting page on the main Git wiki at https://git.wiki.kernel.org/index.php/GitHosting[]. We'll cover using GitHub in detail in <>, as it is the largest Git host out there and you may need to interact with projects hosted on it in any case, but there are dozens more to choose from should you not want to set up your own Git server. diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index 0ff2620d7..ef3c95861 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -36,7 +36,7 @@ It is centered on the <> workflow covered in < Here's how it generally works: -1. Fork the project +1. Fork the project. 2. Create a topic branch from `master`. 3. Make some commits to improve the project. 4. Push this branch to your GitHub project. @@ -107,12 +107,12 @@ To https://github.com/tonychacon/blink * [new branch] slow-blink -> slow-blink ---- -<1> Clone our fork of the project locally -<2> Create a descriptive topic branch -<3> Make our change to the code -<4> Check that the change is good -<5> Commit our change to the topic branch -<6> Push our new topic branch back up to our GitHub fork +<1> Clone our fork of the project locally. +<2> Create a descriptive topic branch. +<3> Make our change to the code. +<4> Check that the change is good. +<5> Commit our change to the topic branch. +<6> Push our new topic branch back up to our GitHub fork. Now if we go back to our fork on GitHub, we can see that GitHub noticed that we pushed a new topic branch up and presents us with a big green button to check out our changes and open a Pull Request to the original project. @@ -270,11 +270,11 @@ To https://github.com/tonychacon/blink ef4725c..3c8d735 slower-blink -> slow-blink ---- -<1> Add the original repository as a remote named ``upstream'' -<2> Fetch the newest work from that remote -<3> Merge the main branch of that repository into your topic branch -<4> Fix the conflict that occurred -<5> Push back up to the same topic branch +<1> Add the original repository as a remote named ``upstream''. +<2> Fetch the newest work from that remote. +<3> Merge the main branch of that repository into your topic branch. +<4> Fix the conflict that occurred. +<5> Push back up to the same topic branch. Once you do that, the Pull Request will be automatically updated and re-checked to see if it merges cleanly. @@ -359,7 +359,7 @@ You can create a task list like this: - [ ] Document the code ---- -If we include this in the description of our Pull Request or Issue, we'll see it rendered like <<_eg_task_lists>> +If we include this in the description of our Pull Request or Issue, we'll see it rendered like <<_eg_task_lists>>. [[_eg_task_lists]] .Task lists rendered in a Markdown comment diff --git a/book/06-github/sections/5-scripting.asc b/book/06-github/sections/5-scripting.asc index f27383bf5..669e2d3c5 100644 --- a/book/06-github/sections/5-scripting.asc +++ b/book/06-github/sections/5-scripting.asc @@ -107,7 +107,7 @@ image::images/scripting-04-webhook-debug.png[Webhook debug] The other great feature of this is that you can redeliver any of the payloads to test your service easily. -For more information on how to write webhooks and all the different event types you can listen for, go to the GitHub Developer documentation at https://developer.github.com/webhooks/ +For more information on how to write webhooks and all the different event types you can listen for, go to the GitHub Developer documentation at https://developer.github.com/webhooks/[]. ==== The GitHub API diff --git a/book/07-git-tools/sections/replace.asc b/book/07-git-tools/sections/replace.asc index ffd08203e..5da498f3f 100644 --- a/book/07-git-tools/sections/replace.asc +++ b/book/07-git-tools/sections/replace.asc @@ -94,7 +94,7 @@ $ echo 'Get history from blah blah blah' | git commit-tree 9c68fdc^{tree} The `commit-tree` command is one of a set of commands that are commonly referred to as 'plumbing' commands. These are commands that are not generally meant to be used directly, but instead are used by *other* Git commands to do smaller jobs. On occasions when we're doing weirder things like this, they allow us to do really low-level things but are not meant for daily use. -You can read more about plumbing commands in <> +You can read more about plumbing commands in <>. ===== image::images/replace3.png[] diff --git a/book/07-git-tools/sections/reset.asc b/book/07-git-tools/sections/reset.asc index c7002ac8c..3f87ac7e3 100644 --- a/book/07-git-tools/sections/reset.asc +++ b/book/07-git-tools/sections/reset.asc @@ -194,9 +194,9 @@ In this particular case, we still have the *v3* version of our file in a commit The `reset` command overwrites these three trees in a specific order, stopping when you tell it to: -1. Move the branch HEAD points to _(stop here if `--soft`)_ -2. Make the index look like HEAD _(stop here unless `--hard`)_ -3. Make the working directory look like the index +1. Move the branch HEAD points to _(stop here if `--soft`)_. +2. Make the index look like HEAD _(stop here unless `--hard`)_. +3. Make the working directory look like the index. ==== Reset With a Path @@ -208,8 +208,8 @@ But the index and working directory _can_ be partially updated, so reset proceed So, assume we run `git reset file.txt`. This form (since you did not specify a commit SHA-1 or branch, and you didn't specify `--soft` or `--hard`) is shorthand for `git reset --mixed HEAD file.txt`, which will: -1. Move the branch HEAD points to _(skipped)_ -2. Make the index look like HEAD _(stop here)_ +1. Move the branch HEAD points to _(skipped)_. +2. Make the index look like HEAD _(stop here)_. So it essentially just copies `file.txt` from HEAD to the index. diff --git a/book/07-git-tools/sections/submodules.asc b/book/07-git-tools/sections/submodules.asc index 1debc4c4d..365dbade9 100644 --- a/book/07-git-tools/sections/submodules.asc +++ b/book/07-git-tools/sections/submodules.asc @@ -732,11 +732,11 @@ $ git commit -m "Merge Tom's Changes" <5> [master 10d2c60] Merge Tom's Changes ---- -<1> First we resolve the conflict -<2> Then we go back to the main project directory -<3> We can check the SHA-1s again -<4> Resolve the conflicted submodule entry -<5> Commit our merge +<1> First we resolve the conflict. +<2> Then we go back to the main project directory. +<3> We can check the SHA-1s again. +<4> Resolve the conflicted submodule entry. +<5> Commit our merge. It can be a bit confusing, but it's really not very hard. diff --git a/book/09-git-and-other-scms/sections/client-bzr.asc b/book/09-git-and-other-scms/sections/client-bzr.asc index d8a5d4bd1..1e55e3e35 100644 --- a/book/09-git-and-other-scms/sections/client-bzr.asc +++ b/book/09-git-and-other-scms/sections/client-bzr.asc @@ -93,7 +93,7 @@ The two features are: As a consequence, there are two different situations to consider: -1. If the `.bzrignore` file does not contain any of these two specific prefixes, then you can simply make a symbolic link to it in the repository: `ln -s .bzrignore .git/info/exclude` +1. If the `.bzrignore` file does not contain any of these two specific prefixes, then you can simply make a symbolic link to it in the repository: `ln -s .bzrignore .git/info/exclude`. 2. Otherwise, you must create the `.git/info/exclude` file and adapt it to ignore exactly the same files in `.bzrignore`. Whatever the case is, you will have to remain vigilant against any change of `.bzrignore` to make sure that the `.git/info/exclude` file always reflects `.bzrignore`. diff --git a/book/A-git-in-other-environments/sections/powershell.asc b/book/A-git-in-other-environments/sections/powershell.asc index 67b404ce5..f0687afbd 100644 --- a/book/A-git-in-other-environments/sections/powershell.asc +++ b/book/A-git-in-other-environments/sections/powershell.asc @@ -21,9 +21,9 @@ With `RemoteSigned`, only scripts having the `ZoneIdentifier` set to `Internet` If you're an administrator and want to set it for all users on that machine, use `-Scope LocalMachine`. If you're a normal user, without administrative rights, you can use `-Scope CurrentUser` to set it only for you. -More about PowerShell Scopes: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_scopes[] +More about PowerShell Scopes: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_scopes[]. -More about PowerShell ExecutionPolicy: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.security/set-executionpolicy[] +More about PowerShell ExecutionPolicy: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.security/set-executionpolicy[]. To set the value of `ExecutionPolicy` to `RemoteSigned` for all users use the next command: @@ -36,7 +36,7 @@ To set the value of `ExecutionPolicy` to `RemoteSigned` for all users use the ne If you have at least PowerShell 5 or PowerShell 4 with PackageManagement installed, you can use the package manager to install posh-git for you. -More information about PowerShell Gallery: https://docs.microsoft.com/en-us/powershell/scripting/gallery/overview[] +More information about PowerShell Gallery: https://docs.microsoft.com/en-us/powershell/scripting/gallery/overview[]. [source,powershell] ---- @@ -83,4 +83,4 @@ Then import the module using the full path to the `posh-git.psd1` file: This will add the proper line to your `profile.ps1` file, and posh-git will be active the next time you open PowerShell. For a description of the Git status summary information displayed in the prompt see: https://github.com/dahlbyk/posh-git/blob/master/README.md#git-status-summary-information[] -For more details on how to customize your posh-git prompt see: https://github.com/dahlbyk/posh-git/blob/master/README.md#customization-variables[] +For more details on how to customize your posh-git prompt see: https://github.com/dahlbyk/posh-git/blob/master/README.md#customization-variables[]. diff --git a/book/A-git-in-other-environments/sections/sublimetext.asc b/book/A-git-in-other-environments/sections/sublimetext.asc index eded27be9..78f197fc6 100644 --- a/book/A-git-in-other-environments/sections/sublimetext.asc +++ b/book/A-git-in-other-environments/sections/sublimetext.asc @@ -11,4 +11,4 @@ The features are: * You can use part of the Sublime Merge git client functionality from within Sublime Text. (This requires that Sublime Merge is installed. See: https://www.sublimemerge.com/[]) -The official documentation for Sublime Text can be found here: https://www.sublimetext.com/docs/3/git_integration.html[] \ No newline at end of file +The official documentation for Sublime Text can be found here: https://www.sublimetext.com/docs/3/git_integration.html[]. diff --git a/book/A-git-in-other-environments/sections/visualstudiocode.asc b/book/A-git-in-other-environments/sections/visualstudiocode.asc index 581324d9f..1a53cb17e 100644 --- a/book/A-git-in-other-environments/sections/visualstudiocode.asc +++ b/book/A-git-in-other-environments/sections/visualstudiocode.asc @@ -16,6 +16,6 @@ The main features are: ** Resolve merge conflicts. ** View diffs. * With an extension, you can also handle GitHub Pull Requests: - https://marketplace.visualstudio.com/items?itemName=GitHub.vscode-pull-request-github[] + https://marketplace.visualstudio.com/items?itemName=GitHub.vscode-pull-request-github[]. -The official documentation can be found here: https://code.visualstudio.com/Docs/editor/versioncontrol[] +The official documentation can be found here: https://code.visualstudio.com/Docs/editor/versioncontrol[]. diff --git a/book/B-embedding-git/sections/dulwich.asc b/book/B-embedding-git/sections/dulwich.asc index c202686d0..73e052bd0 100644 --- a/book/B-embedding-git/sections/dulwich.asc +++ b/book/B-embedding-git/sections/dulwich.asc @@ -40,5 +40,5 @@ porcelain.log('.', max_entries=1) ==== Further Reading - * The official API documentation is available at https://www.dulwich.io/apidocs/dulwich.html[] - * Official tutorial at https://www.dulwich.io/docs/tutorial[] has many examples of how to do specific tasks with Dulwich + * The official API documentation is available at https://www.dulwich.io/apidocs/dulwich.html[]. + * Official tutorial at https://www.dulwich.io/docs/tutorial[] has many examples of how to do specific tasks with Dulwich. From 345e4b3f54f4eea9b09307391170fdb54a7befa7 Mon Sep 17 00:00:00 2001 From: Vipul Kumar Date: Thu, 25 Jun 2020 06:17:41 +0000 Subject: [PATCH 3/9] [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. --- book/01-introduction/sections/installing.asc | 2 +- book/01-introduction/sections/what-is-git.asc | 4 +-- .../sections/recording-changes.asc | 2 +- .../sections/basic-branching-and-merging.asc | 16 +++++----- book/03-git-branching/sections/nutshell.asc | 18 +++++------ book/03-git-branching/sections/rebasing.asc | 22 ++++++------- .../sections/remote-branches.asc | 8 ++--- book/03-git-branching/sections/workflows.asc | 8 ++--- book/04-git-server/sections/gitlab.asc | 8 ++--- book/04-git-server/sections/gitweb.asc | 2 +- .../sections/contributing.asc | 32 +++++++++---------- .../sections/distributed-workflows.asc | 6 ++-- .../sections/maintaining.asc | 18 +++++------ .../sections/1-setting-up-account.asc | 12 +++---- book/06-github/sections/2-contributing.asc | 4 +-- book/06-github/sections/3-maintaining.asc | 10 +++--- .../sections/4-managing-organization.asc | 2 +- .../sections/advanced-merging.asc | 10 +++--- .../sections/revision-selection.asc | 2 +- .../sections/attributes.asc | 4 +-- book/08-customizing-git/sections/config.asc | 2 +- .../sections/client-p4.asc | 4 +-- .../sections/client-tfs.asc | 2 +- book/10-git-internals/sections/objects.asc | 6 ++-- book/10-git-internals/sections/refs.asc | 2 +- .../sections/bash.asc | 2 +- .../sections/eclipse.asc | 2 +- .../sections/guis.asc | 12 +++---- .../sections/jetbrainsides.asc | 2 +- .../sections/powershell.asc | 2 +- .../sections/visualstudio.asc | 4 +-- .../sections/zsh.asc | 4 +-- 32 files changed, 117 insertions(+), 117 deletions(-) diff --git a/book/01-introduction/sections/installing.asc b/book/01-introduction/sections/installing.asc index 6f0a2730d..58cd3f016 100644 --- a/book/01-introduction/sections/installing.asc +++ b/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. diff --git a/book/01-introduction/sections/what-is-git.asc b/book/01-introduction/sections/what-is-git.asc index 47f904ec6..08de9a19c 100644 --- a/book/01-introduction/sections/what-is-git.asc +++ b/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. diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index ee76585af..25765dc52 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/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 diff --git a/book/03-git-branching/sections/basic-branching-and-merging.asc b/book/03-git-branching/sections/basic-branching-and-merging.asc index d26b34458..49f446146 100644 --- 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 index 278d269fd..cb89acc99 100644 --- 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. diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc index d69714f8b..726f5fc78 100644 --- a/book/03-git-branching/sections/rebasing.asc +++ b/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 <>. 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 <>): @@ -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 ` -- 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 <>, 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). diff --git a/book/03-git-branching/sections/remote-branches.asc b/book/03-git-branching/sections/remote-branches.asc index 05ddf3fbf..4062663c9 100644 --- a/book/03-git-branching/sections/remote-branches.asc +++ b/book/03-git-branching/sections/remote-branches.asc @@ -34,13 +34,13 @@ 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 ` 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`. @@ -48,13 +48,13 @@ You can add it as a new remote reference to the project you're currently working 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 diff --git a/book/03-git-branching/sections/workflows.asc b/book/03-git-branching/sections/workflows.asc index 4ae66a76d..0c2387016 100644 --- a/book/03-git-branching/sections/workflows.asc +++ b/book/03-git-branching/sections/workflows.asc @@ -17,13 +17,13 @@ In reality, we're talking about pointers moving up the line of commits you're ma The stable branches are farther down the line in your commit history, and the bleeding-edge branches are farther up the history. .A linear view of progressive-stability branching -image::images/lr-branches-1.png[A linear view of progressive-stability branching.] +image::images/lr-branches-1.png[A linear view of progressive-stability branching] It's generally easier to think about them as work silos, where sets of commits graduate to a more stable silo when they're fully tested. [[lrbranch_b]] .A ``silo'' view of progressive-stability branching -image::images/lr-branches-2.png[A ``silo'' view of progressive-stability branching.] +image::images/lr-branches-2.png[A ``silo'' view of progressive-stability branching] You can keep doing this for several levels of stability. Some larger projects also have a `proposed` or `pu` (proposed updates) branch that has integrated branches that may not be ready to go into the `next` or `master` branch. @@ -48,14 +48,14 @@ Consider an example of doing some work (on `master`), branching off for an issue Your commit history will look something like this: .Multiple topic branches -image::images/topic-branches-1.png[Multiple topic branches.] +image::images/topic-branches-1.png[Multiple topic branches] Now, let's say you decide you like the second solution to your issue best (`iss91v2`); and you showed the `dumbidea` branch to your coworkers, and it turns out to be genius. You can throw away the original `iss91` branch (losing commits `C5` and `C6`) and merge in the other two. Your history then looks like this: .History after merging `dumbidea` and `iss91v2` -image::images/topic-branches-2.png[History after merging `dumbidea` and `iss91v2`.] +image::images/topic-branches-2.png[History after merging `dumbidea` and `iss91v2`] We will go into more detail about the various possible workflows for your Git project in <>, so before you decide which branching scheme your next project will use, be sure to read that chapter. diff --git a/book/04-git-server/sections/gitlab.asc b/book/04-git-server/sections/gitlab.asc index 4b1696374..1984932f9 100644 --- a/book/04-git-server/sections/gitlab.asc +++ b/book/04-git-server/sections/gitlab.asc @@ -17,7 +17,7 @@ One nice touch Bitnami has included is the login screen (accessed by typing alt+ [[bitnami]] .The Bitnami GitLab virtual machine login screen -image::images/bitnami.png[The Bitnami GitLab virtual machine login screen.] +image::images/bitnami.png[The Bitnami GitLab virtual machine login screen] For anything else, follow the guidance in the GitLab Community Edition readme, which can be found at https://gitlab.com/gitlab-org/gitlab-ce/tree/master[]. There you'll find assistance for installing GitLab using Chef recipes, a virtual machine on Digital Ocean, and RPM and DEB packages (which, as of this writing, are in beta). @@ -32,7 +32,7 @@ Once logged in, click the ``Admin area'' icon in the menu at the top right. [[gitlab_menu]] .The ``Admin area'' item in the GitLab menu -image::images/gitlab-menu.png[The ``Admin area'' item in the GitLab menu.] +image::images/gitlab-menu.png[The ``Admin area'' item in the GitLab menu] ===== Users @@ -43,7 +43,7 @@ If the user +jane+ had a project named +project+, that project's url would be `h [[gitlab_users]] .The GitLab user administration screen -image::images/gitlab-users.png[The GitLab user administration screen.] +image::images/gitlab-users.png[The GitLab user administration screen] Removing a user can be done in two ways. ``Blocking'' a user prevents them from logging into the GitLab instance, but all of the data under that user's namespace will be preserved, and commits signed with that user's email address will still link back to their profile. @@ -60,7 +60,7 @@ Each group has a project namespace (the same way that users do), so if the group [[gitlab_groups]] .The GitLab group administration screen -image::images/gitlab-groups.png[The GitLab group administration screen.] +image::images/gitlab-groups.png[The GitLab group administration screen] Each group is associated with a number of users, each of which has a level of permissions for the group's projects and the group itself. These range from ``Guest'' (issues and chat only) to ``Owner'' (full control of the group, its members, and its projects). diff --git a/book/04-git-server/sections/gitweb.asc b/book/04-git-server/sections/gitweb.asc index 508858324..c8d2df557 100644 --- a/book/04-git-server/sections/gitweb.asc +++ b/book/04-git-server/sections/gitweb.asc @@ -6,7 +6,7 @@ Git comes with a CGI script called GitWeb that is sometimes used for this. [[gitweb]] .The GitWeb web-based user interface -image::images/git-instaweb.png[The GitWeb web-based user interface.] +image::images/git-instaweb.png[The GitWeb web-based user interface] If you want to check out what GitWeb would look like for your project, Git comes with a command to fire up a temporary instance if you have a lightweight web server on your system like `lighttpd` or `webrick`. On Linux machines, `lighttpd` is often installed, so you may be able to get it to run by typing `git instaweb` in your project directory. diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index 34fac8c18..f75d89f03 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -42,7 +42,7 @@ First, your submissions should not contain any whitespace errors. Git provides an easy way to check for this -- before you commit, run `git diff --check`, which identifies possible whitespace errors and lists them for you. .Output of `git diff --check` -image::images/git-diff-check.png[Output of `git diff --check`.] +image::images/git-diff-check.png[Output of `git diff --check`] If you run that command before committing, you can tell if you're about to commit whitespace issues that may annoy other developers. @@ -185,7 +185,7 @@ From john@githost:simplegit At this point, John's local repository looks something like this: .John's divergent history -image::images/small-team-1.png[John's divergent history.] +image::images/small-team-1.png[John's divergent history] Now John can merge Jessica's work that he fetched into his own local work: @@ -200,7 +200,7 @@ Merge made by the 'recursive' strategy. As long as that local merge goes smoothly, John's updated history will now look like this: .John's repository after merging `origin/master` -image::images/small-team-2.png[John's repository after merging `origin/master`.] +image::images/small-team-2.png[John's repository after merging `origin/master`] At this point, John might want to test this new code to make sure none of Jessica's work affects any of his and, as long as everything seems fine, he can finally push the new merged work up to the server: @@ -215,13 +215,13 @@ To john@githost:simplegit.git In the end, John's commit history will look like this: .John's history after pushing to the `origin` server -image::images/small-team-3.png[John's history after pushing to the `origin` server.] +image::images/small-team-3.png[John's history after pushing to the `origin` server] In the meantime, Jessica has created a new topic branch called `issue54`, and made three commits to that branch. She hasn't fetched John's changes yet, so her commit history looks like this: .Jessica's topic branch -image::images/small-team-4.png[Jessica's topic branch.] +image::images/small-team-4.png[Jessica's topic branch] Suddenly, Jessica learns that John has pushed some new work to the server and she wants to take a look at it, so she can fetch all new content from the server that she does not yet have with: @@ -238,7 +238,7 @@ That pulls down the work John has pushed up in the meantime. Jessica's history now looks like this: .Jessica's history after fetching John's changes -image::images/small-team-5.png[Jessica's history after fetching John's changes.] +image::images/small-team-5.png[Jessica's history after fetching John's changes] Jessica thinks her topic branch is ready, but she wants to know what part of John's fetched work she has to merge into her work so that she can push. She runs `git log` to find out: @@ -299,7 +299,7 @@ Merge made by the 'recursive' strategy. Everything merges cleanly, and Jessica's history now looks like this: .Jessica's history after merging John's changes -image::images/small-team-6.png[Jessica's history after merging John's changes.] +image::images/small-team-6.png[Jessica's history after merging John's changes] Now `origin/master` is reachable from Jessica's `master` branch, so she should be able to successfully push (assuming John hasn't pushed even more changes in the meantime): @@ -314,7 +314,7 @@ To jessica@githost:simplegit.git Each developer has committed a few times and merged each other's work successfully. .Jessica's history after pushing all changes back to the server -image::images/small-team-7.png[Jessica's history after pushing all changes back to the server.] +image::images/small-team-7.png[Jessica's history after pushing all changes back to the server] That is one of the simplest workflows. You work for a while (generally in a topic branch), and merge that work into your `master` branch when it's ready to be integrated. @@ -322,7 +322,7 @@ When you want to share that work, you fetch and merge your `master` from `origin The general sequence is something like this: .General sequence of events for a simple multiple-developer Git workflow -image::images/small-team-flow.png[General sequence of events for a simple multiple-developer Git workflow.] +image::images/small-team-flow.png[General sequence of events for a simple multiple-developer Git workflow] ==== Private Managed Team @@ -389,7 +389,7 @@ $ git commit -am 'Add ls-files' Jessica's repository now looks like this: .Jessica's initial commit history -image::images/managed-team-1.png[Jessica's initial commit history.] +image::images/managed-team-1.png[Jessica's initial commit history] She's ready to push her work, but gets an email from Josie that a branch with some initial ``featureB'' work on it was already pushed to the server as the `featureBee` branch. Jessica needs to merge those changes with her own before she can push her work to the server. @@ -481,20 +481,20 @@ To jessica@githost:simplegit.git Jessica's commit history now looks something like this: .Jessica's history after committing on a feature branch -image::images/managed-team-2.png[Jessica's history after committing on a feature branch.] +image::images/managed-team-2.png[Jessica's history after committing on a feature branch] At some point, Jessica, Josie, and John inform the integrators that the `featureA` and `featureBee` branches on the server are ready for integration into the mainline. After the integrators merge these branches into the mainline, a fetch will bring down the new merge commit, making the history look like this: .Jessica's history after merging both her topic branches -image::images/managed-team-3.png[Jessica's history after merging both her topic branches.] +image::images/managed-team-3.png[Jessica's history after merging both her topic branches] Many groups switch to Git because of this ability to have multiple teams working in parallel, merging the different lines of work late in the process. The ability of smaller subgroups of a team to collaborate via remote branches without necessarily having to involve or impede the entire team is a huge benefit of Git. The sequence for the workflow you saw here is something like this: .Basic sequence of this managed-team workflow -image::images/managed-team-flow.png[Basic sequence of this managed-team workflow.] +image::images/managed-team-flow.png[Basic sequence of this managed-team workflow] [[_public_project]] ==== Forked Public Project @@ -591,7 +591,7 @@ $ git fetch origin Now, each of your topics is contained within a silo -- similar to a patch queue -- that you can rewrite, rebase, and modify without the topics interfering or interdepending on each other, like so: .Initial commit history with `featureB` work -image::images/public-small-1.png[Initial commit history with `featureB` work.] +image::images/public-small-1.png[Initial commit history with `featureB` work] Let's say the project maintainer has pulled in a bunch of other patches and tried your first branch, but it no longer cleanly merges. In this case, you can try to rebase that branch on top of `origin/master`, resolve the conflicts for the maintainer, and then resubmit your changes: @@ -607,7 +607,7 @@ This rewrites your history to now look like <>. [[psp_b]] .Commit history after `featureA` work -image::images/public-small-2.png[Commit history after `featureA` work.] +image::images/public-small-2.png[Commit history after `featureA` work] Because you rebased the branch, you have to specify the `-f` to your push command in order to be able to replace the `featureA` branch on the server with a commit that isn't a descendant of it. An alternative would be to push this new work to a different branch on the server (perhaps called `featureAv2`). @@ -633,7 +633,7 @@ Also the `--no-commit` option can be useful to delay the merge commit in case of At this point, you can notify the maintainer that you've made the requested changes, and that they can find those changes in your `featureBv2` branch. .Commit history after `featureBv2` work -image::images/public-small-3.png[Commit history after `featureBv2` work.] +image::images/public-small-3.png[Commit history after `featureBv2` work] [[_project_over_email]] ==== Public Project over Email diff --git a/book/05-distributed-git/sections/distributed-workflows.asc b/book/05-distributed-git/sections/distributed-workflows.asc index e07b6e7b9..3ee8a99eb 100644 --- a/book/05-distributed-git/sections/distributed-workflows.asc +++ b/book/05-distributed-git/sections/distributed-workflows.asc @@ -15,7 +15,7 @@ One central hub, or _repository_, can accept code, and everyone synchronizes the A number of developers are nodes -- consumers of that hub -- and synchronize with that centralized location. .Centralized workflow -image::images/centralized_workflow.png[Centralized workflow.] +image::images/centralized_workflow.png[Centralized workflow] This means that if two developers clone from the hub and both make changes, the first developer to push their changes back up can do so with no problems. The second developer must merge in the first one's work before pushing changes up, so as not to overwrite the first developer's changes. @@ -53,7 +53,7 @@ The process works as follows (see <>): [[wfdiag_b]] .Integration-manager workflow -image::images/integration-manager.png[Integration-manager workflow.] +image::images/integration-manager.png[Integration-manager workflow] (((forking))) This is a very common workflow with hub-based tools like GitHub or GitLab, where it's easy to fork a project and push your changes into your fork for everyone to see. @@ -78,7 +78,7 @@ The process works like this (see <>): [[wfdiag_c]] .Benevolent dictator workflow -image::images/benevolent-dictator.png[Benevolent dictator workflow.] +image::images/benevolent-dictator.png[Benevolent dictator workflow] This kind of workflow isn't common, but can be useful in very big projects, or in highly hierarchical environments. It allows the project leader (the dictator) to delegate much of the work and collect large subsets of code at multiple points before integrating them. diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 1eb061bfd..b8f2c439f 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -311,11 +311,11 @@ For instance, if we have a repository with work in two branches named `ruby_clie [[merwf_a]] .History with several topic branches -image::images/merging-workflows-1.png[History with several topic branches.] +image::images/merging-workflows-1.png[History with several topic branches] [[merwf_b]] .After a topic branch merge -image::images/merging-workflows-2.png[After a topic branch merge.] +image::images/merging-workflows-2.png[After a topic branch merge] That is probably the simplest workflow, but it can possibly be problematic if you're dealing with larger or more stable projects where you want to be really careful about what you introduce. @@ -326,15 +326,15 @@ Each time you have a new topic branch to merge in (<>), you merge it in [[merwf_c]] .Before a topic branch merge -image::images/merging-workflows-3.png[Before a topic branch merge.] +image::images/merging-workflows-3.png[Before a topic branch merge] [[merwf_d]] .After a topic branch merge -image::images/merging-workflows-4.png[After a topic branch merge.] +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 topic branch 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. @@ -350,7 +350,7 @@ If they're safe, they're merged into `next`, and that branch is pushed up so eve [[merwf_f]] .Managing a complex series of parallel contributed topic branches -image::images/large-merges-1.png[Managing a complex series of parallel contributed topic branches.] +image::images/large-merges-1.png[Managing a complex series of parallel contributed topic branches] If the topics still need work, they're merged into `pu` instead. When it's determined that they're totally stable, the topics are re-merged into `master`. @@ -358,7 +358,7 @@ The `next` and `pu` branches are then rebuilt from the `master`. This means `master` almost always moves forward, `next` is rebased occasionally, and `pu` is rebased even more often: .Merging contributed topic branches into long-term integration branches -image::images/large-merges-2.png[Merging contributed topic branches into long-term integration branches.] +image::images/large-merges-2.png[Merging contributed topic branches into long-term integration branches] When a topic branch has finally been merged into `master`, it's removed from the repository. The Git project also has a `maint` branch that is forked off from the last release to provide backported patches in case a maintenance release is required. @@ -382,7 +382,7 @@ This is useful if you have a number of commits on a topic branch and you want to For example, suppose you have a project that looks like this: .Example history before a cherry-pick -image::images/rebasing-1.png[Example history before a cherry-pick.] +image::images/rebasing-1.png[Example history before a cherry-pick] If you want to pull commit `e43a6` into your `master` branch, you can run @@ -398,7 +398,7 @@ This pulls the same change introduced in `e43a6`, but you get a new commit SHA-1 Now your history looks like this: .History after cherry-picking a commit on a topic branch -image::images/rebasing-2.png[History after cherry-picking a commit on a topic branch.] +image::images/rebasing-2.png[History after cherry-picking a commit on a topic branch] Now you can remove your topic branch and drop the commits you didn't want to pull in. diff --git a/book/06-github/sections/1-setting-up-account.asc b/book/06-github/sections/1-setting-up-account.asc index da092eb33..49b95f376 100644 --- a/book/06-github/sections/1-setting-up-account.asc +++ b/book/06-github/sections/1-setting-up-account.asc @@ -5,7 +5,7 @@ The first thing you need to do is set up a free user account. Simply visit https://github.com[], choose a user name that isn't already taken, provide an email address and a password, and click the big green ``Sign up for GitHub'' button. .The GitHub sign-up form -image::images/signup.png[The GitHub sign-up form.] +image::images/signup.png[The GitHub sign-up form] The next thing you'll see is the pricing page for upgraded plans, but it's safe to ignore this for now. GitHub will send you an email to verify the address you provided. @@ -33,12 +33,12 @@ If you'd like to use SSH remotes, you'll need to configure a public key. Open up your account settings using the link at the top-right of the window: .The ``Account settings'' link -image::images/account-settings.png[The ``Account settings'' link.] +image::images/account-settings.png[The ``Account settings'' link] Then select the ``SSH keys'' section along the left-hand side. .The ``SSH keys'' link -image::images/ssh-keys.png[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''. @@ -55,12 +55,12 @@ Next, if you wish, you can replace the avatar that is generated for you with an First go to the ``Profile'' tab (above the SSH Keys tab) and click ``Upload new picture''. .The ``Profile'' link -image::images/your-profile.png[The ``Profile'' link.] +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 -image::images/avatar-crop.png[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. @@ -73,7 +73,7 @@ If you use multiple email addresses in your commits and you want GitHub to link [[_add_email_addresses]] .Add email addresses -image::images/email-settings.png[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. The top address is verified and set as the primary address, meaning that is where you'll get any notifications and receipts. diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index ef3c95861..df9cbf915 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -21,7 +21,7 @@ This opens up a discussion thread with code review, and the owner and the contri To fork a project, visit the project page and click the ``Fork'' button at the top-right of the page. .The ``Fork'' button -image::images/forkbutton.png[The ``Fork'' button.] +image::images/forkbutton.png[The ``Fork'' button] After a few seconds, you'll be taken to your new project page, with your own writeable copy of the code. @@ -54,7 +54,7 @@ Let's walk through an example of proposing a change to an open source project ho Tony is looking for code to run on his Arduino programmable microcontroller and has found a great program file on GitHub at https://github.com/schacon/blink[]. .The project we want to contribute to -image::images/blink-01-start.png[The project we want to contribute to.] +image::images/blink-01-start.png[The project we want to contribute to] The only problem is that the blinking rate is too fast. We think it's much nicer to wait 3 seconds instead of 1 in between each state change. diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index 66de8b5c7..cc7637e1a 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -9,16 +9,16 @@ Let's create a new repository to share our project code with. Start by clicking the ``New repository'' button on the right-hand side of the dashboard, or from the `+` button in the top toolbar next to your username as seen in <<_new_repo_dropdown>>. .The ``Your repositories'' area -image::images/newrepo.png[The ``Your repositories'' area.] +image::images/newrepo.png[The ``Your repositories'' area] [[_new_repo_dropdown]] .The ``New repository'' dropdown -image::images/new-repo.png[The ``new repository'' dropdown.] +image::images/new-repo.png[The ``new repository'' dropdown] This takes you to the ``new repository'' form: .The ``new repository'' form -image::images/newrepoform.png[The ``new repository'' form.] +image::images/newrepoform.png[The ``new repository'' form] All you really have to do here is provide a project name; the rest of the fields are completely optional. For now, just click the ``Create Repository'' button, and boom – you have a new repository on GitHub, named `/`. @@ -46,7 +46,7 @@ Doing so will give them ``push'' access, which means they have both read and wri Click the ``Settings'' link at the bottom of the right-hand sidebar. .The repository settings link -image::images/reposettingslink.png[The repository settings link.] +image::images/reposettingslink.png[The repository settings link] Then select ``Collaborators'' from the menu on the left-hand side. Then, just type a username into the box, and click ``Add collaborator.'' @@ -54,7 +54,7 @@ You can repeat this as many times as you like to grant access to everyone you li If you need to revoke access, just click the ``X'' on the right-hand side of their row. .Repository collaborators -image::images/collaborators.png[The repository collaborators box.] +image::images/collaborators.png[The repository collaborators box] ==== Managing Pull Requests diff --git a/book/06-github/sections/4-managing-organization.asc b/book/06-github/sections/4-managing-organization.asc index 42f1f1f72..ab30a2fd5 100644 --- a/book/06-github/sections/4-managing-organization.asc +++ b/book/06-github/sections/4-managing-organization.asc @@ -12,7 +12,7 @@ Normally these accounts are used for Open Source groups (such as ``perl'' or ``r An organization is pretty easy to create; just click on the ``+'' icon at the top-right of any GitHub page, and select ``New organization'' from the menu. .The ``New organization'' menu item -image::images/neworg.png[The ``New organization'' menu item.] +image::images/neworg.png[The ``New organization'' menu item] First you'll need to name your organization and provide an email address for a main point of contact for the group. Then you can invite other users to be co-owners of the account if you want to. diff --git a/book/07-git-tools/sections/advanced-merging.asc b/book/07-git-tools/sections/advanced-merging.asc index 1f1191c47..3fca09d99 100644 --- a/book/07-git-tools/sections/advanced-merging.asc +++ b/book/07-git-tools/sections/advanced-merging.asc @@ -535,7 +535,7 @@ Merge commits are no different. Let's say you started work on a topic branch, accidentally merged it into `master`, and now your commit history looks like this: .Accidental merge commit -image::images/undomerge-start.png[Accidental merge commit.] +image::images/undomerge-start.png[Accidental merge commit] There are two ways to approach this problem, depending on what your desired outcome is. @@ -545,7 +545,7 @@ If the unwanted merge commit only exists on your local repository, the easiest a In most cases, if you follow the errant `git merge` with `git reset --hard HEAD~`, this will reset the branch pointers so they look like this: .History after `git reset --hard HEAD~` -image::images/undomerge-reset.png[History after `git reset --hard HEAD~`.] +image::images/undomerge-reset.png[History after `git reset --hard HEAD~`] We covered `reset` back in <>, so it shouldn't be too hard to figure out what's going on here. Here's a quick refresher: `reset --hard` usually goes through three steps: @@ -578,7 +578,7 @@ In this case, we want to undo all the changes introduced by merging in parent #2 The history with the revert commit looks like this: .History after `git revert -m 1` -image::images/undomerge-revert.png[History after `git revert -m 1`.] +image::images/undomerge-revert.png[History after `git revert -m 1`] The new commit `^M` has exactly the same contents as `C6`, so starting from here it's as if the merge never happened, except that the now-unmerged commits are still in `HEAD`'s history. Git will get confused if you try to merge `topic` into `master` again: @@ -593,7 +593,7 @@ There's nothing in `topic` that isn't already reachable from `master`. What's worse, if you add work to `topic` and merge again, Git will only bring in the changes _since_ the reverted merge: .History with a bad merge -image::images/undomerge-revert2.png[History with a bad merge.] +image::images/undomerge-revert2.png[History with a bad merge] The best way around this is to un-revert the original merge, since now you want to bring in the changes that were reverted out, *then* create a new merge commit: @@ -605,7 +605,7 @@ $ git merge topic ---- .History after re-merging a reverted merge -image::images/undomerge-revert3.png[History after re-merging a reverted merge.] +image::images/undomerge-revert3.png[History after re-merging a reverted merge] In this example, `M` and `^M` cancel out. `^^M` effectively merges in the changes from `C3` and `C4`, and `C8` merges in the changes from `C7`, so now `topic` is fully merged. diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc index 79fccfea1..68a4073d9 100644 --- a/book/07-git-tools/sections/revision-selection.asc +++ b/book/07-git-tools/sections/revision-selection.asc @@ -292,7 +292,7 @@ For example, say you have a commit history that looks like <>. [[double_dot]] .Example history for range selection -image::images/double-dot.png[Example history for range selection.] +image::images/double-dot.png[Example history for range selection] Say you want to see what is in your `experiment` branch that hasn't yet been merged into your `master` branch. You can ask Git to show you a log of just those commits with `master..experiment` -- that means ``all commits reachable from `experiment` that aren't reachable from `master`.'' diff --git a/book/08-customizing-git/sections/attributes.asc b/book/08-customizing-git/sections/attributes.asc index 6863c82f9..6438920ad 100644 --- a/book/08-customizing-git/sections/attributes.asc +++ b/book/08-customizing-git/sections/attributes.asc @@ -198,11 +198,11 @@ These filters can be set to do all sorts of fun things. [[filters_a]] .The ``smudge'' filter is run on checkout -image::images/smudge.png[The ``smudge'' filter is run on checkout.] +image::images/smudge.png[The ``smudge'' filter is run on checkout] [[filters_b]] .The ``clean'' filter is run when files are staged -image::images/clean.png[The ``clean'' filter is run when files are staged.] +image::images/clean.png[The ``clean'' filter is run when files are staged] The original commit message for this feature gives a simple example of running all your C source code through the `indent` program before committing. You can set it up by setting the filter attribute in your `.gitattributes` file to filter `*.c` files with the ``indent'' filter: diff --git a/book/08-customizing-git/sections/config.asc b/book/08-customizing-git/sections/config.asc index e4277734e..68a42c0a4 100644 --- a/book/08-customizing-git/sections/config.asc +++ b/book/08-customizing-git/sections/config.asc @@ -320,7 +320,7 @@ $ git diff 32d1776b1^ 32d1776b1 Instead of getting the diff output on the command line, Git fires up P4Merge, which looks something like this: .P4Merge -image::images/p4merge.png[P4Merge.] +image::images/p4merge.png[P4Merge] If you try to merge two branches and subsequently have merge conflicts, you can run the command `git mergetool`; it starts P4Merge to let you resolve the conflicts through that GUI tool. diff --git a/book/09-git-and-other-scms/sections/client-p4.asc b/book/09-git-and-other-scms/sections/client-p4.asc index e6950fbda..61ae65c75 100644 --- a/book/09-git-and-other-scms/sections/client-p4.asc +++ b/book/09-git-and-other-scms/sections/client-p4.asc @@ -26,7 +26,7 @@ Upon first starting the machine, it asks you to customize the password for three When that has all completed, you'll see this: .The Git Fusion virtual machine boot screen -image::images/git-fusion-boot.png[The Git Fusion virtual machine boot screen.] +image::images/git-fusion-boot.png[The Git Fusion virtual machine boot screen] You should take note of the IP address that's shown here, we'll be using it later on. Next, we'll create a Perforce user. @@ -289,7 +289,7 @@ Git thinks it worked. Let's take a look at the history of the `README` file from Perforce's point of view, using the revision graph feature of `p4v`: .Perforce revision graph resulting from Git push -image::images/git-fusion-perforce-graph.png[Perforce revision graph resulting from Git push.] +image::images/git-fusion-perforce-graph.png[Perforce revision graph resulting from Git push] If you've never seen this view before, it may seem confusing, but it shows the same concepts as a graphical viewer for Git history. We're looking at the history of the `README` file, so the directory tree at top left only shows that file as it surfaces in various branches. diff --git a/book/09-git-and-other-scms/sections/client-tfs.asc b/book/09-git-and-other-scms/sections/client-tfs.asc index fc697f325..8f205058d 100644 --- a/book/09-git-and-other-scms/sections/client-tfs.asc +++ b/book/09-git-and-other-scms/sections/client-tfs.asc @@ -380,7 +380,7 @@ PS> git tfs ct It looks a bit like this: .The git-tfs checkin tool -image::images/git-tfs-ct.png[The git-tfs checkin tool.] +image::images/git-tfs-ct.png[The git-tfs checkin tool] This will look familiar to TFS users, as it's the same dialog that's launched from within Visual Studio. diff --git a/book/10-git-internals/sections/objects.asc b/book/10-git-internals/sections/objects.asc index e5be083e0..081c35383 100644 --- a/book/10-git-internals/sections/objects.asc +++ b/book/10-git-internals/sections/objects.asc @@ -158,7 +158,7 @@ If you're using ZSH, the `^` character is used for globbing, so you have to encl Conceptually, the data that Git is storing looks something like this: .Simple version of the Git data model -image::images/data-model-1.png[Simple version of the Git data model.] +image::images/data-model-1.png[Simple version of the Git data model] You can fairly easily create your own tree. Git normally creates a tree by taking the state of your staging area or index and writing a series of tree objects from it. @@ -239,7 +239,7 @@ If you created a working directory from the new tree you just wrote, you would g You can think of the data that Git contains for these structures as being like this: .The content structure of your current Git data -image::images/data-model-2.png[The content structure of your current Git data.] +image::images/data-model-2.png[The content structure of your current Git data] [[_git_commit_objects]] ==== Commit Objects @@ -348,7 +348,7 @@ $ find .git/objects -type f If you follow all the internal pointers, you get an object graph something like this: .All the reachable objects in your Git directory -image::images/data-model-3.png[All the reachable objects in your Git directory.] +image::images/data-model-3.png[All the reachable objects in your Git directory] ==== Object Storage diff --git a/book/10-git-internals/sections/refs.asc b/book/10-git-internals/sections/refs.asc index 39f0faf29..0f794b33b 100644 --- a/book/10-git-internals/sections/refs.asc +++ b/book/10-git-internals/sections/refs.asc @@ -60,7 +60,7 @@ fdf4fc3344e67ab068f836878b6c4951e3b15f3d First commit Now, your Git database conceptually looks something like this: .Git directory objects with branch head references included -image::images/data-model-4.png[Git directory objects with branch head references included.] +image::images/data-model-4.png[Git directory objects with branch head references included] When you run commands like `git branch `, Git basically runs that `update-ref` command to add the SHA-1 of the last commit of the branch you're on into whatever new reference you want to create. diff --git a/book/A-git-in-other-environments/sections/bash.asc b/book/A-git-in-other-environments/sections/bash.asc index a317780c4..ad383947e 100644 --- a/book/A-git-in-other-environments/sections/bash.asc +++ b/book/A-git-in-other-environments/sections/bash.asc @@ -37,6 +37,6 @@ The `\w` means print the current working directory, the `\$` prints the `$` part Now your bash prompt will look like this when you're anywhere inside a Git-controlled project: .Customized `bash` prompt -image::images/git-bash.png[Customized `bash` prompt.] +image::images/git-bash.png[Customized `bash` prompt] Both of these scripts come with helpful documentation; take a look at the contents of `git-completion.bash` and `git-prompt.sh` for more information. diff --git a/book/A-git-in-other-environments/sections/eclipse.asc b/book/A-git-in-other-environments/sections/eclipse.asc index 2facd117a..ef6781709 100644 --- a/book/A-git-in-other-environments/sections/eclipse.asc +++ b/book/A-git-in-other-environments/sections/eclipse.asc @@ -5,6 +5,6 @@ Eclipse ships with a plugin called Egit, which provides a fairly-complete interf It's accessed by switching to the Git Perspective (Window > Open Perspective > Other…, and select "Git"). .Eclipse's EGit environment -image::images/egit.png[Eclipse's EGit environment.] +image::images/egit.png[Eclipse's EGit environment] EGit comes with plenty of great documentation, which you can find by going to Help > Help Contents, and choosing the "EGit Documentation" node from the contents listing. diff --git a/book/A-git-in-other-environments/sections/guis.asc b/book/A-git-in-other-environments/sections/guis.asc index b046bd896..03b1b870e 100644 --- a/book/A-git-in-other-environments/sections/guis.asc +++ b/book/A-git-in-other-environments/sections/guis.asc @@ -32,7 +32,7 @@ Probably one of the most useful is the `--all` flag, which tells gitk to show co Gitk's interface looks like this: .The `gitk` history viewer -image::images/gitk.png[The `gitk` history viewer.] +image::images/gitk.png[The `gitk` history viewer] On the top is something that looks a bit like the output of `git log --graph`; each dot represents a commit, the lines represent parent relationships, and refs are shown as colored boxes. The yellow dot represents HEAD, and the red dot represents changes that are yet to become a commit. @@ -50,7 +50,7 @@ $ git gui And it looks something like this: .The `git-gui` commit tool -image::images/git-gui.png[The `git-gui` commit tool.] +image::images/git-gui.png[The `git-gui` commit tool] On the left is the index; unstaged changes are on top, staged changes on the bottom. You can move entire files between the two states by clicking on their icons, or you can select a file for viewing by clicking on its name. @@ -74,10 +74,10 @@ These clients are a good example of workflow-oriented tools – rather than expo They look like this: .GitHub for macOS -image::images/github_mac.png[GitHub for macOS.] +image::images/github_mac.png[GitHub for macOS] .GitHub for Windows -image::images/github_win.png[GitHub for Windows.] +image::images/github_win.png[GitHub for Windows] They are designed to look and work very much alike, so we'll treat them like a single product in this chapter. We won't be doing a detailed rundown of these tools (they have their own documentation), but a quick tour of the ``changes'' view (which is where you'll spend most of your time) is in order. @@ -117,12 +117,12 @@ Branch management is one of the areas where the two tools diverge. On macOS, there's a button at the top of the window for creating a new branch: .``Create Branch'' button on macOS -image::images/branch_widget_mac.png[``Create Branch'' button on macOS.] +image::images/branch_widget_mac.png[``Create Branch'' button on macOS] On Windows, this is done by typing the new branch's name in the branch-switching widget: .Creating a branch on Windows -image::images/branch_widget_win.png[Creating a branch on Windows.] +image::images/branch_widget_win.png[Creating a branch on Windows] Once your branch is created, making new commits is fairly straightforward. Make some changes in your working directory, and when you switch to the GitHub client window, it will show you which files changed. diff --git a/book/A-git-in-other-environments/sections/jetbrainsides.asc b/book/A-git-in-other-environments/sections/jetbrainsides.asc index 529d0754c..d6040ca76 100644 --- a/book/A-git-in-other-environments/sections/jetbrainsides.asc +++ b/book/A-git-in-other-environments/sections/jetbrainsides.asc @@ -4,7 +4,7 @@ JetBrains IDEs (such as IntelliJ IDEA, PyCharm, WebStorm, PhpStorm, RubyMine, an It provides a dedicated view in the IDE to work with Git and GitHub Pull Requests. .Version Control ToolWindow in JetBrains IDEs -image::images/jb.png[Version Control ToolWindow in JetBrains IDEs.] +image::images/jb.png[Version Control ToolWindow in JetBrains IDEs] The integration relies on the command-line git client, and requires one to be installed. The official documentation is available at https://www.jetbrains.com/help/idea/using-git-integration.html[]. diff --git a/book/A-git-in-other-environments/sections/powershell.asc b/book/A-git-in-other-environments/sections/powershell.asc index f0687afbd..66f7c3cca 100644 --- a/book/A-git-in-other-environments/sections/powershell.asc +++ b/book/A-git-in-other-environments/sections/powershell.asc @@ -9,7 +9,7 @@ A package called posh-git (https://github.com/dahlbyk/posh-git[]) provides power It looks like this: .PowerShell with Posh-git -image::images/posh-git.png[PowerShell with Posh-git.] +image::images/posh-git.png[PowerShell with Posh-git] ==== Installation diff --git a/book/A-git-in-other-environments/sections/visualstudio.asc b/book/A-git-in-other-environments/sections/visualstudio.asc index 78902660d..a4f098672 100644 --- a/book/A-git-in-other-environments/sections/visualstudio.asc +++ b/book/A-git-in-other-environments/sections/visualstudio.asc @@ -9,7 +9,7 @@ To locate the feature, open a project that's controlled by Git (or just `git ini You'll see the "Connect" view, which looks a bit like this: .Connecting to a Git repository from Team Explorer -image::images/vs-1.png[Connecting to a Git repository from Team Explorer.] +image::images/vs-1.png[Connecting to a Git repository from Team Explorer] Visual Studio remembers all of the projects you've opened that are Git-controlled, and they're available in the list at the bottom. If you don't see the one you want there, click the "Add" link and type in the path to the working directory. @@ -18,7 +18,7 @@ This is a hub for performing Git actions; when you're _writing_ code, you'll pro [[vs_home]] .The "Home" view for a Git repository in Visual Studio -image::images/vs-2.png[The Home view for a Git repository in Visual Studio.] +image::images/vs-2.png[The Home view for a Git repository in Visual Studio] Visual Studio now has a powerful task-focused UI for Git. It includes a linear history view, a diff viewer, remote commands, and many other capabilities. diff --git a/book/A-git-in-other-environments/sections/zsh.asc b/book/A-git-in-other-environments/sections/zsh.asc index e389a0709..934bab35c 100644 --- a/book/A-git-in-other-environments/sections/zsh.asc +++ b/book/A-git-in-other-environments/sections/zsh.asc @@ -38,7 +38,7 @@ This results in a display of the current branch on the right-hand side of the te It looks a bit like this: .Customized `zsh` prompt -image::images/zsh-prompt.png[Customized `zsh` prompt.] +image::images/zsh-prompt.png[Customized `zsh` prompt] For more information on `vcs_info`, check out its documentation in the `zshcontrib(1)` manual page, or online at http://zsh.sourceforge.net/Doc/Release/User-Contributions.html#Version-Control-Information[]. @@ -52,4 +52,4 @@ oh-my-zsh's plugin system comes with powerful git tab-completion, and it has a v [[oh_my_zsh_git]] .An example of an oh-my-zsh theme -image::images/zsh-oh-my.png[An example of an oh-my-zsh theme.] +image::images/zsh-oh-my.png[An example of an oh-my-zsh theme] From 6830c00a42fa102f8e5ed27761469af475f136fa Mon Sep 17 00:00:00 2001 From: Vipul Kumar Date: Wed, 24 Jun 2020 09:14:06 +0000 Subject: [PATCH 4/9] [Fix] use 'an' article before vowel sounds --- .github/ISSUE_TEMPLATE/bug_report.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md index c1b1a0a70..1cae9e978 100644 --- a/.github/ISSUE_TEMPLATE/bug_report.md +++ b/.github/ISSUE_TEMPLATE/bug_report.md @@ -12,7 +12,7 @@ assignees: '' - + @@ -58,7 +58,7 @@ assignees: '' - Browser/application version: **E-book reader:** - + - Device: - Software Update: From 6183d831957dcb7a3013a9d3173597438b7ef52b Mon Sep 17 00:00:00 2001 From: Vipul Kumar Date: Thu, 25 Jun 2020 07:57:40 +0000 Subject: [PATCH 5/9] [enh] add missing text in square bracket Some square brackets are empty, but they do have caption along with them. So I've put same text as caption in empty square brackets. --- book/06-github/sections/4-managing-organization.asc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/book/06-github/sections/4-managing-organization.asc b/book/06-github/sections/4-managing-organization.asc index ab30a2fd5..e919b3344 100644 --- a/book/06-github/sections/4-managing-organization.asc +++ b/book/06-github/sections/4-managing-organization.asc @@ -41,7 +41,7 @@ The Organization page shows you a simple dashboard of all the repositories, user [[_org_page]] .The Organization page -image::images/orgs-01-page.png[] +image::images/orgs-01-page.png[The Organization page] To manage your Teams, you can click on the Teams sidebar on the right hand side of the page in <<_org_page>>. This will bring you to a page you can use to add members to the team, add repositories to the team or manage the settings and access control levels for the team. @@ -50,7 +50,7 @@ You can change that level by clicking the ``Settings'' button in <<_team_page>>. [[_team_page]] .The Team page -image::images/orgs-02-teams.png[] +image::images/orgs-02-teams.png[The Team page] When you invite someone to a team, they will get an email letting them know they've been invited. @@ -67,6 +67,6 @@ You can go to the 'Audit Log' tab and see what events have happened at an organi [[_the_audit_log]] .The Audit log -image::images/orgs-03-audit.png[] +image::images/orgs-03-audit.png[The Audit log] You can also filter down to specific types of events, specific places or specific people. From 7d59c28a0b1a68a913eef33f696a62cae8de2821 Mon Sep 17 00:00:00 2001 From: Vipul Kumar Date: Fri, 26 Jun 2020 07:47:29 +0000 Subject: [PATCH 6/9] [Fix] add missing colon We generally separate statement and commands with a colon. --- book/01-introduction/sections/help.asc | 2 +- book/01-introduction/sections/installing.asc | 2 +- book/02-git-basics/sections/viewing-history.asc | 2 +- book/04-git-server/sections/git-on-a-server.asc | 4 ++-- book/04-git-server/sections/protocols.asc | 2 +- book/05-distributed-git/sections/maintaining.asc | 2 +- book/07-git-tools/sections/advanced-merging.asc | 2 +- book/07-git-tools/sections/revision-selection.asc | 4 ++-- book/07-git-tools/sections/rewriting-history.asc | 6 +++--- book/07-git-tools/sections/subtree-merges.asc | 2 +- book/08-customizing-git/sections/config.asc | 8 ++++---- book/08-customizing-git/sections/policy.asc | 8 ++++---- book/09-git-and-other-scms/sections/client-svn.asc | 4 ++-- book/09-git-and-other-scms/sections/import-svn.asc | 2 +- book/10-git-internals/sections/refspec.asc | 2 +- 15 files changed, 26 insertions(+), 26 deletions(-) diff --git a/book/01-introduction/sections/help.asc b/book/01-introduction/sections/help.asc index 6f4a62b31..e7169ee5d 100644 --- a/book/01-introduction/sections/help.asc +++ b/book/01-introduction/sections/help.asc @@ -10,7 +10,7 @@ $ git --help $ man git- ---- -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:(((git commands, help))) [source,console] ---- diff --git a/book/01-introduction/sections/installing.asc b/book/01-introduction/sections/installing.asc index 58cd3f016..0652df97b 100644 --- a/book/01-introduction/sections/installing.asc +++ b/book/01-introduction/sections/installing.asc @@ -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/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index 2dd731f28..172d86697 100644 --- 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/04-git-server/sections/git-on-a-server.asc b/book/04-git-server/sections/git-on-a-server.asc index 18727c660..61847a993 100644 --- a/book/04-git-server/sections/git-on-a-server.asc +++ b/book/04-git-server/sections/git-on-a-server.asc @@ -23,7 +23,7 @@ done. You should now have a copy of the Git directory data in your `my_project.git` directory. -This is roughly equivalent to something like +This is roughly equivalent to something like: [source,console] ---- @@ -45,7 +45,7 @@ Assuming that `/srv/git` exists on that server, you can set up your new reposito $ scp -r my_project.git user@git.example.com:/srv/git ---- -At this point, other users who have SSH-based read access to the `/srv/git` directory on that server can clone your repository by running +At this point, other users who have SSH-based read access to the `/srv/git` directory on that server can clone your repository by running: [source,console] ---- diff --git a/book/04-git-server/sections/protocols.asc b/book/04-git-server/sections/protocols.asc index 6fbb41e83..99d232a72 100644 --- a/book/04-git-server/sections/protocols.asc +++ b/book/04-git-server/sections/protocols.asc @@ -105,7 +105,7 @@ $ chmod a+x hooks/post-update That's all.(((hooks, post-update))) The `post-update` hook that comes with Git by default runs the appropriate command (`git update-server-info`) to make HTTP fetching and cloning work properly. -This command is run when you push to this repository (over SSH perhaps); then, other people can clone via something like +This command is run when you push to this repository (over SSH perhaps); then, other people can clone via something like: [source,console] ---- diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index b8f2c439f..8196ce914 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -384,7 +384,7 @@ For example, suppose you have a project that looks like this: .Example history before a cherry-pick image::images/rebasing-1.png[Example history before a cherry-pick] -If you want to pull commit `e43a6` into your `master` branch, you can run +If you want to pull commit `e43a6` into your `master` branch, you can run: [source,console] ---- diff --git a/book/07-git-tools/sections/advanced-merging.asc b/book/07-git-tools/sections/advanced-merging.asc index 3fca09d99..79fa865ac 100644 --- a/book/07-git-tools/sections/advanced-merging.asc +++ b/book/07-git-tools/sections/advanced-merging.asc @@ -226,7 +226,7 @@ In the `ignore-space-change` merge, we actually ended up with a few lines with D If you want to get an idea before finalizing this commit about what was actually changed between one side or the other, you can ask `git diff` to compare what is in your working directory that you're about to commit as the result of the merge to any of these stages. Let's go through them all. -To compare your result to what you had in your branch before the merge, in other words, to see what the merge introduced, you can run `git diff --ours` +To compare your result to what you had in your branch before the merge, in other words, to see what the merge introduced, you can run `git diff --ours`: [source,console] ---- diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc index 68a4073d9..9583b15e3 100644 --- a/book/07-git-tools/sections/revision-selection.asc +++ b/book/07-git-tools/sections/revision-selection.asc @@ -138,7 +138,7 @@ $ git show HEAD@{5} ---- You can also use this syntax to see where a branch was some specific amount of time ago. -For instance, to see where your `master` branch was yesterday, you can type +For instance, to see where your `master` branch was yesterday, you can type: [source,console] ---- @@ -252,7 +252,7 @@ The other main ancestry specification is the `~` (tilde). This also refers to the first parent, so `HEAD~` and `HEAD^` are equivalent. The difference becomes apparent when you specify a number. `HEAD~2` means ``the first parent of the first parent,'' or ``the grandparent'' -- it traverses the first parents the number of times you specify. -For example, in the history listed earlier, `HEAD~3` would be +For example, in the history listed earlier, `HEAD~3` would be: [source,console] ---- diff --git a/book/07-git-tools/sections/rewriting-history.asc b/book/07-git-tools/sections/rewriting-history.asc index 95a37e6ef..306ff41ca 100644 --- a/book/07-git-tools/sections/rewriting-history.asc +++ b/book/07-git-tools/sections/rewriting-history.asc @@ -150,7 +150,7 @@ Once you're satisfied with your changes, run ---- These instructions tell you exactly what to do. -Type +Type: [source,console] ---- @@ -158,7 +158,7 @@ $ git commit --amend ---- Change the commit message, and exit the editor. -Then, run +Then, run: [source,console] ---- @@ -172,7 +172,7 @@ Each time, Git will stop, let you amend the commit, and continue when you're fin ==== Reordering Commits You can also use interactive rebases to reorder or remove commits entirely. -If you want to remove the ``added cat-file'' commit and change the order in which the other two commits are introduced, you can change the rebase script from this +If you want to remove the ``added cat-file'' commit and change the order in which the other two commits are introduced, you can change the rebase script from this: [source,console] ---- diff --git a/book/07-git-tools/sections/subtree-merges.asc b/book/07-git-tools/sections/subtree-merges.asc index 6ef0f714d..09592d209 100644 --- a/book/07-git-tools/sections/subtree-merges.asc +++ b/book/07-git-tools/sections/subtree-merges.asc @@ -95,7 +95,7 @@ Instead, you must run `git diff-tree` with the branch you want to compare to: $ git diff-tree -p rack_branch ---- -Or, to compare what is in your `rack` subdirectory with what the `master` branch on the server was the last time you fetched, you can run +Or, to compare what is in your `rack` subdirectory with what the `master` branch on the server was the last time you fetched, you can run: [source,console] ---- diff --git a/book/08-customizing-git/sections/config.asc b/book/08-customizing-git/sections/config.asc index 68a42c0a4..4a84856b8 100644 --- a/book/08-customizing-git/sections/config.asc +++ b/book/08-customizing-git/sections/config.asc @@ -37,7 +37,7 @@ It's generally easier to run the `git config` command, though. The configuration options recognized by Git fall into two categories: client-side and server-side. The majority of the options are client-side -- configuring your personal working preferences. Many, _many_ configuration options are supported, but a large fraction of them are useful only in certain edge cases; we'll cover just the most common and useful options here. -If you want to see a list of all the options your version of Git recognizes, you can run +If you want to see a list of all the options your version of Git recognizes, you can run: [source,console] ---- @@ -227,7 +227,7 @@ Each of these can be set to `true`, `false`, or `always`: color.status In addition, each of these has subsettings you can use to set specific colors for parts of the output, if you want to override each color. -For example, to set the meta information in your diff output to blue foreground, black background, and bold text, you can run +For example, to set the meta information in your diff output to blue foreground, black background, and bold text, you can run: [source,console] ---- @@ -287,7 +287,7 @@ $ sudo chmod +x /usr/local/bin/extDiff Now you can set up your config file to use your custom merge resolution and diff tools. This takes a number of custom settings: `merge.tool` to tell Git what strategy to use, `mergetool..cmd` to specify how to run the command, `mergetool..trustExitCode` to tell Git if the exit code of that program indicates a successful merge resolution or not, and `diff.external` to tell Git what command to run for diffs. -So, you can either run four config commands +So, you can either run four config commands: [source,console] ---- @@ -369,7 +369,7 @@ Some of the tools listed above only work in a windowed environment. If run in a terminal-only session, they will fail. ---- -If you're not interested in using KDiff3 for diff but rather want to use it just for merge resolution, and the kdiff3 command is in your path, then you can run +If you're not interested in using KDiff3 for diff but rather want to use it just for merge resolution, and the kdiff3 command is in your path, then you can run: [source,console] ---- diff --git a/book/08-customizing-git/sections/policy.asc b/book/08-customizing-git/sections/policy.asc index 48e759b12..a20d40d88 100644 --- a/book/08-customizing-git/sections/policy.asc +++ b/book/08-customizing-git/sections/policy.asc @@ -270,7 +270,7 @@ error: failed to push some refs to 'git@gitserver:project.git' You'll see a remote rejected message for each reference that your hook declined, and it tells you that it was declined specifically because of a hook failure. Furthermore, if someone tries to edit a file they don't have access to and push a commit containing it, they will see something similar. -For instance, if a documentation author tries to push a commit modifying something in the `lib` directory, they see +For instance, if a documentation author tries to push a commit modifying something in the `lib` directory, they see: [source,console] ---- @@ -360,7 +360,7 @@ check_directory_perms This is roughly the same script as the server-side part, but with two important differences. First, the ACL file is in a different place, because this script runs from your working directory, not from your `.git` directory. -You have to change the path to the ACL file from this +You have to change the path to the ACL file from this: [source,ruby] ---- @@ -376,14 +376,14 @@ access = get_acl_access_data('.git/acl') The other important difference is the way you get a listing of the files that have been changed. Because the server-side method looks at the log of commits, and, at this point, the commit hasn't been recorded yet, you must get your file listing from the staging area instead. -Instead of +Instead of: [source,ruby] ---- files_modified = `git log -1 --name-only --pretty=format:'' #{ref}` ---- -you have to use +you have to use: [source,ruby] ---- diff --git a/book/09-git-and-other-scms/sections/client-svn.asc b/book/09-git-and-other-scms/sections/client-svn.asc index a3e0d87fa..5ee30720a 100644 --- a/book/09-git-and-other-scms/sections/client-svn.asc +++ b/book/09-git-and-other-scms/sections/client-svn.asc @@ -58,7 +58,7 @@ $ svnsync init file:///tmp/test-svn \ ---- This sets up the properties to run the sync. -You can then clone the code by running +You can then clone the code by running: [source,console] ---- @@ -362,7 +362,7 @@ It's important to note that it doesn't check you out into that branch; if you co Git figures out what branch your dcommits go to by looking for the tip of any of your Subversion branches in your history – you should have only one, and it should be the last one with a `git-svn-id` in your current branch history. If you want to work on more than one branch simultaneously, you can set up local branches to `dcommit` to specific Subversion branches by starting them at the imported Subversion commit for that branch. -If you want an `opera` branch that you can work on separately, you can run +If you want an `opera` branch that you can work on separately, you can run: [source,console] ---- diff --git a/book/09-git-and-other-scms/sections/import-svn.asc b/book/09-git-and-other-scms/sections/import-svn.asc index f33c6ccb6..becb37df2 100644 --- a/book/09-git-and-other-scms/sections/import-svn.asc +++ b/book/09-git-and-other-scms/sections/import-svn.asc @@ -57,7 +57,7 @@ $ cd my_project ---- Now you should have a nicer Subversion import in your `my_project` directory. -Instead of commits that look like this +Instead of commits that look like this: [source] ---- diff --git a/book/10-git-internals/sections/refspec.asc b/book/10-git-internals/sections/refspec.asc index f1b411a63..f8157ce56 100644 --- a/book/10-git-internals/sections/refspec.asc +++ b/book/10-git-internals/sections/refspec.asc @@ -101,7 +101,7 @@ If you have a complex workflow process that has a QA team pushing branches, deve It's nice that you can fetch namespaced references that way, but how does the QA team get their branches into a `qa/` namespace in the first place? You accomplish that by using refspecs to push. -If the QA team wants to push their `master` branch to `qa/master` on the remote server, they can run +If the QA team wants to push their `master` branch to `qa/master` on the remote server, they can run: [source,console] ---- From 11863e740174660b07ba125174789033bced1bc0 Mon Sep 17 00:00:00 2001 From: Vipul Kumar Date: Fri, 3 Jul 2020 14:43:13 +0000 Subject: [PATCH 7/9] [Fix] add missing "this" keyword See @ben's comment on PR #1444[1]. [1]: https://github.com/progit/progit2/pull/1444#discussion_r446303558 --- book/01-introduction/sections/help.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/01-introduction/sections/help.asc b/book/01-introduction/sections/help.asc index e7169ee5d..d5331d835 100644 --- a/book/01-introduction/sections/help.asc +++ b/book/01-introduction/sections/help.asc @@ -10,7 +10,7 @@ $ git --help $ man git- ---- -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] ---- From 1283cac07fb08bc35cf0d8cd1aec1020435dba9b Mon Sep 17 00:00:00 2001 From: Vipul Kumar Date: Fri, 3 Jul 2020 14:51:58 +0000 Subject: [PATCH 8/9] [Fix] use monospace font for "upstream" keyword See @ben's comment on PR #1444[1]. [1]: https://github.com/progit/progit2/pull/1444/files/20ec785536bb526e16dc0de8fb7ad1fe2635049c#r446307067 --- book/06-github/sections/2-contributing.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index df9cbf915..cfec4c793 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -270,7 +270,7 @@ To https://github.com/tonychacon/blink ef4725c..3c8d735 slower-blink -> slow-blink ---- -<1> Add the original repository as a remote named ``upstream''. +<1> Add the original repository as a remote named `upstream`. <2> Fetch the newest work from that remote. <3> Merge the main branch of that repository into your topic branch. <4> Fix the conflict that occurred. From e98c6518d0204c7fa31402134afef12ecd0009b0 Mon Sep 17 00:00:00 2001 From: Vipul Kumar Date: Fri, 3 Jul 2020 15:12:27 +0000 Subject: [PATCH 9/9] [Fix] add missing double quote around "Home" keyword Double quote around "Home" keyword is missing in square bracket, but present in figure caption, see @Morganov's comment on PR #1444[1]. [1]: https://github.com/progit/progit2/pull/1444#discussion_r446494854 --- book/A-git-in-other-environments/sections/visualstudio.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/A-git-in-other-environments/sections/visualstudio.asc b/book/A-git-in-other-environments/sections/visualstudio.asc index a4f098672..22a77f087 100644 --- a/book/A-git-in-other-environments/sections/visualstudio.asc +++ b/book/A-git-in-other-environments/sections/visualstudio.asc @@ -18,7 +18,7 @@ This is a hub for performing Git actions; when you're _writing_ code, you'll pro [[vs_home]] .The "Home" view for a Git repository in Visual Studio -image::images/vs-2.png[The Home view for a Git repository in Visual Studio] +image::images/vs-2.png[The ``Home'' view for a Git repository in Visual Studio] Visual Studio now has a powerful task-focused UI for Git. It includes a linear history view, a diff viewer, remote commands, and many other capabilities.