Fixes

C-git-commands.asc

@@ -39,17 +39,17 @@
 
 В разделе <<ch08-customizing-git#r_keyword_expansion>> главы 7 мы показали как настроить фильтры содержимого для данных, перемещаемых между индексом и рабочей копией.
 
-И наконец, этой команде посвящен практически весь раздел <<ch08-customizing-git#r_git_config>> главы 8.
+И наконец, этой команде посвящён практически весь раздел <<ch08-customizing-git#r_git_config>> главы 8.
 
 [[r_core_editor]]
 ==== Команды git config core.editor
 
 Согласно инструкциям, приведённым в разделе <<ch01-getting-started#r_editor>> главы 1, большинство редакторов может быть установлено следующим образом:
 
 .Исчерпывающий список команд по настройке `core.editor`
-[cols="1,2",options="header"]
+[cols="^.^1,2",options="header"]
 |==============================
-|Редактор | Команда
+|Редактор ^.^| Команда
 |Atom |`git config --global core.editor "atom --wait"`
 |BBEdit (Mac, with command line tools) |`git config --global core.editor "bbedit -w"`
 |Emacs |`git config --global core.editor emacs`
@@ -309,7 +309,7 @@
 
 Мы познакомились и разобрались с ней в разделе <<ch02-git-basics-chapter#r_git_tagging>> главы 2 и использовали на практике в разделе <<ch05-distributed-git#r_tagging_releases>> главы 5.
 
-Мы научились создавать подписанные с помощью GPG метки, используя флаг `-s`, и проверять их, используя флаг `-v`, в разделе <<ch07-git-tools#r_signing>> главы 7.
+Мы научились создавать подписанные с помощью GPG теги, используя флаг `-s`, и проверять их, используя флаг `-v`, в разделе <<ch07-git-tools#r_signing>> главы 7.
 
 
 === Совместная работа и обновление проектов
@@ -389,9 +389,9 @@
 ==== git show
 
 Команда `git show` отображает объект в простом и человекопонятном виде.
-Обычно она используется для просмотра информации о метке или коммите.
+Обычно она используется для просмотра информации о теге или коммите.
 
-Впервые мы использовали её для просмотра информации об аннотированной метке в разделе <<ch02-git-basics-chapter#r_annotated_tags>> главы 2.
+Впервые мы использовали её для просмотра информации об аннотированном теге в разделе <<ch02-git-basics-chapter#r_annotated_tags>> главы 2.
 
 В разделе <<ch07-git-tools#r_revision_selection>> главы 7 мы использовали её для показа коммитов, подпадающих под различные селекторы диапазонов.
 

TRANSLATION_NOTES.asc

@@ -14,7 +14,7 @@
 Каждая из глав имеет такую структуру:
 
     Название главы
-    Краткое описание о чем пойдёт речь
+    Краткое описание о чём пойдёт речь
     Собственно, содержимое
     Заключение (Summary)
 
@@ -62,6 +62,8 @@ stashed -- припрятано, припрятали
 === Working Directory → рабочий каталог
 Каталог файловой системы, содержащий рабочую копию.
 
+=== Pull Request → запрос на слияние
+
 === Кавычки
 В тексте книги следует использовать кавычки «ёлочки» во всех случаях, за исключением ситуации, когда слово или фраза в кавычках входит в состав другой фразы заключённой в кавычки.
 Например: «Фраза с „выделенным“ словом­­».

attributes.asc

@@ -6,3 +6,4 @@ ifdef::lang[include::attributes-{lang}.adoc[]]
 :icons: font
 :toc:
 :toclevels: 2
+:experimental:

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

@@ -22,7 +22,6 @@
 
 В системах семейства Windows Git ищет файл `.gitconfig` в каталоге `$HOME` (`C:\Users\$USER` для большинства пользователей).
 Кроме того, Git ищет файл `[path]/etc/gitconfig`, но уже относительно корневого каталога MSys, который находится там, куда вы решили установить Git при запуске инсталлятора.
-
 Если вы используете Git для Windows версии 2.х или новее, то так же обрабатывается файл конфигурации уровня системы, который имеет путь `C:\Documents and Settings\All Users\Application Data\Git\config` в Windows XP или `C:\ProgramData\Git\config` в Windows Vista и новее.
 Этот файл может быть изменён только командой `git config -f <file>`, запущенной с правами администратора.
 
@@ -113,7 +112,7 @@ color.diff=auto
 ...
 ----
 
