progit · Nokhrin · Aug 11, 2025
diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc
@@ -38,7 +38,7 @@ GitHub разработан с прицелом на определённый р
 
 1. Создайте форк проекта.
 2. Создайте тематическую ветку на основании ветки `master`.
-3. Создайте один или несколько коммитов с изменениями, улучшающих проект.
+3. Создайте один или несколько коммитов с изменениями, улучшающими проект.
 4. Отправьте эту ветку в ваш проект на GitHub.
 5. Откройте запрос на слияние на GitHub.
 6. Обсуждайте его, вносите изменения, если нужно.
@@ -378,7 +378,7 @@ image::images/markdown-02-tasks.png["Пример списка задач"]
 Вы можете просто кликнуть по флажку, чтобы обновить комментарий -- не нужно редактировать комментарий вручную, чтобы пометить задачу как выполненную.
 
 Так же GitHub ищет списки задач в запросах на слияние и проблемах и отображает их как метаданные на страницах, где они упоминаются.
-Например, если в вашем запросе на слияние есть задачи и вы просматриваете список всех запросов, то можно увидеть на сколько готов каждый из них.
+Например, если в вашем запросе на слияние есть задачи и вы просматриваете список всех запросов, то можно увидеть насколько готов каждый из них.
 Это позволяет разбивать запрос на слияние на несколько подзадач и помогает другим людям отслеживать прогресс ветки.
 Пример приведён на <<r_task_list_progress>>.
 

diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc
@@ -102,7 +102,7 @@ $ curl https://github.com/tonychacon/fade/pull/1.patch | git am
 .Ответы на письма включены в диалог
 image::images/maint-03-email-resp.png["Email ответ"]
 
-Когда вы готовы слить код, вы можете стянуть его себе и слить локально, слить используя команду `git pull <url> <branch>`, которую мы видели ранее, или добавив ответвлённый репозиторий как удалённый получить и слить изменения.
+Когда вы готовы слить код, вы можете стянуть его себе и слить локально, слить используя команду `git pull <url> <branch>`, которую мы видели ранее, или добавив ответвлённый репозиторий как удалённый, получить и слить изменения.
 
 Если слияние тривиально, то можно просто нажать кнопку «Merge» на сайте GitHub.
 Это всегда приводит с созданию коммита слияния, даже если доступно слияние перемоткой вперёд.
