[WIP] Atualizações do texto original

A-git-in-other-environments.asc

@@ -1,4 +1,4 @@
-[#A-git-in-other-environments]
+[[A-git-in-other-environments]]
 [appendix]
 == Git em Outros Ambientes
 
@@ -13,6 +13,11 @@ include::book/A-git-in-other-environments/sections/visualstudio.asc[]
 
 include::book/A-git-in-other-environments/sections/eclipse.asc[]
 
+include::book/A-git-in-other-environments/sections/visualstudiocode.asc[]
+
+include::book/A-git-in-other-environments/sections/jetbrainsides.asc[]
+
+include::book/A-git-in-other-environments/sections/sublimetext.asc[]
 
 include::book/A-git-in-other-environments/sections/bash.asc[]
 

B-embedding-git.asc → B-embedding-git-in-your-applications.asc

@@ -1,14 +1,19 @@
-[#B-embedding-git]
+[[B-embedding-git-in-your-applications]]
 [appendix]
 == Embedding Git in your Applications
 
 If your application is for developers, chances are good that it could benefit from integration with source control.
 Even non-developer applications, such as document editors, could potentially benefit from version-control features, and Git's model works very well for many different scenarios.
 
-If you need to integrate Git with your application, you have essentially three choices: spawning a shell and using the Git command-line tool; Libgit2; and JGit.
+If you need to integrate Git with your application, you have essentially two options: spawn a shell and call the `git` command-line program, or embed a Git library into your application.
+Here we'll cover command-line integration and several of the most popular embeddable Git libraries.
 
 include::book/B-embedding-git/sections/command-line.asc[]
 
 include::book/B-embedding-git/sections/libgit2.asc[]
 
 include::book/B-embedding-git/sections/jgit.asc[]
+
+include::book/B-embedding-git/sections/go-git.asc[]
+
+include::book/B-embedding-git/sections/dulwich.asc[]

book-en/01-introduction/sections/about-version-control.asc

@@ -19,21 +19,21 @@ It is easy to forget which directory you're in and accidentally write to the wro
 
 To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control.
 
-.Local version control
+.Local version control diagram
 image::images/local.png[Local version control diagram]
 
 One of the most popular VCS tools was a system called RCS, which is still distributed with many computers today.
-https://www.gnu.org/software/rcs/[RCS] works by keeping patch sets (that is, the differences between files) in a special format on disk; it can then re-create what any file looked like at any point in time by adding up all the patches.
+https://www.gnu.org/software/rcs/[RCS^] works by keeping patch sets (that is, the differences between files) in a special format on disk; it can then re-create what any file looked like at any point in time by adding up all the patches.
 
 ==== Centralized Version Control Systems
 
 (((version control,centralized)))
 The next major issue that people encounter is that they need to collaborate with developers on other systems.
 To deal with this problem, Centralized Version Control Systems (CVCSs) were developed.
-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)))
+These systems (such as CVS, Subversion, and Perforce) have a single server that contains all the versioned files, and a number of clients that check out files from that central place.(((CVS)))(((Subversion)))(((Perforce)))
 For many years, this has been the standard for version control.
 
-.Centralized version control
+.Centralized version control diagram
 image::images/centralized.png[Centralized version control diagram]
 
 This setup offers many advantages, especially over local VCSs.
@@ -50,11 +50,11 @@ Local VCSs suffer from this same problem -- whenever you have the entire history
 
 (((version control,distributed)))
 This is where Distributed Version Control Systems (DVCSs) step in.
-In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don't just check out the latest snapshot of the files; rather, they fully mirror the repository, including its full history.
+In a DVCS (such as Git, Mercurial or Darcs), clients don't just check out the latest snapshot of the files; rather, they fully mirror the repository, including its full history.
 Thus, if any server dies, and these systems were collaborating via that server, any of the client repositories can be copied back up to the server to restore it.
 Every clone is really a full backup of all the data.
 
-.Distributed version control
+.Distributed version control diagram
 image::images/distributed.png[Distributed version control diagram]
 
 Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project.

