progit · Morganov · Sep 9, 2024 · Feb 1, 2024 · Sep 9, 2024
diff --git a/C-git-commands.asc b/C-git-commands.asc
@@ -39,7 +39,7 @@
 
 В разделе <<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

diff --git a/TRANSLATION_NOTES.asc b/TRANSLATION_NOTES.asc
@@ -14,7 +14,7 @@
 Каждая из глав имеет такую структуру:
 
  Название главы
- Краткое описание о чем пойдёт речь
+ Краткое описание о чём пойдёт речь
  Собственно, содержимое
  Заключение (Summary)
 

diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc
@@ -50,7 +50,7 @@ $ git add LICENSE
 $ git commit -m 'Initial project version'
 ----
 
-Мы разберем, что делают эти команды чуть позже.
+Мы разберём, что делают эти команды чуть позже.
 Теперь у вас есть Git-репозиторий с отслеживаемыми файлами и начальным коммитом.
 
 [[r_git_cloning]]

diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc
@@ -8,7 +8,7 @@
 Если кратко, то отслеживаемые файлы -- это те файлы, о которых знает Git.
 
 Неотслеживаемые файлы -- это всё остальное, любые файлы в вашем рабочем каталоге, которые не входили в ваш последний снимок состояния и не подготовлены к коммиту.
-Когда вы впервые клонируете репозиторий, все файлы будут отслеживаемыми и неизменёнными, потому что Git только что их извлек и вы ничего пока не редактировали.
+Когда вы впервые клонируете репозиторий, все файлы будут отслеживаемыми и неизменёнными, потому что Git только что их извлёк и вы ничего пока не редактировали.
 
 Как только вы отредактируете файлы, Git будет рассматривать их как изменённые, так как вы изменили их с момента последнего коммита.
 Вы индексируете эти изменения, затем фиксируете все проиндексированные изменения, а затем цикл повторяется.

diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc
@@ -202,7 +202,7 @@ To [email protected]:schacon/simplegit.git
  * [new tag] v1.5 -> v1.5
 ----
 
-Если у вас много тегов, и вам хотелось бы отправить все за один раз, то можно использовать опцию `--tags` для команды `git push`.
+Если у вас много тегов, и вам хотелось бы отправить всё за один раз, то можно использовать опцию `--tags` для команды `git push`.
 В таком случае все ваши теги отправятся на удалённый сервер (если только их уже там нет).
 
 [source,console]
@@ -222,7 +222,7 @@ To [email protected]:schacon/simplegit.git
 .`git push` отправляет оба типа тегов
 ====
 Отправка тегов командой `git push <remote> --tags` не различает аннотированные и легковесные теги.
-В настоящее время не существует опции чтобы отправить только лёгковесные теги, но если использовать команду `git push <remote> --follow-tags`, то отправятся только аннотированные теги.
+В настоящее время не существует опции чтобы отправить только легковесные теги, но если использовать команду `git push <remote> --follow-tags`, то отправятся только аннотированные теги.
 ====
 
 ==== Удаление тегов
@@ -298,4 +298,4 @@ $ git checkout -b version2 v2.0.0
 Switched to a new branch 'version2'
 ----
 
-Если сделать коммит в ветке `version2`, то она сдвинется вперед и будет отличаться от тега `v2.0.0`, так что будьте с этим осторожны.
+Если сделать коммит в ветке `version2`, то она сдвинется вперёд и будет отличаться от тега `v2.0.0`, так что будьте с этим осторожны.
diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc
@@ -193,7 +193,7 @@ Changes not staged for commit:
 
 ===== Откат изменённого файла с помощью git restore
 
-Что, если вы поймете, что не хотите сохранять изменения в файле `CONTRIBUTING.md`?
+Что, если вы поймёте, что не хотите сохранять изменения в файле `CONTRIBUTING.md`?
 Как легко его откатить -- вернуть обратно к тому, как он выглядел при последнем коммите (или изначально клонирован, или каким-либо образом помещён в рабочий каталог)?
 К счастью, `git status` тоже говорит, как это сделать.
 В выводе последнего примера, неиндексированная область выглядит следующим образом:

diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc
@@ -145,7 +145,7 @@ a11bef06a3f659402fe7563abf99ad00de2209e6 Initial commit
 ----
 
 Наиболее интересной опцией является `format`, которая позволяет указать формат для вывода информации.
