е -> ё

C-git-commands.asc

@@ -44,7 +44,7 @@
 [[r_core_editor]]
 ==== Команды git config core.editor
 
-Согласно инструкциям, приведенным в разделе <<ch01-getting-started#r_editor>> главы 1, большинство редакторов может быть установлено следующим образом:
+Согласно инструкциям, приведённым в разделе <<ch01-getting-started#r_editor>> главы 1, большинство редакторов может быть установлено следующим образом:
 
 .Исчерпывающий список команд по настройке `core.editor`
 [cols="1,2",options="header"]
@@ -444,7 +444,7 @@
 ==== git cherry-pick
 
 Команда `git cherry-pick` берёт изменения, вносимые одним коммитом, и пытается повторно применить их в виде нового коммита в текущей ветке.
-Эта возможность полезна в ситуации, когда нужно забрать парочку коммитов из другой ветки, а не сливать ветку целиком со всеми внесенными в неё изменениями.
+Эта возможность полезна в ситуации, когда нужно забрать парочку коммитов из другой ветки, а не сливать ветку целиком со всеми внесёнными в неё изменениями.
 
 Этот процесс описан и показан в разделе <<ch05-distributed-git#r_rebase_cherry_pick>> главы 5.
 

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

@@ -176,11 +176,11 @@ Changes to be committed:
  modified: CONTRIBUTING.md
 ----
 
-==== Сокращенный вывод статуса
+==== Сокращённый вывод статуса
 
 Вывод команды `git status` довольно всеобъемлющий и многословный.
-Git также имеет флаг вывода сокращенного статуса, так что вы можете увидеть изменения в более компактном виде.
-Если вы выполните `git status -s` или `git status --short` вы получите гораздо более упрощенный вывод:
+Git также имеет флаг вывода сокращённого статуса, так что вы можете увидеть изменения в более компактном виде.
+Если вы выполните `git status -s` или `git status --short` вы получите гораздо более упрощённый вывод:
 
 [source,console]
 ----

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

@@ -88,7 +88,7 @@ Changes not staged for commit:
 [NOTE]
 =====
 Команда `git reset` _может_ быть опасной если вызвать её с параметром `--hard`.
-В приведенном примере файл не был затронут, следовательно команда относительно безопасна.
+В приведённом примере файл не был затронут, следовательно команда относительно безопасна.
 =====
 
 На текущий момент этот магический вызов -- всё, что вам нужно знать о команде `git reset`.
@@ -224,6 +224,6 @@ Changes to be committed:
 [IMPORTANT]
 =====
 Важно понимать, что `git restore <file>` -- опасная команда.
-Любые локальные изменения, внесенные в этот файл, исчезнут -- Git просто заменит файл последней зафиксированной версией.
-Никогда не используйте эту команду, если точно не знаете, нужны ли вам эти несохраненные локальные изменения. 
+Любые локальные изменения, внесённые в этот файл, исчезнут -- Git просто заменит файл последней зафиксированной версией.
+Никогда не используйте эту команду, если точно не знаете, нужны ли вам эти несохранённые локальные изменения. 
 =====

book/02-git-basics/sections/viewing-history.asc

@@ -42,7 +42,7 @@ Date: Sat Mar 15 10:31:28 2008 -0700
 Команда `git log` имеет очень большое количество опций для поиска коммитов по разным критериям.
 Рассмотрим наиболее популярные из них.
 
-Одним из самых полезных аргументов является `-p` или `--patch`, который показывает разницу (выводит _патч_), внесенную в каждый коммит.
+Одним из самых полезных аргументов является `-p` или `--patch`, который показывает разницу (выводит _патч_), внесённую в каждый коммит.
 Так же вы можете ограничить количество записей в выводе команды; используйте параметр `-2` для вывода только двух записей:
 
 [source,console]