@@ -125,7 +125,7 @@ image::images/maint-02-merge.png["Кнопка Merge"]
 По умолчанию, они не копируются при клонировании, а существуют в замаскированном виде и вы можете легко получить доступ к ним.
 
 В качестве примера мы используем низкоуровневую команду `ls-remote` (часто упоминается как «plumbing» команда, более подробно о ней будет рассказано в <<ch10-git-internals#r_plumbing_porcelain>>).
-Обычно, эта команда не используется в повседневных Git операциях, но сейчас поможет нам увидеть какие ссылки присутствуют на сервере.
+Обычно, эта команда не используется в повседневных Git операциях, но сейчас поможет нам увидеть, какие ссылки присутствуют на сервере.
 
 Если выполнить её относительно использованного ранее репозитория «blink», мы получим список всех веток, тегов и прочих ссылок в репозитории.
 
@@ -162,7 +162,7 @@ From https://github.com/libgit2/libgit2
 
 Эта команда указывает Git: «Подключись к `origin` репозиторию и скачай ссылку `refs/pull/958/head`».
 Git с радостью слушается и выкачивает всё необходимое для построения указанной ссылки, а так же устанавливает указатель на коммит в `.git/FETCH_HEAD`.
-Далее, вы можете слить изменения в нужную ветку при помощи команды `git merge FETCH_HEAD`, однако сообщение коммита слияния будет выглядеть немного странно.
+Далее, вы можете слить изменения в нужную ветку при помощи команды `git merge FETCH_HEAD`, однако, сообщение коммита слияния будет выглядеть немного странно.
 Так же это становится утомительным, если вы просматриваете *много* запросов на слияние.
 
 Существует способ получать _все_ запросы слияния и поддерживать их в актуальном состоянии при подключении к удалённому репозиторию.
@@ -349,7 +349,7 @@ X-GitHub-Recipient-Address: [email protected]
 image::images/maint-09-contrib.png["Примечание для участников проекта"]
 
 Идея состоит в том, что вы можете указать конкретные вещи, которые вы хотите или не хотите видеть в новых запросах на слияние.
-Таким образом люди могут ознакомится с руководством, перед тем как создавать новый запрос на слияние.
+Таким образом, люди могут ознакомится с руководством перед тем как создавать новый запрос на слияние.
 
 ==== Управление проектом
 

diff --git a/book/06-github/sections/4-managing-organization.asc b/book/06-github/sections/4-managing-organization.asc
@@ -35,7 +35,7 @@ image::images/neworg.png["Пункт меню «New organization»"]
 
 Например, у вашей компании есть три репозитория: `frontend`, `backend` и `deployscripts`.
 Вы бы хотели, чтобы ваши разработчики HTML/CSS/JavaScript имели доступ к `frontend` и возможно к `backend`, а ваши администраторы имели доступ к `backend` и `deployscripts`.
-С помощью команд это легко реализовать не настраивая доступ к каждому репозиторию для каждого участника.
+С помощью команд это легко реализовать, не настраивая доступ к каждому репозиторию для каждого участника.
 
 Страница Организации представляет собой простую панель управления репозиториями, пользователями и командами в пределах данной организации.
 
@@ -55,7 +55,7 @@ image::images/orgs-02-teams.png["Страница команды"]
 Когда вы пригласите кого-нибудь в команду, то будет отправлено письмо с приглашением.
 
 Упоминания команд (`@mentions`), такие как `@acmecorp/frontend`, работают точно так же как и упоминания отдельных пользователей, за исключением того, что уведомляются *все* члены команды.
-Это полезно когда вы хотите привлечь внимание кого-нибудь из команды, но точно не знаете кого спросить.
+Это полезно, когда вы хотите привлечь внимание кого-нибудь из команды, но точно не знаете, кого спросить.
 
 Пользователь может принадлежать любому числу команд, поэтому не ограничивайте себя командами, разделёнными по уровню доступа.
 Специализированные команды, такие как `ux`, `css` или `refactoring` полезны для вопросов одной тематики, тогда как команды `legal` и `colorblind` -- для вопросов другой тематики.

diff --git a/book/06-github/sections/5-scripting.asc b/book/06-github/sections/5-scripting.asc
@@ -56,7 +56,7 @@ image::images/scripting-03-webhook.png[Web hook]
 Давайте рассмотрим небольшой пример веб-сервиса, который вы можете настроить для обработки вебхука.
 Мы будем использовать веб-фреймворк Ruby Sinatra, так как он довольно лаконичен, и вы сможете легко увидеть, что мы делаем.
 
-Допустим, мы хотим получать электронное письмо, если конкретный человек отправляет на определённую ветку нашего проекта, изменённый определённый файл.
+Допустим, мы хотим получать электронное письмо, если конкретный человек отправляет на определённую ветку нашего проекта изменённый определённый файл.
 Мы могли бы довольно легко сделать это с помощью такого кода:
 
 [source,ruby]
@@ -168,7 +168,7 @@ hs_err_pid*
 
 ==== Комментирование проблемы
 
-Однако, если вы хотите выполнить какое-либо действие на веб-сайте, например прокомментировать проблему или запрос на слияние, или если вы хотите просмотреть или взаимодействовать с частным контентом, вам необходимо пройти аутентификацию.
+Однако, если вы хотите выполнить какое-либо действие на веб-сайте, например, прокомментировать проблему или запрос на слияние, или если вы хотите просмотреть или взаимодействовать с частным контентом, вам необходимо пройти аутентификацию.
 
 Существует несколько способов аутентификации.
 Вы можете использовать обычную аутентификацию только с вашим именем пользователя и паролем, но, как правило, лучше использовать токен личного доступа.