From 036a58aeeb74f95ed1bf4a75c211f4b3a20273cb Mon Sep 17 00:00:00 2001 From: Viktor Yegay Date: Thu, 1 Feb 2024 22:25:07 +0500 Subject: [PATCH 1/2] =?UTF-8?q?=D0=98=D1=81=D0=BF=D0=BE=D0=BB=D1=8C=D0=B7?= =?UTF-8?q?=D0=BE=D0=B2=D0=B0=D1=82=D1=8C=20=D0=B1=D1=83=D0=BA=D0=B2=D1=83?= =?UTF-8?q?=20=D1=91?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit берем -> берём разберем -> разберём разберемся -> разберёмся берет -> берёт соберете -> соберёте берете -> берёте введете -> введёте ведет -> ведёт проведет -> проведёт приведет -> приведёт вперед -> вперёд Все -> Всё дает -> даёт создает -> создаёт создаете -> создаёте его -> её её -> их жесткие -> жёсткие зеленую -> зелёную извлек -> извлёк изменен -> изменён имен -> имён лёгковесные -> легковесные нажмем -> нажмём начнет -> начнёт нашел -> нашёл него -> неё неё -> него отменен -> отменён перешел -> перешёл подойдет -> подойдёт подчеркивает -> подчёркивает подчеркивая -> подчёркивая поймете -> поймёте посвящен -> посвящён приведен -> приведён придется -> придётся применен -> применён прошел -> прошёл свое -> своё своем -> своём сохранен -> сохранён уведомлен -> уведомлён умен -> умён упрощен -> упрощён учетной -> учётной чем -> чём четырех -> четырёх четырехлетней -> четырёхлетней --- C-git-commands.asc | 2 +- TRANSLATION_NOTES.asc | 2 +- .../sections/getting-a-repository.asc | 2 +- .../sections/recording-changes.asc | 2 +- book/02-git-basics/sections/tagging.asc | 6 +++--- book/02-git-basics/sections/undoing.asc | 2 +- .../02-git-basics/sections/viewing-history.asc | 4 ++-- .../sections/basic-branching-and-merging.asc | 18 +++++++++--------- book/03-git-branching/sections/rebasing.asc | 2 +- book/04-git-server/sections/gitlab.asc | 4 ++-- book/04-git-server/sections/hosted.asc | 2 +- book/04-git-server/sections/protocols.asc | 2 +- book/04-git-server/sections/smart-http.asc | 2 +- .../sections/contributing.asc | 8 ++++---- .../sections/maintaining.asc | 10 +++++----- .../sections/1-setting-up-account.asc | 4 ++-- book/06-github/sections/2-contributing.asc | 4 ++-- book/06-github/sections/3-maintaining.asc | 2 +- .../sections/4-managing-organization.asc | 2 +- book/06-github/sections/5-scripting.asc | 14 +++++++------- .../07-git-tools/sections/advanced-merging.asc | 2 +- book/07-git-tools/sections/credentials.asc | 2 +- book/07-git-tools/sections/debugging.asc | 2 +- .../sections/interactive-staging.asc | 2 +- book/07-git-tools/sections/replace.asc | 2 +- book/07-git-tools/sections/reset.asc | 16 ++++++++-------- .../sections/revision-selection.asc | 4 ++-- .../sections/rewriting-history.asc | 4 ++-- book/07-git-tools/sections/searching.asc | 2 +- book/07-git-tools/sections/signing.asc | 2 +- .../sections/stashing-cleaning.asc | 6 +++--- book/07-git-tools/sections/submodules.asc | 6 +++--- .../08-customizing-git/sections/attributes.asc | 4 ++-- book/08-customizing-git/sections/policy.asc | 2 +- book/10-git-internals/sections/environment.asc | 2 +- book/preface_schacon.asc | 4 ++-- ch03-git-branching.asc | 2 +- ch10-git-internals.asc | 2 +- 38 files changed, 80 insertions(+), 80 deletions(-) diff --git a/C-git-commands.asc b/C-git-commands.asc index 1a6815b6..80e7a34d 100644 --- a/C-git-commands.asc +++ b/C-git-commands.asc @@ -39,7 +39,7 @@ В разделе <> главы 7 мы показали как настроить фильтры содержимого для данных, перемещаемых между индексом и рабочей копией. -И наконец, этой команде посвящен практически весь раздел <> главы 8. +И наконец, этой команде посвящён практически весь раздел <> главы 8. [[r_core_editor]] ==== Команды git config core.editor diff --git a/TRANSLATION_NOTES.asc b/TRANSLATION_NOTES.asc index cda63d8a..7e857cdc 100644 --- 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 index 47f051df..ea5c5326 100644 --- 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 index 8553cbf2..ea7ba780 100644 --- 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 index e4512f93..ae33a9bd 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -202,7 +202,7 @@ To git@github.com:schacon/simplegit.git * [new tag] v1.5 -> v1.5 ---- -Если у вас много тегов, и вам хотелось бы отправить все за один раз, то можно использовать опцию `--tags` для команды `git push`. +Если у вас много тегов, и вам хотелось бы отправить всё за один раз, то можно использовать опцию `--tags` для команды `git push`. В таком случае все ваши теги отправятся на удалённый сервер (если только их уже там нет). [source,console] @@ -222,7 +222,7 @@ To git@github.com:schacon/simplegit.git .`git push` отправляет оба типа тегов ==== Отправка тегов командой `git push --tags` не различает аннотированные и легковесные теги. -В настоящее время не существует опции чтобы отправить только лёгковесные теги, но если использовать команду `git push --follow-tags`, то отправятся только аннотированные теги. +В настоящее время не существует опции чтобы отправить только легковесные теги, но если использовать команду `git push --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 index 6d1b280d..3383a04d 100644 --- 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 index dfc9f50f..82ad4d95 100644 --- 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 index b088bb5a..0c603f4f 100644 --- 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,7 +45,7 @@ $ git checkout iss53 image::images/basic-branching-2.png["Создание нового указателя ветки"] Вы работаете над сайтом и делаете коммиты. -Это приводит к тому, что ветка `iss53` движется вперед, так как вы переключились на неё ранее (`HEAD` указывает на неё). +Это приводит к тому, что ветка `iss53` движется вперёд, так как вы переключились на неё ранее (`HEAD` указывает на неё). [source,console] ---- @@ -53,12 +53,12 @@ $ 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.support@github.com Разрешив каждый конфликт во всех файлах, запустите `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 index 6835b2dc..9e9ab6fa 100644 --- 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 index da4d96fb..1a9eec52 100644 --- 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 index b33be3cb..5a57b05f 100644 --- 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 в главе <>, так как это крупнейший Git-хостинг и вам скорее всего понадобится взаимодействовать с проектами, хостящимися на нём; при этом существуют десятки других, что делает необязательным использование собственного сервера. diff --git a/book/04-git-server/sections/protocols.asc b/book/04-git-server/sections/protocols.asc index 7cdfc9bb..6dda2dbd 100644 --- a/book/04-git-server/sections/protocols.asc +++ b/book/04-git-server/sections/protocols.asc @@ -27,7 +27,7 @@ $ git clone file:///srv/git/project.git ---- Git работает немного по-другому, если вы явно укажете префикс `file://` в начале вашего URL. -Когда вы просто указываете путь, Git пытается использовать жесткие ссылки или копировать необходимые файлы. +Когда вы просто указываете путь, Git пытается использовать жёсткие ссылки или копировать необходимые файлы. Если вы указываете `file://`, Git работает с данными так же, как при использовании сетевых протоколов, что снижает эффективность передачи данных. Причиной для использования `file://` может быть необходимость создания чистой копии репозитория без лишних внешних ссылок и объектов, обычно после импорта из другой системы управления версиями или чего-то похожего (задачи по обслуживанию рассмотрены в главе <>). Мы будем использовать обычные пути, поскольку это практически всегда быстрее. diff --git a/book/04-git-server/sections/smart-http.asc b/book/04-git-server/sections/smart-http.asc index 2dfead13..a89a85d8 100644 --- a/book/04-git-server/sections/smart-http.asc +++ b/book/04-git-server/sections/smart-http.asc @@ -62,7 +62,7 @@ $ htpasswd -c /srv/git/.htpasswd schacon Скорее всего вы ещё захотите настроить SSL для шифрования трафика. Мы не хотим погружаться слишком глубоко в бездну настроек Apache, так как у вас может быть другой сервер или другие требования к аутентификации. -Идея в том, что Git идёт с CGI-скриптом `git-http-backend`, который берет на себя согласование передачи и приёма данных по HTTP. +Идея в том, что Git идёт с CGI-скриптом `git-http-backend`, который берёт на себя согласование передачи и приёма данных по HTTP. Сам по себе, он не реализует аутентификации, но это легко настраивается на уровне веб-сервера, который его запускает. Вы можете сделать это практически на любом веб-сервере с поддержкой CGI, так что используйте тот, который знаете лучше всего. diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index 7a931d18..e849054d 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -286,7 +286,7 @@ Fast forward 2 files changed, 6 insertions(+), 1 deletions(-) ---- -Проблем не возникает; как можно заметить, это простое перемещение вперед. +Проблем не возникает; как можно заметить, это простое перемещение вперёд. Теперь Джессика заканчивает процесс локального слияния объединяя полученные ранее изменения Джона, находящиеся в ветке `origin/master`: [source,console] @@ -506,7 +506,7 @@ image::images/managed-team-flow.png["Основная последователь Так как у вас нет доступа обновлять ветки проекта напрямую, то передавать проделанную работу следует другим способом. В первом примере рассматривается участие в публичном проекте посредством форка на Git платформах, где возможно его простое создание. Большинство сайтов Git хостинга поддерживают такую функцию (включая GitHub, BitBucket, repo.or.cz и другие), как и большинство тех, кто сопровождает проекты, ожидают такого же стиля участия. -Следующий раздел посвящен проектам, которые предпочитают принимать исправления в виде патчей по электронной почте. +Следующий раздел посвящён проектам, которые предпочитают принимать исправления в виде патчей по электронной почте. Для начала, вам следует клонировать основной репозиторий, создать тематическую ветку для одного или нескольких патчей и работать в ней. Обычно, последовательность действий выглядит так: @@ -537,7 +537,7 @@ $ git remote add myfork После этого следует отправить проделанную работу в него. Проще отправить вашу тематическую ветку, в которой велась работа, чем сливать изменения в вашу ветку `master` и отправлять её. -Если ваши изменения будут отклонены или какой-то из коммитов будет применен выборочно (команда `cherry-pick` более детально рассматривается в разделе <> главы 5), то вы не сможете вернуть состояние вашей ветки `master`. +Если ваши изменения будут отклонены или какой-то из коммитов будет применён выборочно (команда `cherry-pick` более детально рассматривается в разделе <> главы 5), то вы не сможете вернуть состояние вашей ветки `master`. Если менеджер проекта сольёт, перебазирует или выборочно применит ваши изменения, то вы сможете их получить из оригинального репозитория. В любом случае, отправить свои изменения вы можете командой: @@ -628,7 +628,7 @@ $ git commit $ git push myfork featureBv2 ---- -Опция `--squash` берет все изменения из указанной ветки, объединяет их и создаёт новый коммит в текущей ветке без создания коммита слияния. +Опция `--squash` берёт все изменения из указанной ветки, объединяет их и создаёт новый коммит в текущей ветке без создания коммита слияния. Это значит, что новый коммит будет иметь только одного родителя и будет включать все изменения из другой ветки, а так же позволяет внести дополнительные изменения до фактического создания коммита. Опция `--no-commit` указывает Git не создавать новый коммит автоматически. diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 6a23023c..5ee2dd48 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -11,7 +11,7 @@ Перед интеграцией новых изменений желательно проверить их в тематической ветке -- временной ветке, специально созданной для проверки работоспособности новых изменений. Таким образом, можно применять патчи по одному и пропускать неработающие, пока не найдётся время к ним вернуться. Если вы создадите ветку с коротким и понятным названием, основанным на тематике изменений, например, `ruby_client` или что-то похожее, то без труда можно будет вернуться к ней, если пришлось на какое-то время отказаться от работы с ней. -Сопровождающему Git проекта свойственно использовать пространство имен для веток, например, `sc/ruby_client`, где `sc` -- это сокращение от имени того, кто проделал работу. +Сопровождающему Git проекта свойственно использовать пространство имён для веток, например, `sc/ruby_client`, где `sc` -- это сокращение от имени того, кто проделал работу. Как известно, ветки можно создавать на основании базовой ветки, например: [source,console] @@ -39,7 +39,7 @@ $ git checkout -b sc/ruby_client master (((команды git, apply))) Если полученный по почте патч был создан командой `git diff` или Unix командой `diff` (что не рекомендуется делать), то применить его можно командой `git apply`. -Предположим, патч сохранен здесь `/tmp/patch-ruby-client.patch`, тогда применить его можно вот так: +Предположим, патч сохранён здесь `/tmp/patch-ruby-client.patch`, тогда применить его можно вот так: [source,console] ---- @@ -257,7 +257,7 @@ $ git diff master ---- Эта команда может вводить в заблуждение, но точно покажет разницу. -Если ваша `master` ветка продвинулась вперед с тех пор как вы создали тематическую ветку, то вы получите на первый взгляд странные результаты. +Если ваша `master` ветка продвинулась вперёд с тех пор как вы создали тематическую ветку, то вы получите на первый взгляд странные результаты. Это происходит потому, что Git непосредственно сравнивает снимки последних коммитов текущей и `master` веток. Например, если вы добавили строку в файл в ветке `master`, то прямое сравнение снимков будет выглядеть как будто тематическая ветка собирается удалить эту строку. @@ -355,7 +355,7 @@ image::images/large-merges-1.png["Управление сложным набор Если содержимое тематических веток требует доработки, оно сливается в ветку `seen`. Когда выясняется, что предложенный код полностью стабилен, он сливается в ветку `master`. Затем ветки `next` и `seen` перестраиваются на основании `master`. -Это означает, что `master` практически всегда двигается только вперед, `next` время от времени перебазируется, а `seen` перебазируется ещё чаще: +Это означает, что `master` практически всегда двигается только вперёд, `next` время от времени перебазируется, а `seen` перебазируется ещё чаще: .Слияние тематических веток в долгоживущие ветки интеграции image::images/large-merges-2.png["Слияние тематических веток в долгоживущие ветки интеграции"] @@ -495,7 +495,7 @@ v1.6.2-rc1-20-g8c5b85c ---- Таким образом, вы можете сделать снимок или собрать сборку и дать ей понятное для человека название. -К слову, если вы клонируете репозиторий Git и соберете его из исходного кода, то вывод команды `git --version` будет примерно таким же. +К слову, если вы клонируете репозиторий Git и соберёте его из исходного кода, то вывод команды `git --version` будет примерно таким же. Если попытаться получить имя коммита, которому назначен тег, то результатом будет название самого тега. По умолчанию, команда `git describe` поддерживает только аннотированные теги (созданные с использованием опций `-a` или `-s`); если вы хотите использовать легковесные (не аннотированные) теги, то укажите команде параметр `--tags`. diff --git a/book/06-github/sections/1-setting-up-account.asc b/book/06-github/sections/1-setting-up-account.asc index 212c9a72..0babfa61 100644 --- a/book/06-github/sections/1-setting-up-account.asc +++ b/book/06-github/sections/1-setting-up-account.asc @@ -1,4 +1,4 @@ -=== Настройка и конфигурация учетной записи +=== Настройка и конфигурация учётной записи (((GitHub, учётные записи))) @@ -79,7 +79,7 @@ image::images/email-settings.png["Добавьте все ваши почтов Верхний почтовый адрес подтверждён и является основным для пользователя, это тот самый адрес, куда будут направляться оповещения, а также остальные уведомления. Второй адрес тоже подтверждён, и так же может быть назначен в качестве основного. Последний адрес не подтверждён, это значит, что вы не можете использовать его в качестве основного и получать на него уведомления. -При отправке коммита в любой из репозиториев, GitHub распознает один из указанных почтовых адресов и автоматически привяжет этот коммит к вашей учетной записи. +При отправке коммита в любой из репозиториев, GitHub распознает один из указанных почтовых адресов и автоматически привяжет этот коммит к вашей учётной записи. ==== Двухфакторная аутентификация diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index a05fa96e..11676e44 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -69,7 +69,7 @@ image::images/blink-01-start.png["Проект, над которым мы хо Для начала, нажмите кнопку «Fork», как было сказано выше, чтобы заполучить собственную копию проекта. Мы зарегистрированы на GitHub под именем «tonychacon», так что наша копия окажется по адресу `https://github.com/tonychacon/blink`, где мы сможем редактировать её. -Мы клонируем его, создадим тематическую ветку, внесём необходимые изменения и, наконец, отправим их на GitHub. +Мы клонируем её, создадим тематическую ветку, внесём необходимые изменения и, наконец, отправим их на GitHub. [source,console] ---- @@ -190,7 +190,7 @@ image::images/blink-06-final.png["Финальная стадия запроса GitHub так же проверяет может ли запрос на слияние быть применён без конфликтов и предоставляет кнопку для осуществления слияния на сервере. Эта кнопка отображается только если у вас есть права на запись в репозиторий и возможно простейшее слияние. -По нажатию на неё GitHub произведёт «non-fast-forward» слияние, что значит даже если слияние *может* быть осуществлено перемоткой вперед, всё равно будет создан коммит слияния. +По нажатию на неё GitHub произведёт «non-fast-forward» слияние, что значит даже если слияние *может* быть осуществлено перемоткой вперёд, всё равно будет создан коммит слияния. При желании, можно стянуть ветку и произвести слияние локально. Если эта ветка будет слита в `master` ветку и отправлена на сервер, то GitHub автоматически закроет запрос на слияние. diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index b8600372..1f2130c0 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -113,7 +113,7 @@ image::images/maint-03-email-resp.png["Email ответ"] .Кнопка Merge и инструкции по ручному слиянию запроса image::images/maint-02-merge.png["Кнопка Merge"] -Если вы решаете не сливать запрос, то вы можете просто закрыть запрос на слияние, а открывший его участник будет уведомлен. +Если вы решаете не сливать запрос, то вы можете просто закрыть запрос на слияние, а открывший его участник будет уведомлён. [[r_pr_refs]] ===== Ссылки на запрос слияния diff --git a/book/06-github/sections/4-managing-organization.asc b/book/06-github/sections/4-managing-organization.asc index 753e9b8a..337ab163 100644 --- a/book/06-github/sections/4-managing-organization.asc +++ b/book/06-github/sections/4-managing-organization.asc @@ -46,7 +46,7 @@ image::images/orgs-01-page.png["Страница организации"] Для управления командами нужно перейти на закладку 'Teams' справа вверху на странице <>. Это приведёт вас на страницу где можно добавлять пользователей в команду, добавлять команде репозитории или управлять настройками и правами доступа. Каждая команда может иметь только следующие уровни доступа к репозиториям: «только чтение», «чтение/запись» или «администратор». -Уровень доступа может быть изменен нажатием кнопки «Settings» на странице <>. +Уровень доступа может быть изменён нажатием кнопки «Settings» на странице <>. [[r_team_page]] .Страница команды diff --git a/book/06-github/sections/5-scripting.asc b/book/06-github/sections/5-scripting.asc index 28e80699..42ad0e7f 100644 --- a/book/06-github/sections/5-scripting.asc +++ b/book/06-github/sections/5-scripting.asc @@ -28,7 +28,7 @@ image::images/scripting-01-services.png[Services and hooks] .Конфигурация службы электронной почты image::images/scripting-02-email-service.png[Email service] -В этом случае, если мы нажмем кнопку «Добавить сервис» («Add Service»), указанный нами адрес электронной почты будет получать электронное письмо каждый раз, когда кто-то отправляет в репозиторий. +В этом случае, если мы нажмём кнопку «Добавить сервис» («Add Service»), указанный нами адрес электронной почты будет получать электронное письмо каждый раз, когда кто-то отправляет в репозиторий. Сервисы могут прослушивать множество различных типов событий, но большинство из них прослушивают только push-события, а затем что-то делают с этими данными. Если вы используете систему, которую хотите интегрировать с GitHub, вам следует проверить здесь, чтобы узнать, доступна ли существующая интеграция сервиса. @@ -43,7 +43,7 @@ image::images/scripting-02-email-service.png[Email service] Как правило, это работает так: вы можете настроить небольшой веб-сервис для прослушивания полезных данных хука GitHub, а затем что-то делать с данными, когда они будут получены. Чтобы включить хук, вы нажимаете кнопку «Добавить вебхук» («Add webhook») в <>. -Это приведет вас на страницу, которая выглядит как <>. +Это приведёт вас на страницу, которая выглядит как <>. [[r_web_hook]] .Конфигурация вебхука @@ -93,7 +93,7 @@ post '/payload' do end ---- -Здесь мы берем полезные данные JSON, которые доставляет нам GitHub, и ищем, кто их отправил, в какую ветку они отправили и какие файлы были затронуты во всех отправленных коммитах. +Здесь мы берём полезные данные JSON, которые доставляет нам GitHub, и ищем, кто их отправил, в какую ветку они отправили и какие файлы были затронуты во всех отправленных коммитах. Затем мы проверяем это на соответствие нашим критериям и отправляем электронное письмо, если оно соответствует. Чтобы разработать и протестировать что-то подобное, у вас есть хорошая консоль разработчика на том же экране, где вы устанавливаете связь. @@ -182,7 +182,7 @@ image::images/scripting-05-access-token.png[Access Token] Обязательно используйте хорошее описание, чтобы вам было удобно удалять токен, когда ваш скрипт или приложение больше не используются. GitHub покажет вам токен только один раз, поэтому обязательно скопируйте его. -Теперь вы можете использовать это для аутентификации в своем скрипте вместо использования имени пользователя и пароля. +Теперь вы можете использовать это для аутентификации в своём скрипте вместо использования имени пользователя и пароля. Это хорошо, потому что вы можете ограничить объём того, что вы хотите сделать, и токен может быть отозван. Это также имеет дополнительное преимущество в виде увеличения лимита скорости. @@ -228,7 +228,7 @@ image::images/scripting-06-comment.png[API Comment] Есть ещё один последний пример, который мы рассмотрим, так как он действительно полезен, если вы работаете с запросами на слияние. С каждым коммитом может быть связан один или несколько статусов, и существует API для добавления и запроса этого статуса. -Большинство сервисов непрерывной интеграции и тестирования используют этот API для реагирования на отправку путём тестирования кода, который был отправлен, а затем сообщают, прошел ли этот коммит все тесты. +Большинство сервисов непрерывной интеграции и тестирования используют этот API для реагирования на отправку путём тестирования кода, который был отправлен, а затем сообщают, прошёл ли этот коммит все тесты. Вы также можете использовать это, чтобы проверить, правильно ли отформатировано сообщение о коммите, следовал ли отправитель всем вашим рекомендациям по вкладу, был ли коммит действительно подписан — что угодно. Допустим, вы настроили вебхук в своём репозитории, который обращается к небольшому веб-сервису, который проверяет наличие строки «Signed-off-by» в сообщении коммита. @@ -288,9 +288,9 @@ end .Статус коммита через API image::images/scripting-07-status.png[Commit status] -Теперь вы можете увидеть маленькую зеленую галочку рядом с коммитом, в сообщении которой есть строка «Signed-off-by», и красным крестиком тот коммит, который автор забыл подписать. +Теперь вы можете увидеть маленькую зелёную галочку рядом с коммитом, в сообщении которой есть строка «Signed-off-by», и красным крестиком тот коммит, который автор забыл подписать. Вы также можете видеть, что запрос на слияние принимает статус последнего коммита в ветке и предупреждает вас, если это сбой. -Это действительно полезно, если вы используете этот API для результатов тестирования, чтобы случайно не объединить что-то, где последний коммит не прошел тесты. +Это действительно полезно, если вы используете этот API для результатов тестирования, чтобы случайно не объединить что-то, где последний коммит не прошёл тесты. ==== Octokit diff --git a/book/07-git-tools/sections/advanced-merging.asc b/book/07-git-tools/sections/advanced-merging.asc index dc0eb524..cb60c446 100644 --- a/book/07-git-tools/sections/advanced-merging.asc +++ b/book/07-git-tools/sections/advanced-merging.asc @@ -580,7 +580,7 @@ $ git revert -m 1 HEAD .История после `git revert -m 1` image::images/undomerge-revert.png["История после `git revert -m 1`"] -Новый коммит `^M` имеет точно такое же содержимое как `C6`, таким образом, начиная с неё всё выглядит так, как будто слияние никогда не выполнялось, за тем лишь исключением, что «теперь уже не слитые» коммиты всё также присутствуют в истории `HEAD`. +Новый коммит `^M` имеет точно такое же содержимое как `C6`, таким образом, начиная с него всё выглядит так, как будто слияние никогда не выполнялось, за тем лишь исключением, что «теперь уже не слитые» коммиты всё также присутствуют в истории `HEAD`. Git придёт в замешательство, если вы вновь попытаетесь слить `topic` в ветку `master`: [source,console] diff --git a/book/07-git-tools/sections/credentials.asc b/book/07-git-tools/sections/credentials.asc index 78294bde..0bf9aec4 100644 --- a/book/07-git-tools/sections/credentials.asc +++ b/book/07-git-tools/sections/credentials.asc @@ -161,7 +161,7 @@ https://bob:s3cre7@mygithost . Формат файла с совместно используемыми учётными данными такой же как и у `git-credential-store`. . Расположение этого файла более-менее стандартное, но, на всякий случай, мы должны позволять пользователям передавать свой собственный путь. -Мы снова напишем расширение на Ruby, но подойдет любой язык, так как Git может использовать всё, что сможет запустить на выполнение. +Мы снова напишем расширение на Ruby, но подойдёт любой язык, так как Git может использовать всё, что сможет запустить на выполнение. Ниже приведён полный исходный код нашего нового помощника авторизации: [source,ruby] diff --git a/book/07-git-tools/sections/debugging.asc b/book/07-git-tools/sections/debugging.asc index df20b5df..e73e8c56 100644 --- a/book/07-git-tools/sections/debugging.asc +++ b/book/07-git-tools/sections/debugging.asc @@ -73,7 +73,7 @@ ad11ac80 GITPackUpload.m (Scott 2009-03-24 150) Если вы не знаете, что сломано, а с тех пор как код работал, были сделаны десятки или сотни коммитов, вы вероятно воспользуетесь командой `git bisect`. Эта команда выполняет бинарный поиск по истории коммитов для того, чтобы помочь вам как можно быстрее определить коммит, который создал проблему. -Допустим, вы только что развернули некоторую версию вашего кода в боевом окружении и теперь получаете отчёты о некоторой ошибке, которая не возникала в вашем разработческом окружении, и вы не можете представить, почему код ведет себя так. +Допустим, вы только что развернули некоторую версию вашего кода в боевом окружении и теперь получаете отчёты о некоторой ошибке, которая не возникала в вашем разработческом окружении, и вы не можете представить, почему код ведёт себя так. Вы возвращаетесь к вашему коду и выясняете, что можете воспроизвести проблему, но всё ещё не понимаете, что работает неверно. Вы можете воспользоваться бинарным поиском, чтобы выяснить это. Во-первых, выполните команду `git bisect start` для запуска процесса поиска, а затем используйте `git bisect bad`, чтобы сообщить Git, что текущий коммит сломан. diff --git a/book/07-git-tools/sections/interactive-staging.asc b/book/07-git-tools/sections/interactive-staging.asc index 84853f71..18c021cf 100644 --- a/book/07-git-tools/sections/interactive-staging.asc +++ b/book/07-git-tools/sections/interactive-staging.asc @@ -30,7 +30,7 @@ What now> ==== Добавление и удаление файлов из индекса -Если вы введете `2` или `u` в поле ввода `What now>`, скрипт спросит у вас какие файлы вы хотите добавить в индекс: +Если вы введёте `2` или `u` в поле ввода `What now>`, скрипт спросит у вас какие файлы вы хотите добавить в индекс: [source,console] ---- diff --git a/book/07-git-tools/sections/replace.asc b/book/07-git-tools/sections/replace.asc index 48e53c38..37396b5a 100644 --- a/book/07-git-tools/sections/replace.asc +++ b/book/07-git-tools/sections/replace.asc @@ -79,7 +79,7 @@ c1822cf First commit Для того, чтобы сделать это, нам нужно выбрать точку разбиения, которой для нас будет третий коммит, хеш которого `9c68fdc`. Таким образом, наш базовый коммит будет основываться на этом дереве. -Мы можем создать наш базовый коммит, используя команду `commit-tree`, которая просто берет дерево и возвращает SHA-1 объекта, представляющего новый сиротский коммит. +Мы можем создать наш базовый коммит, используя команду `commit-tree`, которая просто берёт дерево и возвращает SHA-1 объекта, представляющего новый сиротский коммит. [source,console] ---- diff --git a/book/07-git-tools/sections/reset.asc b/book/07-git-tools/sections/reset.asc index 4a047ce2..8cf20a72 100644 --- a/book/07-git-tools/sections/reset.asc +++ b/book/07-git-tools/sections/reset.asc @@ -10,7 +10,7 @@ Разобраться с командами `reset` и `checkout` будет проще, если считать, что Git управляет содержимым трёх различных деревьев. Здесь под «деревом» мы понимаем «набор файлов», а не специальную структуру данных. -(В некоторых случаях индекс ведет себя не совсем так, как дерево, но для наших текущих целей его проще представлять именно таким.) +(В некоторых случаях индекс ведёт себя не совсем так, как дерево, но для наших текущих целей его проще представлять именно таким.) В своих обычных операциях Git управляет тремя деревьями: @@ -72,7 +72,7 @@ $ git ls-files -s ===== Рабочий Каталог Наконец, у вас есть рабочий каталог. -Два других дерева сохраняют свое содержимое эффективным, но неудобным способом внутри каталога `.git`. +Два других дерева сохраняют своё содержимое эффективным, но неудобным способом внутри каталога `.git`. Рабочий Каталог распаковывает их в настоящие файлы, что упрощает для вас их редактирование. Считайте Рабочий Каталог *песочницей*, где вы можете опробовать изменения перед их коммитом в индекс (область подготовленных изменений) и затем в историю. @@ -106,7 +106,7 @@ image::images/reset-ex1.png[] image::images/reset-ex2.png[] -Затем, мы выполняем команду `git commit`, которая сохраняет содержимое Индекса как неизменяемый снимок, создает объект коммита, который указывает на этот снимок, и обновляет `master` так, чтобы он тоже указывал на этот коммит. +Затем, мы выполняем команду `git commit`, которая сохраняет содержимое Индекса как неизменяемый снимок, создаёт объект коммита, который указывает на этот снимок, и обновляет `master` так, чтобы он тоже указывал на этот коммит. image::images/reset-ex3.png[] @@ -158,7 +158,7 @@ image::images/reset-soft.png[] При вызове `reset --soft` на этом выполнение команды и остановится. Теперь взгляните на диаграмму и постарайтесь разобраться, что случилось: фактически была отменена последняя команда `git commit`. -Когда вы выполняете `git commit`, Git создает новый коммит и перемещает на него ветку, на которую указывает HEAD. +Когда вы выполняете `git commit`, Git создаёт новый коммит и перемещает на него ветку, на которую указывает HEAD. Если вы выполняете `reset` на `HEAD~` (родителя HEAD), то вы перемещаете ветку туда, где она была раньше, не изменяя при этом ни Индекс, ни Рабочий Каталог. Вы можете обновить Индекс и снова выполнить `git commit`, таким образом добиваясь того же, что делает команда `git commit --amend` (смотрите <>). @@ -173,7 +173,7 @@ image::images/reset-mixed.png[] Если вы указали опцию `--mixed`, выполнение `reset` остановится на этом шаге. Такое поведение также используется по умолчанию, поэтому если вы не указали совсем никаких опций (в нашем случае `git reset HEAD~`), выполнение команды также остановится на этом шаге. -Снова взгляните на диаграмму и постарайтесь разобраться, что произошло: отменен не только ваш последний `commit`, но также и _добавление в индекс_ всех файлов. +Снова взгляните на диаграмму и постарайтесь разобраться, что произошло: отменён не только ваш последний `commit`, но также и _добавление в индекс_ всех файлов. Вы откатились назад до момента выполнения команд `git add` и `git commit`. ===== Шаг 3: Обновление Рабочего Каталога (--hard) @@ -183,7 +183,7 @@ image::images/reset-mixed.png[] image::images/reset-hard.png[] -Давайте разберемся, что сейчас случилось. +Давайте разберёмся, что сейчас случилось. Вы отменили ваш последний коммит, результаты выполнения команд `git add` и `git commit`, а также **все** изменения, которые вы сделали в рабочем каталоге. Важно отметить, что только указание этого флага (`--hard`) делает команду `reset` опасной, это один из немногих случаев, когда Git действительно удаляет данные. @@ -215,7 +215,7 @@ image::images/reset-hard.png[] image::images/reset-path1.png[] -Это создает эффект _отмены индексации_ файла. +Это создаёт эффект _отмены индексации_ файла. Если вы посмотрите на диаграммы этой команды и команды `git add`, то увидите, что их действия прямо противоположные. image::images/reset-path2.png[] @@ -261,7 +261,7 @@ image::images/reset-squash-r3.png[] ==== Сравнение с `checkout` -Наконец, вы можете задаться вопросом, в чем же состоит отличие между `checkout` и `reset`. +Наконец, вы можете задаться вопросом, в чём же состоит отличие между `checkout` и `reset`. Как и `reset`, команда `checkout` управляет тремя деревьями Git, и также её поведение зависит от того указали ли вы путь до файла или нет. ===== Без указания пути diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc index 3bcd29ca..4cffc549 100644 --- a/book/07-git-tools/sections/revision-selection.asc +++ b/book/07-git-tools/sections/revision-selection.asc @@ -11,7 +11,7 @@ Git позволяет различными способами указать к ==== Сокращённый SHA-1 -Git достаточно умен, чтобы понять какой коммит имеется ввиду по нескольким первым символам его хеша, если указанная часть SHA-1 имеет в длину по крайней мере четыре символа и однозначна -- то есть в текущем репозитории существует только один объект с таким частичным SHA-1. +Git достаточно умён, чтобы понять какой коммит имеется ввиду по нескольким первым символам его хеша, если указанная часть SHA-1 имеет в длину по крайней мере четыре символа и однозначна -- то есть в текущем репозитории существует только один объект с таким частичным SHA-1. Например, предположим, чтобы найти некоторый коммит, вы выполнили команду `git log` и нашли коммит, в которой добавили определённую функциональность: @@ -179,7 +179,7 @@ Date: Thu Dec 11 15:08:43 2008 -0800 [TIP] .Воспринимайте reflog Git как историю командной строки ==== -Если у вас есть опыт работы с UNIX или Linux, можете думать о reflog как об истории командной строки Git, которая подчеркивает, что то, что там есть, явно актуально только для вас и вашего «сеанса» и не имеет ничего общего с кем-либо ещё, кто может работать на той же машине. +Если у вас есть опыт работы с UNIX или Linux, можете думать о reflog как об истории командной строки Git, которая подчёркивает, что то, что там есть, явно актуально только для вас и вашего «сеанса» и не имеет ничего общего с кем-либо ещё, кто может работать на той же машине. ==== [NOTE] diff --git a/book/07-git-tools/sections/rewriting-history.asc b/book/07-git-tools/sections/rewriting-history.asc index f49528f7..3b86183b 100644 --- a/book/07-git-tools/sections/rewriting-history.asc +++ b/book/07-git-tools/sections/rewriting-history.asc @@ -33,7 +33,7 @@ $ git commit --amend Когда вы сохраните его и закроете редактор, будет создан новый коммит, содержащий это сообщение, который теперь и будет вашим последним коммитом. Если вы создали коммит и затем хотите изменить зафиксированный снимок, добавив или изменив файлы (возможно, вы забыли добавить вновь созданный файл, когда совершали изначальный коммит), то процесс выглядит в основном так же. -Вы добавляете в индекс необходимые изменения, редактируя файл и выполняя для него `git add` или `git rm` для отслеживаемого файла, а последующая команда `git commit --amend` берет вашу текущую область подготовленных изменений и делает её снимок для нового коммита. +Вы добавляете в индекс необходимые изменения, редактируя файл и выполняя для него `git add` или `git rm` для отслеживаемого файла, а последующая команда `git commit --amend` берёт вашу текущую область подготовленных изменений и делает её снимок для нового коммита. Вы должны быть осторожными, используя этот приём, так как при этом изменяется SHA-1 коммита. Поэтому, как и с операцией `rebase` -- не изменяйте ваш последний коммит, если вы уже отправили его в общий репозиторий. @@ -121,7 +121,7 @@ f7f3f6d Change my name a bit Обратите внимание на обратный порядок. Команда `rebase` в интерактивном режиме предоставит вам скрипт, который она будет выполнять. -Она начнет с коммита, который вы указали в командной строке (`HEAD~3`) и повторит изменения, внесённые каждым из коммитов, сверху вниз. +Она начнёт с коммита, который вы указали в командной строке (`HEAD~3`) и повторит изменения, внесённые каждым из коммитов, сверху вниз. Наверху отображается самый старый коммит, а не самый новый, потому что он будет повторен первым. Вам необходимо изменить скрипт так, чтобы он остановился на коммите, который вы хотите изменить. diff --git a/book/07-git-tools/sections/searching.asc b/book/07-git-tools/sections/searching.asc index 68836c6e..00108fd6 100644 --- a/book/07-git-tools/sections/searching.asc +++ b/book/07-git-tools/sections/searching.asc @@ -12,7 +12,7 @@ Git поставляется с командой `grep`, которая позв В следующих примерах, мы обратимся к исходному коду самого Git. По умолчанию эта команда ищет по файлам в рабочем каталоге. -В качестве первого варианта вы можете использовать любой из параметров `-n` или `--line-number`, чтобы распечатать номера строк, в которых Git нашел совпадения: +В качестве первого варианта вы можете использовать любой из параметров `-n` или `--line-number`, чтобы распечатать номера строк, в которых Git нашёл совпадения: [source,console] ---- diff --git a/book/07-git-tools/sections/signing.asc b/book/07-git-tools/sections/signing.asc index 3a95f551..f407452a 100644 --- a/book/07-git-tools/sections/signing.asc +++ b/book/07-git-tools/sections/signing.asc @@ -2,7 +2,7 @@ === Подпись Благодаря шифрованию система Git является безопасной, но полностью она не защищена. -На случай, если вы берете у кого-то в интернете результаты его работы и хотите проверить, что коммиты действительно получены из доверенного источника, в Git есть несколько способов подписать и проверить исходники, используя GPG. +На случай, если вы берёте у кого-то в интернете результаты его работы и хотите проверить, что коммиты действительно получены из доверенного источника, в Git есть несколько способов подписать и проверить исходники, используя GPG. ==== Введение в GPG diff --git a/book/07-git-tools/sections/stashing-cleaning.asc b/book/07-git-tools/sections/stashing-cleaning.asc index 6307a997..fc34c3e5 100644 --- a/book/07-git-tools/sections/stashing-cleaning.asc +++ b/book/07-git-tools/sections/stashing-cleaning.asc @@ -5,7 +5,7 @@ Сложность при этом заключается в том, что вы не хотите фиксировать наполовину сделанную работу только для того, чтобы иметь возможность вернуться к ней позже. Справиться с ней помогает команда `git stash`. -Операция `stash` берет изменённое состояние вашего рабочего каталога, то есть изменённые отслеживаемые файлы и проиндексированные изменения, и сохраняет их в хранилище незавершённых изменений, которые вы можете в любое время применить обратно. +Операция `stash` берёт изменённое состояние вашего рабочего каталога, то есть изменённые отслеживаемые файлы и проиндексированные изменения, и сохраняет их в хранилище незавершённых изменений, которые вы можете в любое время применить обратно. [NOTE] .Переход на `git stash push` @@ -236,7 +236,7 @@ Dropped refs/stash@{0} (29d385a81d163dfd45a452a2ce816487a6b8b014) Предположим, вы хотите удалить мусор и очистить ваш рабочий каталог; вы можете сделать это с помощью `git clean`. Для удаления всех неотслеживаемых файлов в вашем рабочем каталоге, вы можете выполнить команду `git clean -f -d`, которая удалит все файлы и также все каталоги, которые в результате станут пустыми. -Параметр `-f` (сокращение от слова force -- заставить) означает принудительное удаление, подчеркивая, что вы действительно хотите это сделать, и требуется, если переменная конфигурации Git `clean.requireForce` явным образом не установлена в `false`. +Параметр `-f` (сокращение от слова force -- заставить) означает принудительное удаление, подчёркивая, что вы действительно хотите это сделать, и требуется, если переменная конфигурации Git `clean.requireForce` явным образом не установлена в `false`. Если вы хотите только посмотреть, что будет сделано, вы можете запустить команду с опцией `-n`, которая означает «имитируй работу команды и скажи мне, что ты _будешь_ удалять». @@ -288,7 +288,7 @@ What now> [NOTE] ==== -Существует причудливая ситуация, когда вам, возможно, придется проявить особую настойчивость, попросив Git очистить ваш рабочий каталог. +Существует причудливая ситуация, когда вам, возможно, придётся проявить особую настойчивость, попросив Git очистить ваш рабочий каталог. Если вы оказались в рабочем каталоге, в который вы скопировали или клонировали другие репозитории Git (возможно, в виде подмодулей), даже `git clean -fd` откажется удалить эти каталоги. В таких случаях вам нужно добавить второй параметр `-f` для акцентирования. ==== diff --git a/book/07-git-tools/sections/submodules.asc b/book/07-git-tools/sections/submodules.asc index aa9f8707..e8ceffe1 100644 --- a/book/07-git-tools/sections/submodules.asc +++ b/book/07-git-tools/sections/submodules.asc @@ -479,7 +479,7 @@ Switched to branch 'stable' ---- Давайте попробуем обновить подмодуль путём слияния изменений. -Чтобы задать её вручную, просто добавьте опцию `--merge` при вызове команды `update`. +Чтобы задать их вручную, просто добавьте опцию `--merge` при вызове команды `update`. Ниже мы видим, что с удалённого сервера получен коммит для подмодуля и слит с текущим состоянием: [source,console] @@ -632,7 +632,7 @@ To https://github.com/chaconinc/MainProject 3d6d338..9a377d1 master -> master ---- -Как видите, перед отправкой на сервер основного проекта Git перешел в каталог модуля DbConnector и отправил его изменения на сервер. +Как видите, перед отправкой на сервер основного проекта Git перешёл в каталог модуля DbConnector и отправил его изменения на сервер. Отправка изменений основного репозитория также завершится неудачей если во время отправки изменений подмодуля возникла ошибка. Установить такое поведение по умолчанию можно с помощью команды `git config push.recurseSubmodules on-demand`. @@ -862,7 +862,7 @@ index 1aaefb6..5297645 100644 ===== Полезные псевдонимы Возможно, вы захотите настроить псевдонимы для некоторых из этих команд, так как они могут быть довольно длинными и для большинства из них вы не можете задать значения по умолчанию. -Мы рассмотрели настройку псевдонимов Git в разделе <> главы 2, однако ниже приведен пример, который вы наверняка захотите использовать, если планируете часто работать с подмодулями Git. +Мы рассмотрели настройку псевдонимов Git в разделе <> главы 2, однако ниже приведён пример, который вы наверняка захотите использовать, если планируете часто работать с подмодулями Git. [source,console] ---- diff --git a/book/08-customizing-git/sections/attributes.asc b/book/08-customizing-git/sections/attributes.asc index 94dc3247..8d0203e3 100644 --- a/book/08-customizing-git/sections/attributes.asc +++ b/book/08-customizing-git/sections/attributes.asc @@ -85,7 +85,7 @@ $ git config diff.word.textconv docx2txt Теперь Git знает, что при сравнении двух коммитов, имена файлов в которых заканчиваются на `.docx`, он должен обработать эти файлы с помощью фильтра «word», который определён как программа `docx2txt`. Это позволяет автоматически генерировать текстовые версии файлов Word и только потом их сравнивать. -Для примера, первый раздел этой книги был сохранен в формате Word и добавлен в Git репозиторий. +Для примера, первый раздел этой книги был сохранён в формате Word и добавлен в Git репозиторий. Затем был добавлен новый абзац. Вот что покажет команда `git diff`: @@ -226,7 +226,7 @@ $ git config --global filter.indent.smudge cat Другой интересный пример -- это подстановка ключевого слова `$Date$` в стиле системы контроля ревизий. Чтобы правильно это реализовать, вам нужен простой скрипт, который получает имя файла, определяет дату последнего коммита и вставляет её в файл. -Ниже приведен небольшой пример такого скрипта на Ruby: +Ниже приведён небольшой пример такого скрипта на Ruby: [source,ruby] ---- diff --git a/book/08-customizing-git/sections/policy.asc b/book/08-customizing-git/sections/policy.asc index 5a9a26cc..cd54e549 100644 --- a/book/08-customizing-git/sections/policy.asc +++ b/book/08-customizing-git/sections/policy.asc @@ -106,7 +106,7 @@ end check_message_format ---- -Размещение указанного кода в скрипте `update` приведет к отклонению всех обновлений, в которых содержатся один или несколько коммитов с сообщением, которое не соответствует вашему правилу. +Размещение указанного кода в скрипте `update` приведёт к отклонению всех обновлений, в которых содержатся один или несколько коммитов с сообщением, которое не соответствует вашему правилу. ===== Контроль доступа по списку имён пользователей diff --git a/book/10-git-internals/sections/environment.asc b/book/10-git-internals/sections/environment.asc index 5954f96f..a389a7a9 100644 --- a/book/10-git-internals/sections/environment.asc +++ b/book/10-git-internals/sections/environment.asc @@ -12,7 +12,7 @@ Git всегда запускается в оболочке `bash` и испол *`GIT_EXEC_PATH`* определяет где Git будет искать свои подпрограммы (такие как `git-commit`, `git-diff` и другие). Текущие настройки можно узнать командой `git --exec-path`. -*`HOME`* обычно не рассматривается в качестве изменяемого параметра (чересчур много вещей от него зависят), но именно тут Git ищет глобальный файл конфигурации. +*`HOME`* обычно не рассматривается в качестве изменяемого параметра (чересчур много вещей от неё зависят), но именно тут Git ищет глобальный файл конфигурации. Если вам нужна по-настоящему портируемая версия Git с собственной глобальной конфигурацией, можете переопределить `HOME` в shell профиле. *`PREFIX`* аналогичная константа, но для общесистемной конфигурации. diff --git a/book/preface_schacon.asc b/book/preface_schacon.asc index 2a81f5b4..9c1a49cf 100644 --- a/book/preface_schacon.asc +++ b/book/preface_schacon.asc @@ -2,7 +2,7 @@ == Предисловие Добро пожаловать во второе издание Pro Git. -Первое издание было опубликовано более четырех лет назад. +Первое издание было опубликовано более четырёх лет назад. С тех пор многое изменилось, но многие важные вещи остались неизменны. Хотя большинство ключевых команд и концепций по-прежнему работают, так как команда, разрабатывающая ядро Git, фантастическим образом оставляет всё обратно совместимым, произошло несколько существенных дополнений и изменений в сообществе вокруг Git. Второе издание призвано обозначить эти изменения и обновить книгу для помощи новичкам. @@ -11,7 +11,7 @@ И хотя в некоторых сообществах он уже начинал набирать обороты, ему было далеко до сегодняшней распространённости. С тех пор его приняло практически всё сообщество свободного программного обеспечения. Git достиг невероятного прогресса в Windows, взрывными темпами получил графический интерфейс для всех платформ, поддержку сред разработки и стал использоваться в бизнесе. -Pro Git четырехлетней давности ничего подобного не подозревал. +Pro Git четырёхлетней давности ничего подобного не подозревал. Одна из главных целей издания -- затронуть в Git сообществе эти рубежи. Сообщество свободного программного обеспечения тоже испытало взрывной рост. diff --git a/ch03-git-branching.asc b/ch03-git-branching.asc index e2defacc..7fd4b86d 100644 --- a/ch03-git-branching.asc +++ b/ch03-git-branching.asc @@ -10,7 +10,7 @@ Что в ней такого особенного? Ветвление Git очень легковесно: операция создания ветки выполняется почти мгновенно, переключение между ветками туда-сюда, обычно, также быстро. В отличие от многих других систем контроля версий, Git поощряет процесс работы, при котором ветвление и слияние выполняется часто, даже по несколько раз в день. -Понимание и владение этой функциональностью дает вам уникальный и мощный инструмент, который может полностью изменить привычный процесс разработки. +Понимание и владение этой функциональностью даёт вам уникальный и мощный инструмент, который может полностью изменить привычный процесс разработки. include::book/03-git-branching/sections/nutshell.asc[] diff --git a/ch10-git-internals.asc b/ch10-git-internals.asc index 077be741..4503ece3 100644 --- a/ch10-git-internals.asc +++ b/ch10-git-internals.asc @@ -11,7 +11,7 @@ Довольно скоро станет понятнее, что это значит. На заре развития Git (примерно до версии 1.5) интерфейс был значительно сложнее, поскольку был больше похож на интерфейс доступа к файловой системе, чем на законченную систему контроля версий. -За последние годы, интерфейс значительно очищен и упрощен до уровня аналогов; тем не менее, сохраняется стереотип о том, что интерфейс у Git чересчур сложен и труден для изучения. +За последние годы, интерфейс значительно очищен и упрощён до уровня аналогов; тем не менее, сохраняется стереотип о том, что интерфейс у Git чересчур сложен и труден для изучения. Контентно-адресуемая файловая система -- основа Git, невероятно крута, именно её мы рассмотрим в этой главе в первую очередь; затем вы узнаете о транспортных механизмах и инструментах обслуживания репозитория, с которыми возможно вам придётся столкнуться. From 11eeac05ef612339c2c74ad2fbfc3548d2f3885a Mon Sep 17 00:00:00 2001 From: Dexter Morganov Date: Tue, 10 Sep 2024 00:55:53 +0300 Subject: [PATCH 2/2] =?UTF-8?q?fix:=20=D0=B8=D1=81=D0=BF=D1=80=D0=B0=D0=B2?= =?UTF-8?q?=D0=BB=D0=B5=D0=BD=D0=B8=D0=B5=20=D0=B4=D0=BB=D1=8F=20=D0=B8?= =?UTF-8?q?=D1=81=D0=BF=D1=80=D0=B0=D0=B2=D0=BB=D0=B5=D0=BD=D0=B8=D1=8F?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- book/07-git-tools/sections/submodules.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/07-git-tools/sections/submodules.asc b/book/07-git-tools/sections/submodules.asc index e8ceffe1..c6a96229 100644 --- a/book/07-git-tools/sections/submodules.asc +++ b/book/07-git-tools/sections/submodules.asc @@ -479,7 +479,7 @@ Switched to branch 'stable' ---- Давайте попробуем обновить подмодуль путём слияния изменений. -Чтобы задать их вручную, просто добавьте опцию `--merge` при вызове команды `update`. +Для этого просто добавьте опцию `--merge` при вызове команды `update`. Ниже мы видим, что с удалённого сервера получен коммит для подмодуля и слит с текущим состоянием: [source,console]