@@ -90,9 +90,9 @@ index a0a60ae..47c6340 100644
 ----
 
 Эта опция отображает аналогичную информацию но содержит разницу для каждой записи.
-Очень удобно использовать данную опцию для код ревью или для быстрого просмотра серии внесенных изменений.
+Очень удобно использовать данную опцию для код ревью или для быстрого просмотра серии внесённых изменений.
 Так же есть возможность использовать серию опций для обобщения.
-Например, если вы хотите увидеть сокращенную статистику для каждого коммита, вы можете использовать опцию `--stat`:
+Например, если вы хотите увидеть сокращённую статистику для каждого коммита, вы можете использовать опцию `--stat`:
 
 [source,console]
 ----
@@ -163,11 +163,11 @@ a11bef0 - Scott Chacon, 6 years ago : Initial commit
 |================================
 | Опция | Описания вывода
 | `%H` | Хеш коммита
-| `%h` | Сокращенный хеш коммита
+| `%h` | Сокращённый хеш коммита
 | `%T` | Хеш дерева
-| `%t` | Сокращенный хеш дерева
+| `%t` | Сокращённый хеш дерева
 | `%P` | Хеш родителей
-| `%p` | Сокращенный хеш родителей
+| `%p` | Сокращённый хеш родителей
 | `%an` | Имя автора
 | `%ae` | Электронная почта автора
 | `%ad` | Дата автора (формат даты можно задать опцией --date=option)
@@ -208,7 +208,7 @@ $ git log --pretty=format:"%h %s" --graph
 <<rlog_options>> содержит описание как уже рассмотренных, так и нескольких новых опций, которые могут быть полезными в зависимости от нужного формата вывода.
 
 [[rlog_options]]
-.Наиболее распространенные опции для команды `git log`
+.Наиболее распространённые опции для команды `git log`
 [cols="1,4",options="header"]
 |================================
 | Опция | Описание
@@ -226,7 +226,7 @@ $ git log --pretty=format:"%h %s" --graph
 
 ==== Ограничение вывода
 
-В дополнение к опциям форматирования вывода, команда `git log` принимает несколько опций для ограничения вывода -- опций, с помощью которых можно увидеть определенное подмножество коммитов.
+В дополнение к опциям форматирования вывода, команда `git log` принимает несколько опций для ограничения вывода -- опций, с помощью которых можно увидеть определённое подмножество коммитов.
 Вы уже видели одну из таких опций -- это опция `-2`, которая показывает только последние два коммита.
 В действительности вы можете использовать `-<n>`, где `n` -- это любое натуральное число и представляет собой `n` последних коммитов.
 На практике вы не будете часто использовать эту опцию, потому что Git по умолчанию использует постраничный вывод и вы будете видеть только одну страницу за раз.
@@ -239,7 +239,7 @@ $ git log --pretty=format:"%h %s" --graph
 $ git log --since=2.weeks
 ----
 
-Это команда работает с большим количеством форматов -- вы можете указать определенную дату вида `2008-01-15` или же относительную дату, например `2 years 1 day 3 minutes ago`.
+Это команда работает с большим количеством форматов -- вы можете указать определённую дату вида `2008-01-15` или же относительную дату, например `2 years 1 day 3 minutes ago`.
 
 Также вы можете фильтровать список коммитов по заданным параметрам.
 Опция `--author` дает возможность фильтровать по автору коммита, а опция `--grep` искать по ключевым словам в сообщении коммита.
@@ -250,7 +250,7 @@ $ git log --since=2.weeks
 ====
 
 Следующим действительно полезным фильтром является опция `-S`, которая принимает аргумент в виде строки и показывает только те коммиты, в которых изменение в коде повлекло за собой добавление или удаление этой строки.
-Например, если вы хотите найти последний коммит, который добавил или удалил вызов определенной функции, вы можете запустить команду:
+Например, если вы хотите найти последний коммит, который добавил или удалил вызов определённой функции, вы можете запустить команду:
 
 [source,console]
 ----
