Исправление опечаток

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

@@ -610,8 +610,8 @@ image::images/public-small-2.png[История коммитов после ра
 Альтернативным решением может быть отправка этих исправлений в ветку с другим названием (например, `featureAv2`).
 
 Давайте рассмотрим ещё один возможный сценарий: сопровождающий посмотрел вашу вторую ветку и ему понравилась идея, но он хочет попросить вас изменить некоторые детали.
-Возможо, вы так же захотите перебазировать эту ветку относительно текущего состояния ветки `master`.
-Вы создаёте новую ветку базируясь на текущей `origin/master`, сбрасываете все изменения в неё, разрашаете возможные конфликты, делаете изменения в реализации и отправляете её как новую ветку:
+Возможно, вы так же захотите перебазировать эту ветку относительно текущего состояния ветки `master`.
+Вы создаёте новую ветку базируясь на текущей `origin/master`, сбрасываете все изменения в неё, разрешаете возможные конфликты, делаете изменения в реализации и отправляете её как новую ветку:
 
 (((git commands, merge, squash)))
 [source,console]

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

@@ -120,7 +120,7 @@ CommitDate: Thu Apr 9 09:19:06 2009 -0700
 `Commit` информация указывает на того, кто применил патч и когда это было сделано.
 `Author` информация указывает на того, кто изначально создал патч и когда это было сделано.
 
-Однако, возможна ситуация, когда патч не может быть безаконфликтно применен.
+Однако, возможна ситуация, когда патч не может быть безконфликтно применен.
 Возможно, ваша основная ветка сильно расходится с той веткой, на основании которой был создан патч, или он зависит от другого, ещё не примененного патча.
 В таком случае работа `git am` будет прервана, а так же выведена подсказка со списком возможных действий:
 
@@ -322,7 +322,7 @@ image::images/merging-workflows-2.png[Слияние тематической в
 Если у вас очень важный проект, то возможно вам стоит использовать двухступенчатый цикл слияния.
 При таком сценарии у вас имеются две долгоживущие ветки `master` и `develop`, где в `master` сливаются только очень стабильные изменения, а все новые доработки интегрируются в ветку `develop`.
 Обе ветки регулярно отправляются в публичный репозиторий.
-Каждый раз, когда новая тематческая ветка готова к слиянию (<<rmerwf_c>>), вы сливаете её в `develop` (<<rmerwf_d>>); затем, когда вы выпускаете релиз, ветка `master` смещается на стабильное состояние ветки `develop` (<<rmerwf_e>>).
+Каждый раз, когда новая тематическая ветка готова к слиянию (<<rmerwf_c>>), вы сливаете её в `develop` (<<rmerwf_d>>); затем, когда вы выпускаете релиз, ветка `master` смещается на стабильное состояние ветки `develop` (<<rmerwf_e>>).
 
 [[rmerwf_c]]
 .Перед слиянием тематической ветки.
@@ -377,7 +377,7 @@ image::images/large-merges-2.png[Слияние тематических вет
 Другим способом перемещения предлагаемых изменений из одной ветки в другую является их выборочное применение (cherry-pick).
 Выборочное применение в Git похоже на перебазирование для одного коммита.
 В таком случае формируется патч для выбранного коммита и применяется к текущей ветке.
-Это полезно, когда в тематической ветке присутствует несколько коммитов, а выхотите применить только один из них, или в тематической ветке только один коммит и выхотите его применить вместо использования перебазирования.
+Это полезно, когда в тематической ветке присутствует несколько коммитов, а вы хотите применить только один из них, или в тематической ветке только один коммит и выхотите его применить вместо использования перебазирования.
 Например, предположим, что ваш проект выглядит следующим образом:
 
 .Пример истории до выборочного слияния.
@@ -404,7 +404,7 @@ image::images/rebasing-2.png[История после выборочного п
 ===== Возможность ``Rerere''
 
 (((git commands, rerere)))(((rerere)))
-Если вы часто производите перебазирование и слияние или поддерживаете догоживущие тематические ветки, то в Git есть специальная возможность под названием ``rerere'', призванная вам помочь.
+Если вы часто производите перебазирование и слияние или поддерживаете долгоживущие тематические ветки, то в Git есть специальная возможность под названием ``rerere'', призванная вам помочь.
 
 Её название расшифровывается как ``переиспользование записанного решения'', а применяется для ускорения ручного разрешения конфликтов.
 Когда эта опция включена, Git будет сохранять набор образов до и после успешного слияния, а так же разрешать конфликты самостоятельно, если аналогичные конфликты уже были разрешены ранее.
@@ -462,15 +462,15 @@ $ gpg -a --export F721C45A | git hash-object -w --stdin
 659ef797d181633c87ec71ac3f9ba29fe5775b92
 ----
 
-Теперь, когда ваш публчниый ключ находится в репозитории, можно поставить указывающий на него тег, используя полученное ранее значение SHA-1:
+Теперь, когда ваш публичный ключ находится в репозитории, можно поставить указывающий на него тег, используя полученное ранее значение SHA-1:
 
 [source,console]
 ----
 $ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92
 ----
 
 Выполнив команду `git push --tags`, `maintainer-pgp-pub` тег станет общедоступным.
-Теперь все, кто захочет проверить вашу подпись, могут ипортировать ваш публиный ключ, предварительно получив его из репозитория:
+Теперь все, кто захочет проверить вашу подпись, могут импортировать ваш публиный ключ, предварительно получив его из репозитория:
 
 [source,console]
 ----

book/06-github/sections/2-contributing.asc

@@ -16,7 +16,7 @@
 
 Таким образом, проекты не обеспокоены тем, чтобы пользователи, которые хотели бы выступать в роли соавторов, имели право на внесение изменений путем их отправки (push).
 Люди просто могут создавать свои собственные ветвления (fork), вносить туда изменения, а затем отправлять свои внесенные изменения в оригинальный репозиторий проекта путем создания запроса на принятие изменений (Pull Request), сами же запросы на принятие изменений (Pull Request) будут описаны далее.
-Запрос на принятие изменений (Pull Request) откроет новую ветвь с обсуждением отправляемого кода, и автор оригинального проекта, а так же другие его участники, могут принимать участие в обсуждения предлагаемых изменений до тех пор, пока автор проекта не будет ими доволен, после чего автор проекта может добавить предлагаемые изменения в проект.
+Запрос на принятие изменений (Pull Request) откроет новую ветвь с обсуждением отправляемого кода, и автор оригинального проекта, а так же другие его участники, могут принимать участие в обсуждении предлагаемых изменений до тех пор, пока автор проекта не будет ими доволен, после чего автор проекта может добавить предлагаемые изменения в проект.
 
 Для того, чтобы создать ответвление проекта (fork), зайдите на страницу проекта и нажмите кнопку ``Создать ответвление'' (``Fork''), которая расположена в правом верхнем углу.
 
@@ -173,7 +173,7 @@ image::images/blink-05-general-comment.png[Страница обсуждения
 image::images/blink-06-final.png[Финальная стадия запроса на слияние]
 
 Примечательно, что если вы перейдёте на вкладку ``Files Changed'' в этом запросе на слияние, то увидите ``унифицированную'' разницу -- это суммарные изменения, которые будут включены в освновную ветку при слиянии тематической ветки.
-В терминологии `git diff` это эквивалентно команде `git diff master...<branch>` для ветки, на котрой основан этот запрос на слияние.
+В терминологии `git diff` это эквивалентно команде `git diff master...<branch>` для ветки, на которой основан этот запрос на слияние.
 В <<ch05-distributed-git#r_what_is_introduced>> детальнее описан данный тип отличий.
 
 GitHub так же проверяет может ли запрос на слияние быть применен без конфликтов и предоставляет кнопку для осуществления слияния на сервере.
@@ -209,7 +209,7 @@ GitHub так же проверяет может ли запрос на слия
 
 Например, если вы вернетесь и посмотрите на <<r_pr_final>>, то увидите, что контрибьютер не делал перебазирование своего коммита и не отправлял новый запрос на слияние.
 Вместо этого были сделаны новые коммиты и отправлены в существующую ветку.
-Таким образом, если вы в будущем вернетесь к к этому запросу слияния, то легко найдёте весь контекст принятого решения.
+Таким образом, если вы в будущем вернетесь к этому запросу слияния, то легко найдёте весь контекст принятого решения.
 По нажатию кнопки ``Merge'' целенаправленно создаётся коммит слияния, который указывает на запрос слиния, оставляя возможность возврата к цепочке обсуждения.
 
 ===== Следование за исходным репозиторием
@@ -282,7 +282,7 @@ image::images/pr-02-merge-fix.png[PR fixed]
 Одна из замечательных особенностей Git - это то, что вы можете делать это постоянно.
 Если у вас очень длительный проект, вы можете легко сливать изменения из целевой ветки снова и снова и иметь дело только с конфликтами, возникшими с момента вашего последнего слияния, что делает процесс очень управляемым.
 
-Если вы очень хотите перебазровать ветку, чтобы её почистить, то, конечно, вы можете это сделать, но настоятельно не рекомендуется переписывать ветку, к которой уже открыт запрос на слияние.
+Если вы очень хотите перебазировать ветку, чтобы её почистить, то, конечно, вы можете это сделать, но настоятельно не рекомендуется переписывать ветку, к которой уже открыт запрос на слияние.
 Если другие люди уже стянули её и проделали много работы, то вы столкнётесь со всеми проблемами, описанными в <<ch03-git-branching#r_rebase_peril>>.
 Вместо этого, отправьте перебазированную ветку в новую на GiHub и откройте новый запрос на слияние, который указывает на предыдущий, затем закройте исходный.
 
@@ -295,7 +295,7 @@ image::images/pr-02-merge-fix.png[PR fixed]
 Всем запросам слияния и проблемам присваиваются уникальные номера в пределах проекта.
 Например, у вас не может быть запроса на слияние с номером #3 и проблемы с номером #3.
 Если вы хотите сослаться на любой запрос слияния или проблему из другого места, просто добавьте `#<num>` в комментарий или описание.
-Так же можно указывать более конкретно, если проблема или запрос слияния находятя где-то ещё; пишите `username#<num>` если ссылаетесь на проблему или запрос слияния, находящиеся в ответвленном репозитории, или `username/repo#<num>` если ссылаетесь на другой репозиторий.
+Так же можно указывать более конкретно, если проблема или запрос слияния находятся где-то ещё; пишите `username#<num>` если ссылаетесь на проблему или запрос слияния, находящиеся в ответвленном репозитории, или `username/repo#<num>` если ссылаетесь на другой репозиторий.
 
 Рассмотрим это на примере.
 Предположим, что мы перебазировали ветку в предыдущем примере, создали новый запрос слияния для неё и сейчас хотим сослаться на предыдущий запрос слияния из нового.