-Особенно это может быть полезным когда вы хотите сгенерировать вывод для автоматического анализа -- так как вы указываете формат явно, он не будет изменен даже после обновления Git:(((форматирование журнала)))
+Особенно это может быть полезным когда вы хотите сгенерировать вывод для автоматического анализа -- так как вы указываете формат явно, он не будет изменён даже после обновления Git:(((форматирование журнала)))
 
 [source,console]
 ----
@@ -242,7 +242,7 @@ $ git log --since=2.weeks
 Это команда работает с большим количеством форматов -- вы можете указать определённую дату вида `2008-01-15` или же относительную дату, например `2 years 1 day 3 minutes ago`.
 
 Также вы можете фильтровать список коммитов по заданным параметрам.
-Опция `--author` дает возможность фильтровать по автору коммита, а опция `--grep` искать по ключевым словам в сообщении коммита.
+Опция `--author` даёт возможность фильтровать по автору коммита, а опция `--grep` искать по ключевым словам в сообщении коммита.
 
 [NOTE]
 ====

diff --git a/book/03-git-branching/sections/basic-branching-and-merging.asc b/book/03-git-branching/sections/basic-branching-and-merging.asc
@@ -4,7 +4,7 @@
 Ваша работа построена так:
 
 . Вы работаете над сайтом.
-. Вы создаете ветку для реализации новой функциональности в соответствии с пользовательской историей.
+. Вы создаёте ветку для реализации новой функциональности в соответствии с пользовательской историей.
 . Вы работаете в этой ветке.
 
 В этот момент вы получаете сообщение, что обнаружена критическая ошибка, требующая скорейшего исправления.
@@ -45,20 +45,20 @@ $ git checkout iss53
 image::images/basic-branching-2.png["Создание нового указателя ветки"]
 
 Вы работаете над сайтом и делаете коммиты.
-Это приводит к тому, что ветка `iss53` движется вперед, так как вы переключились на неё ранее (`HEAD` указывает на неё).
+Это приводит к тому, что ветка `iss53` движется вперёд, так как вы переключились на неё ранее (`HEAD` указывает на неё).
 
 [source,console]
 ----
 $ vim index.html
 $ git commit -a -m 'Create new footer [issue 53]'
 ----
 
-.Ветка iss53 движется вперед 
-image::images/basic-branching-3.png["Ветка iss53 двигается вперед"]
+.Ветка iss53 движется вперёд 
+image::images/basic-branching-3.png["Ветка iss53 двигается вперёд"]
 
 И тут вы получаете сообщение об обнаружении на сайте уязвимости, и эту уязвимость устранить нужно немедленно.
 Благодаря Git вам не придётся ни пытаться реализовать исправление вместе с изменениями, которые вы сделали в ходе разработки `iss53`, ни прилагать усилия для отката этих изменений и возвращения к исходному состоянию перед началом разработки исправления. 
-Все, что вам нужно -- переключиться на ветку `master`.
+Всё, что вам нужно -- переключиться на ветку `master`.
 
 Имейте в виду, что если рабочий каталог или индекс содержат незафиксированные изменения, конфликтующие с веткой, на которую вы хотите переключиться, то Git не позволит переключить ветки.
 Лучше всего переключаться из чистого рабочего состояния проекта: все изменённые файлы добавить в индекс и сделать коммит.
@@ -106,8 +106,8 @@ Fast-forward
 ----
 
 Заметили фразу «fast-forward» в этом слиянии?
-Git просто переместил указатель ветки вперед, потому что коммит `C4`, на который указывает слитая ветка `hotfix`, был прямым потомком коммита `C2`, на котором вы находились до этого.
-Другими словами, если коммит сливается с тем, до которого можно добраться, двигаясь по истории вперёд, Git упрощает слияние, просто перенося указатель ветки вперед, потому что в этом случае нет никаких разнонаправленных изменений, которые нужно было бы свести воедино.
+Git просто переместил указатель ветки вперёд, потому что коммит `C4`, на который указывает слитая ветка `hotfix`, был прямым потомком коммита `C2`, на котором вы находились до этого.
+Другими словами, если коммит сливается с тем, до которого можно добраться, двигаясь по истории вперёд, Git упрощает слияние, просто перенося указатель ветки вперёд, потому что в этом случае нет никаких разнонаправленных изменений, которые нужно было бы свести воедино.
 Это называется «fast-forward».
 
 Теперь ваши изменения включены в коммит, на который указывает ветка `master`, и исправление можно внедрять.