book-en/01-introduction/sections/first-time-setup.asc

@@ -21,8 +21,7 @@ Each level overrides values in the previous level, so values in `.git/config` tr
 
 On Windows systems, Git looks for the `.gitconfig` file in the `$HOME` directory (`C:\Users\$USER` for most people).
 It also still looks for `[path]/etc/gitconfig`, although it's relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer.
-If you are using version 2.x or later of Git for Windows, there is also a system-level config file at
-`C:\Documents and Settings\All Users\Application Data\Git\config` on Windows XP, and in `C:\ProgramData\Git\config` on Windows Vista and newer.
+If you are using version 2.x or later of Git for Windows, there is also a system-level config file at `C:\Documents and Settings\All Users\Application Data\Git\config` on Windows XP, and in `C:\ProgramData\Git\config` on Windows Vista and newer.
 This config file can only be changed by `git config -f <file>` as an admin.
 
 You can view all of your settings and where they are coming from using:
@@ -43,7 +42,7 @@ $ git config --global user.name "John Doe"
 $ git config --global user.email johndoe@example.com
 ----
 
-Again, you need to do this only once if you pass the `--global` option, because then Git will always use that information for anything you do on that system.
+Again, you need to do this only once if you pass the `--global` option, because then Git will always use that information for your user on that system.
 If you want to override this with a different name or email address for specific projects, you can run the command without the `--global` option when you're in that project.
 
 Many of the GUI tools will help you do this when you first run them.
@@ -84,6 +83,7 @@ You may find, if you don't setup your editor like this, you get into a really co
 An example on a Windows system may include a prematurely terminated Git operation during a Git initiated edit.
 ====
 
+[[_new_default_branch]]
 ==== Your default branch name
 
 By default Git will create a branch called _master_ when you create a new repository with `git init`.

book-en/01-introduction/sections/help.asc

@@ -18,7 +18,7 @@ $ git help config
 ----
 
 These commands are nice because you can access them anywhere, even offline.
-If the manpages and this book aren't enough and you need in-person help, you can try the `#git`, `#github`, or `#gitlab` channels on the Libera Chat IRC server, which can be found at https://libera.chat/[].
+If the manpages and this book aren't enough and you need in-person help, you can try the `#git`, `#github`, or `#gitlab` channels on the Libera Chat IRC server, which can be found at https://libera.chat/[^].
 These channels are regularly filled with hundreds of people who are all very knowledgeable about Git and are often willing to help.(((IRC)))
 
 In addition, if you don't need the full-blown manpage help, but just need a quick refresher on the available options for a Git command, you can ask for the more concise "`help`" output with the `-h` option, as in:
@@ -43,8 +43,8 @@ usage: git add [<options>] [--] <pathspec>...
     --refresh                   don't add, only refresh the index
     --ignore-errors             just skip files which cannot be added because of errors
     --ignore-missing            check if - even missing - files are ignored in dry run
+    --sparse                    allow updating entries outside of the sparse-checkout cone
     --chmod (+|-)x              override the executable bit of the listed files
     --pathspec-from-file <file> read pathspec from file
     --pathspec-file-nul         with --pathspec-from-file, pathspec elements are separated with NUL character
 ----
-

book-en/01-introduction/sections/history.asc

@@ -10,11 +10,11 @@ In 2005, the relationship between the community that developed the Linux kernel
 This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper.(((Linus Torvalds)))
 Some of the goals of the new system were as follows:
 
-*  Speed
-*  Simple design
-*  Strong support for non-linear development (thousands of parallel branches)
-*  Fully distributed
-*  Able to handle large projects like the Linux kernel efficiently (speed and data size)
+* Speed
+* Simple design
+* Strong support for non-linear development (thousands of parallel branches)
+* Fully distributed
+* Able to handle large projects like the Linux kernel efficiently (speed and data size)
 
 Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities.