-Некоторые ключи (названия) настроек могут отображаться несколько раз, потому что Git читает настройки из разных файлов (например, из `/etc/gitconfig` и `~/.gitconfig`).
+Некоторые ключи (названия) настроек могут отображаться несколько раз, потому что Git читает настройки из разных файлов (например, из `[path]/etc/gitconfig` и `~/.gitconfig`).
 В таком случае Git использует последнее значение для каждого ключа.
 
 Также вы можете проверить значение конкретного ключа, выполнив `git config <key>`:(((команды git, config)))

book/01-introduction/sections/help.asc

@@ -18,7 +18,7 @@ $ git help config
 ----
 
 Эти команды хороши тем, что ими можно пользоваться всегда, даже без подключения к сети.
-Если руководства и этой книги недостаточно и вам нужна персональная помощь, вы можете попытаться поискать её на каналах `#git` и `#github` IRC сервера Libera Chat, который доступен по адресу https://libera.chat/[^].
+Если руководства и этой книги недостаточно и вам нужна персональная помощь, вы можете попытаться поискать её на каналах `#git`, `#github` или `#gitlab` IRC сервера Libera Chat, который доступен по адресу https://libera.chat/[^].
 Обычно там сотни людей, отлично знающих Git, которые могут помочь.(((IRC)))
 
 Так же, если вам нужно посмотреть только список опций и вы не хотите читать полную документацию по команде, вы можете использовать опцию `-h` для вывода краткой инструкции по использованию:

book/01-introduction/sections/installing.asc

@@ -113,7 +113,7 @@ $ sudo ln -s /usr/bin/db2x_docbook2texi /usr/bin/docbook2x-texi
 ----
 
 Когда все необходимые зависимости установлены, вы можете пойти дальше и скачать самый свежий архив с исходниками из следующих мест:
-с сайта Kernel.org https://www.kernel.org/pub/software/scm/git[^], или зеркала на сайте GitHub https://github.com/git/git/releases[^].
+с сайта Kernel.org https://www.kernel.org/pub/software/scm/git[^], или зеркала на сайте GitHub https://github.com/git/git/tags[^].
 Конечно, немного проще скачать последнюю версию с сайта GitHub, но на странице kernel.org релизы имеют подписи, если вы хотите проверить, что скачиваете.
 
 Затем скомпилируйте и установите:

book/02-git-basics/sections/getting-a-repository.asc

@@ -41,7 +41,7 @@ $ git init
 Подробное описание файлов, содержащихся в только что созданном вами каталоге `.git`, приведено в главе <<ch10-git-internals#ch10-git-internals>>(((команды git, init)))
 
 Если вы хотите добавить под версионный контроль существующие файлы (в отличие от пустого каталога), вам стоит добавить их в индекс и осуществить первый коммит изменений.
-Добиться этого вы сможете запустив команду `git add` несколько раз, указав индексируемые файлы, а затем выполнив `git commit`: 
+Добиться этого вы сможете запустив команду `git add` несколько раз, указав индексируемые файлы, а затем выполнив `git commit`:
 
 [source,console]
 ----
@@ -50,7 +50,7 @@ $ git add LICENSE
 $ git commit -m 'Initial project version'
 ----
 
-Мы разберем, что делают эти команды чуть позже.
+Мы разберём, что делают эти команды чуть позже.
 Теперь у вас есть Git-репозиторий с отслеживаемыми файлами и начальным коммитом.
 
 [[r_git_cloning]]
@@ -72,6 +72,7 @@ $ git clone https://github.com/libgit2/libgit2
 
 Эта команда создаёт каталог `libgit2`, инициализирует в нём подкаталог `.git`, скачивает все данные для этого репозитория и извлекает рабочую копию последней версии.
 Если вы перейдёте в только что созданный каталог `libgit2`, то увидите в нём файлы проекта, готовые для работы или использования.
+
 Для того, чтобы клонировать репозиторий в каталог с именем, отличающимся от `libgit2`, необходимо указать желаемое имя, как параметр командной строки:
 
 [source,console]

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

@@ -1,14 +1,14 @@
 === Запись изменений в репозиторий
 
-Итак, у вас имеется настоящий Git-репозиторий и рабочая копия файлов для некоторого проекта.
+Итак, у вас имеется _настоящий_ Git-репозиторий и _рабочая копия_ файлов для некоторого проекта.
 Вам нужно делать некоторые изменения и фиксировать «снимки» состояния (snapshots) этих изменений в вашем репозитории каждый раз, когда проект достигает состояния, которое вам хотелось бы сохранить.
 