@@ -149,7 +149,7 @@ image::images/basic-branching-6.png["Продолжение работы над
 (((ветки, слияние)))(((слияние)))
 Предположим, вы решили, что работа по проблеме #53 закончена и её можно влить в ветку `master`.
 Для этого нужно выполнить слияние ветки `iss53` точно так же, как вы делали это с веткой `hotfix` ранее.
-Все, что нужно сделать -- переключиться на ветку, в которую вы хотите включить изменения, и выполнить команду `git merge`:
+Всё, что нужно сделать -- переключиться на ветку, в которую вы хотите включить изменения, и выполнить команду `git merge`:
 
 [source,console]
 ----
@@ -248,7 +248,7 @@ please contact us at [email protected]
 Разрешив каждый конфликт во всех файлах, запустите `git add` для каждого файла, чтобы отметить конфликт как решённый.
 Добавление файла в индекс означает для Git, что все конфликты в нём исправлены.
 
-Если вы хотите использовать графический инструмент для разрешения конфликтов, можно запустить `git mergetool`, который проведет вас по всем конфликтам:(((команды git, mergetool)))
+Если вы хотите использовать графический инструмент для разрешения конфликтов, можно запустить `git mergetool`, который проведёт вас по всем конфликтам:(((команды git, mergetool)))
 
 [source,console]
 ----

diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc
@@ -58,7 +58,7 @@ image::images/basic-rebase-4.png["Перемотка ветки `master`"]
 Тогда владельцу проекта не придётся делать никакой лишней работы -- всё решится простой перемоткой или бесконфликтным слиянием.
 
 Учтите, что снимок, на который ссылается ваш последний коммит -- является ли он последним коммитом после перебазирования или коммитом слияния после слияния -- в обоих случаях это один и тот же снимок, отличаются только истории коммитов.
-Перебазирование повторяет изменения из одной ветки поверх другой в том порядке, в котором эти изменения были сделаны, в то время как слияние берет две конечные точки и сливает их вместе.
+Перебазирование повторяет изменения из одной ветки поверх другой в том порядке, в котором эти изменения были сделаны, в то время как слияние берёт две конечные точки и сливает их вместе.
 
 ==== Более интересные перемещения
 

diff --git a/book/04-git-server/sections/gitlab.asc b/book/04-git-server/sections/gitlab.asc
@@ -44,10 +44,10 @@ image::images/gitlab-menu.png["Пункт «Административная з
 image::images/gitlab-users.png["Экран управления пользователями GitLab"]
 
 Удаление пользователя может быть выполнено двумя способами.
-«Блокирование» («Blocking») пользователя запрещает ему вход в GitLab, но все данные в его пространстве имен сохраняются, и коммиты, подписанные этим пользователем, будут указывать на его профиль.
+«Блокирование» («Blocking») пользователя запрещает ему вход в GitLab, но все данные в его пространстве имён сохраняются, и коммиты, подписанные этим пользователем, будут указывать на его профиль.
 
 «Разрушение» («Destroying») пользователя, с другой стороны, полностью удаляет его из базы данных и файловой системы.
-Все проекты и данные в его пространстве имен удаляются, как и все принадлежащие ему группы.
+Все проекты и данные в его пространстве имён удаляются, как и все принадлежащие ему группы.
 Конечно, этим более постоянным и разрушительным действием пользуются реже.
 
 [[r_gitlab_groups_section]]

diff --git a/book/04-git-server/sections/hosted.asc b/book/04-git-server/sections/hosted.asc
@@ -5,6 +5,6 @@
 Даже если вы установили и запустили свой собственный внутренний сервер, возможно, вы захотите использовать сайт на публичном хостинге для ваших проектов с открытым кодом -- так сообществу будет проще вас найти и помочь.
 
 В наши дни у вас есть огромный выбор вариантов хостинга, каждый из которых имеет свои преимущества и недостатки.
-Актуальный список приведен в главной вики Git на странице GitHosting: https://git.wiki.kernel.org/index.php/GitHosting[^]
+Актуальный список приведён в главной вики Git на странице GitHosting: https://git.wiki.kernel.org/index.php/GitHosting[^]
 
 Мы детально рассмотрим GitHub в главе <<ch06-github#ch06-github>>, так как это крупнейший Git-хостинг и вам скорее всего понадобится взаимодействовать с проектами, хостящимися на нём; при этом существуют десятки других, что делает необязательным использование собственного сервера.