-It's amazingly fast, it's very efficient with large projects, and it has an incredible branching system for non-linear development (See <<ch03-git-branching#ch03-git-branching>>).
+It's amazingly fast, it's very efficient with large projects, and it has an incredible branching system for non-linear development (see <<ch03-git-branching#ch03-git-branching>>).

book-en/01-introduction/sections/installing.asc

@@ -6,9 +6,9 @@ You can either install it as a package or via another installer, or download the
 
 [NOTE]
 ====
-This book was written using Git version *2.8.0*.
-Though most of the commands we use should work even in ancient versions of Git, some of them might not or might act slightly differently if you're using an older version.
-Since Git is quite excellent at preserving backwards compatibility, any version after 2.8 should work just fine.
+This book was written using Git version 2.
+Since Git is quite excellent at preserving backwards compatibility, any recent version should work just fine.
+Though most of the commands we use should work even in ancient versions of Git, some of them might not or might act slightly differently.
 ====
 
 ==== Installing on Linux
@@ -29,12 +29,12 @@ If you're on a Debian-based distribution, such as Ubuntu, try `apt`:
 $ sudo apt install git-all
 ----
 
-For more options, there are instructions for installing on several different Unix distributions on the Git website, at https://git-scm.com/download/linux[].
+For more options, there are instructions for installing on several different Unix distributions on the Git website, at https://git-scm.com/download/linux[^].
 
 ==== Installing on macOS
 
 (((macOS, installing)))
-There are several ways to install Git on a Mac.
+There are several ways to install Git on macOS.
 The easiest is probably to install the Xcode Command Line Tools.(((Xcode)))
 On Mavericks (10.9) or above you can do this simply by trying to run `git` from the Terminal the very first time.
 
@@ -46,19 +46,19 @@ $ git --version
 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[].
+A macOS Git installer is maintained and available for download at the Git website, at https://git-scm.com/download/mac[^].
 
-.Git macOS Installer
+.Git macOS installer
 image::images/git-osx-installer.png[Git macOS installer]
 
 ==== Installing on Windows
 
 There are also a few ways to install Git on Windows.(((Windows, installing)))
 The most official build is available for download on the Git website.
-Just go to https://git-scm.com/download/win[] and the download will start automatically.
-Note that this is a project called Git for Windows, which is separate from Git itself; for more information on it, go to https://gitforwindows.org[].
+Just go to https://git-scm.com/download/win[^] and the download will start automatically.
+Note that this is a project called Git for Windows, which is separate from Git itself; for more information on it, go to https://gitforwindows.org[^].
 
-To get an automated installation you can use the https://chocolatey.org/packages/git[Git Chocolatey package].
+To get an automated installation you can use the https://community.chocolatey.org/packages/git[Git Chocolatey package^].
 Note that the Chocolatey package is community maintained.
 
 ==== Installing from Source
@@ -87,7 +87,7 @@ $ sudo apt-get install asciidoc xmlto docbook2x
 
 [NOTE]
 ====
-Users of RHEL and RHEL-derivatives like CentOS and Scientific Linux will have to https://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F[enable the EPEL repository] to download the `docbook2X` package.
+Users of RHEL and RHEL-derivatives like CentOS and Scientific Linux will have to https://docs.fedoraproject.org/en-US/epel/#how_can_i_use_these_extra_packages[enable the EPEL repository^] to download the `docbook2X` package.
 ====
 
 If you're using a Debian-based distribution (Debian/Ubuntu/Ubuntu-derivatives), you also need the `install-info` package:
@@ -114,7 +114,7 @@ $ sudo ln -s /usr/bin/db2x_docbook2texi /usr/bin/docbook2x-texi
 due to binary name differences.
 
 When you have all the necessary dependencies, you can go ahead and grab the latest tagged release tarball from several places.
-You can get it via the kernel.org site, at https://www.kernel.org/pub/software/scm/git[], or the mirror on the GitHub website, at https://github.com/git/git/releases[].
+You can get it via the kernel.org site, at https://www.kernel.org/pub/software/scm/git[^], or the mirror on the GitHub website, at https://github.com/git/git/tags[^].
 It's generally a little clearer what the latest version is on the GitHub page, but the kernel.org page also has release signatures if you want to verify your download.
 
 Then, compile and install:
@@ -133,5 +133,5 @@ After this is done, you can also get Git via Git itself for updates:
 
 [source,console]
 ----
-$ git clone git://git.kernel.org/pub/scm/git/git.git
+$ git clone https://git.kernel.org/pub/scm/git/git.git
 ----

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

@@ -10,7 +10,7 @@ Even though Git's user interface is fairly similar to these other VCSs, Git stor
 
 The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data.
 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).
+These other systems (CVS, Subversion, Perforce, 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]
@@ -86,7 +86,7 @@ Git has three main states that your files can reside in: _modified_, _staged_, a
 This leads us to the three main sections of a Git project: the working tree, the staging area, and the Git directory.
 
 .Working tree, staging area, and Git directory
-image::images/areas.png["Working tree, staging area, and Git directory."]
+image::images/areas.png["Working tree, staging area, and Git directory"]
 
 The working tree is a single checkout of one version of the project.
 These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify.

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

@@ -36,6 +36,15 @@ Finally, the command tells you which branch you're on and informs you that it ha
 For now, that branch is always `master`, which is the default; you won't worry about it here.
 <<ch03-git-branching#ch03-git-branching>> will go over branches and references in detail.
 
+[NOTE]
+====
+GitHub changed the default branch name from `master` to `main` in mid-2020, and other Git hosts followed suit.
+So you may find that the default branch name in some newly created repositories is `main` and not `master`.
+In addition, the default branch name can be changed (as you have seen in <<ch01-getting-started#_new_default_branch>>), so you may see a different name for the default branch.
+
+However, Git itself still uses `master` as the default, so we will use it throughout the book.
+====
+
 Let's say you add a new file to your project, a simple `README` file.
 If the file didn't exist before, and you run `git status`, you see your untracked file like so:
 
@@ -219,11 +228,11 @@ Setting up a `.gitignore` file for your new repository before you get going is g
 
 The rules for the patterns you can put in the `.gitignore` file are as follows:
 
-*  Blank lines or lines starting with `#` are ignored.
-*  Standard glob patterns work, and will be applied recursively throughout the entire working tree.
-*  You can start patterns with a forward slash (`/`) to avoid recursivity.
-*  You can end patterns with a forward slash (`/`) to specify a directory.
-*  You can negate a pattern by starting it with an exclamation point (`!`).
+* Blank lines or lines starting with `#` are ignored.
+* Standard glob patterns work, and will be applied recursively throughout the entire working tree.
+* You can start patterns with a forward slash (`/`) to avoid recursivity.
+* You can end patterns with a forward slash (`/`) to specify a directory.
+* You can negate a pattern by starting it with an exclamation point (`!`).
 
 Glob patterns are like simplified regular expressions that shells use.
 An asterisk (`\*`) matches zero or more characters; `[abc]` matches any character inside the brackets (in this case a, b, or c); a question mark (`?`) matches a single character; and brackets enclosing characters separated by a hyphen (`[0-9]`) matches any character between them (in this case 0 through 9).
@@ -254,7 +263,7 @@ doc/**/*.pdf
 
 [TIP]
 ====
-GitHub maintains a fairly comprehensive list of good `.gitignore` file examples for dozens of projects and languages at https://github.com/github/gitignore[] if you want a starting point for your project.
+GitHub maintains a fairly comprehensive list of good `.gitignore` file examples for dozens of projects and languages at https://github.com/github/gitignore[^] if you want a starting point for your project.
 ====
 
 [NOTE]
@@ -617,4 +626,4 @@ $ git add README
 
 Git figures out that it's a rename implicitly, so it doesn't matter if you rename a file that way or with the `mv` command.
 The only real difference is that `git mv` is one command instead of three -- it's a convenience function.
-More importantly, you can use any tool you like to rename a file, and address the add/rm later, before you commit.
+More importantly, you can use any tool you like to rename a file, and address the `add`/`rm` later, before you commit.