@@ -267,7 +267,7 @@ $ git log -- path/to/file
 ----
 
 
-В таблице <<rlimit_options>> вы можете увидеть эти и другие распространенные опции.
+В таблице <<rlimit_options>> вы можете увидеть эти и другие распространённые опции.
 
 [[rlimit_options]]
 .Опции для ограничения вывода команды `git log`

book/03-git-branching/sections/basic-branching-and-merging.asc

@@ -277,7 +277,7 @@ Hit return to start merge resolution tool (opendiff):
 ====
 
 После выхода из инструмента слияния Git спросит об успешности процесса.
-Если вы ответите скрипту утвердительно, то он добавит файл в индекс, чтобы отметить его как разрешенный.
+Если вы ответите скрипту утвердительно, то он добавит файл в индекс, чтобы отметить его как разрешённый.
 Теперь можно снова запустить `git status`, чтобы убедиться в отсутствии конфликтов:
 
 [source,console]

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

@@ -4,7 +4,7 @@
 (((ветки, удалённые)))(((указатели, удалённые)))
 Удалённые ссылки -- это ссылки (указатели) в ваших удалённых репозиториях, включая ветки, теги и так далее.
 Полный список удалённых ссылок можно получить с помощью команды `git ls-remote <remote>` или команды `git remote show <remote>` для получения удалённых веток и дополнительной информации.
-Тем не менее, более распространенным способом является использование веток слежения.
+Тем не менее, более распространённым способом является использование веток слежения.
 
 Ветки слежения -- это ссылки на определённое состояние удалённых веток.
 Это локальные ветки, которые нельзя перемещать; Git перемещает их автоматически при любой коммуникации с удалённым репозиторием, чтобы гарантировать точное соответствие с ним.

book/04-git-server/sections/git-on-a-server.asc

@@ -78,7 +78,7 @@ $ git init --bare --shared
 
 Если вы небольшая компания или вы только пробуете использовать Git в вашей организации и у вас небольшое число разработчиков, то всё достаточно просто.
 Один из наиболее сложных аспектов настройки сервера Git -- это управление пользователями.
-Если вы хотите, чтобы некоторые репозитории были доступны определенным пользователям только на чтение, а остальным на чтение и запись, то настроить доступ и привилегии будет несколько сложнее.
+Если вы хотите, чтобы некоторые репозитории были доступны определённым пользователям только на чтение, а остальным на чтение и запись, то настроить доступ и привилегии будет несколько сложнее.
 
 ===== SSH доступ
 

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

@@ -75,7 +75,7 @@ image::images/git-diff-check.png["Вывод команды `git diff --check`"]
 (за исключением случаев, когда детального описания нет);
 в противном случае такие инструменты, как rebase, могут вас запутать.
 
-Сообщения коммитов следует писать используя неопределенную форму глагола совершенного вида повелительного наклонения: «Fix bug» (Исправить баг), а не «Fixed bug» (Исправлен баг) или «Fixes bug» (Исправляет баг).
+Сообщения коммитов следует писать используя неопределённую форму глагола совершенного вида повелительного наклонения: «Fix bug» (Исправить баг), а не «Fixed bug» (Исправлен баг) или «Fixes bug» (Исправляет баг).
 Это соглашение соответствует сообщениям коммитов, генерируемых такими командами, как `git merge` и `git revert`.
 
 Последующие абзацы идут после пустых строк.
@@ -417,7 +417,7 @@ Merge made by the 'recursive' strategy.
 ----
 
 Одна небольшая проблема -- ей нужно отправить слитые изменения из локальной ветки `featureB` в ветку `featureBee` на сервере.
-Для этого в команде `git push` Джессика указывает названия локальной и удалённой веток, разделенных двоеточием:
+Для этого в команде `git push` Джессика указывает названия локальной и удалённой веток, разделённых двоеточием:
 
 [source,console]
 ----