-Запомните, каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем (отслеживаемые) и нет (неотслеживаемые).
+Запомните, каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем (_отслеживаемые_) и нет (_неотслеживаемые_).
 Отслеживаемые файлы -- это те файлы, которые были в последнем снимке состояния проекта; они могут быть неизменёнными, изменёнными или подготовленными к коммиту.
 Если кратко, то отслеживаемые файлы -- это те файлы, о которых знает Git.
 
 Неотслеживаемые файлы -- это всё остальное, любые файлы в вашем рабочем каталоге, которые не входили в ваш последний снимок состояния и не подготовлены к коммиту.
-Когда вы впервые клонируете репозиторий, все файлы будут отслеживаемыми и неизменёнными, потому что Git только что их извлек и вы ничего пока не редактировали.
+Когда вы впервые клонируете репозиторий, все файлы будут отслеживаемыми и неизменёнными, потому что Git только что их извлёк и вы ничего пока не редактировали.
 
 Как только вы отредактируете файлы, Git будет рассматривать их как изменённые, так как вы изменили их с момента последнего коммита.
 Вы индексируете эти изменения, затем фиксируете все проиндексированные изменения, а затем цикл повторяется.
@@ -41,6 +41,7 @@ Git также не обнаружил неотслеживаемых файло
 В 2020 году GitHub изменил имя ветки по умолчанию с `master` на `main`, другие же git-хостинг платформы последовали этому примеру.
 Поэтому, вы можете обнаружить, что ветка по умолчанию для новых репозиториев -- `main`, а не `master`.
 Более того, имя ветки по умолчанию можно изменить (как вы видели в <<ch01-getting-started#ru_new_default_branch>>), поэтому вам может встретиться и другое имя.
+
 При этом Git продолжает использовать имя `master`, поэтому далее в книге мы используем именно его.
 ====
 
@@ -64,7 +65,7 @@ nothing added to commit but untracked files present (use "git add" to track)
 Понять, что новый файл `README` неотслеживаемый можно по тому, что он находится в секции «Untracked files» в выводе команды `status`.
 Статус `Untracked` означает, что Git видит файл, которого не было в предыдущем снимке состояния (коммите); Git не станет добавлять его в ваши коммиты, пока вы его явно об этом не попросите.
 Это предохранит вас от случайного добавления в репозиторий сгенерированных бинарных файлов или каких-либо других, которые вы и не думали добавлять.
-Мы хотели добавить README, так давайте сделаем это.
+Мы хотели добавить `README`, так давайте сделаем это.
 
 [[r_tracking_files]]
 ==== Отслеживание новых файлов
@@ -168,7 +169,7 @@ Changes not staged for commit:
 Теперь `CONTRIBUTING.md` отображается как проиндексированный и непроиндексированный одновременно.
 Как такое возможно?
 Такая ситуация наглядно демонстрирует, что Git индексирует файл в точности в том состоянии, в котором он находился, когда вы выполнили команду  `git add`.
-Если вы выполните коммит сейчас, то файл `CONTRIBUTING.md` попадёт в коммит в том состоянии, в котором он находился, когда вы последний раз выполняли команду `git add` , а не в том, в котором он находится в вашем рабочем каталоге в момент выполнения `git commit`.
+Если вы выполните коммит сейчас, то файл `CONTRIBUTING.md` попадёт в коммит в том состоянии, в котором он находился, когда вы последний раз выполняли команду `git add`, а не в том, в котором он находится в вашем рабочем каталоге в момент выполнения `git commit`.
 Если вы изменили файл после выполнения `git add`, вам придётся снова выполнить `git add`, чтобы проиндексировать последнюю версию файла:
 
 [source,console]

book/02-git-basics/sections/remotes.asc

@@ -230,7 +230,7 @@ paul
 Стоит упомянуть, что это также изменит имена удалённых веток в вашем репозитории.
 То, к чему вы обращались как `pb/master`, теперь стало `paul/master`.
 
-Если по какой-то причине вы хотите удалить удалённый репозиторий -- вы сменили сервер или больше не используете определённое зеркало, или кто-то перестал вносить изменения -- вы можете использовать `git remote rm`:
+Если по какой-то причине вы хотите удалить удалённый репозиторий -- вы сменили сервер или больше не используете определённое зеркало, или кто-то перестал вносить изменения -- вы можете использовать `git remote remove` или `git remote rm`:
 
 [source,console]
 ----