From 71b7a1eb5731407bd67feeade4b70eedcf9669a5 Mon Sep 17 00:00:00 2001 From: Viktor Yegay Date: Thu, 1 Feb 2024 22:25:07 +0500 Subject: [PATCH 01/13] =?UTF-8?q?=D0=98=D1=81=D0=BF=D0=BE=D0=BB=D1=8C?= =?UTF-8?q?=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D1=8C=20=D0=B1=D1=83=D0=BA=D0=B2?= =?UTF-8?q?=D1=83=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 d72c6279..fdb997bb 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 edb90608c55f136b2fca6e2dd66c74d59d7a0feb Mon Sep 17 00:00:00 2001 From: Viktor Yegay Date: Thu, 1 Feb 2024 22:43:29 +0500 Subject: [PATCH 02/13] =?UTF-8?q?=D0=98=D1=81=D0=BF=D1=80=D0=B0=D0=B2?= =?UTF-8?q?=D0=B8=D1=82=D1=8C=20=D0=BF=D1=80=D0=BE=D0=B1=D0=B5=D0=BB=D1=8B?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Удалить лишний пробел перед запятой Добавить пробел перед скобкой Удалить замыкающие пробелы Заменить двойные пробелы в одинарные между словами в не в коде --- book/02-git-basics/sections/getting-a-repository.asc | 2 +- book/02-git-basics/sections/recording-changes.asc | 2 +- book/02-git-basics/sections/undoing.asc | 2 +- .../03-git-branching/sections/basic-branching-and-merging.asc | 4 ++-- book/04-git-server/sections/protocols.asc | 2 +- book/06-github/sections/1-setting-up-account.asc | 2 +- book/06-github/sections/3-maintaining.asc | 2 +- book/07-git-tools/sections/advanced-merging.asc | 2 +- book/07-git-tools/sections/replace.asc | 2 +- book/08-customizing-git/sections/policy.asc | 2 +- book/10-git-internals/sections/transfer-protocols.asc | 2 +- book/A-git-in-other-environments/sections/guis.asc | 4 ++-- book/B-embedding-git/sections/jgit.asc | 2 +- ch05-distributed-git.asc | 2 +- 14 files changed, 16 insertions(+), 16 deletions(-) diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index ea5c5326..176a1e83 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -41,7 +41,7 @@ $ git init Подробное описание файлов, содержащихся в только что созданном вами каталоге `.git`, приведено в главе <>(((команды git, init))) Если вы хотите добавить под версионный контроль существующие файлы (в отличие от пустого каталога), вам стоит добавить их в индекс и осуществить первый коммит изменений. -Добиться этого вы сможете запустив команду `git add` несколько раз, указав индексируемые файлы, а затем выполнив `git commit`: +Добиться этого вы сможете запустив команду `git add` несколько раз, указав индексируемые файлы, а затем выполнив `git commit`: [source,console] ---- diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index ea7ba780..13d48dd1 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -168,7 +168,7 @@ Changes not staged for commit: Теперь `CONTRIBUTING.md` отображается как проиндексированный и непроиндексированный одновременно. Как такое возможно? Такая ситуация наглядно демонстрирует, что Git индексирует файл в точности в том состоянии, в котором он находился, когда вы выполнили команду `git add`. -Если вы выполните коммит сейчас, то файл `CONTRIBUTING.md` попадёт в коммит в том состоянии, в котором он находился, когда вы последний раз выполняли команду `git add` , а не в том, в котором он находится в вашем рабочем каталоге в момент выполнения `git commit`. +Если вы выполните коммит сейчас, то файл `CONTRIBUTING.md` попадёт в коммит в том состоянии, в котором он находился, когда вы последний раз выполняли команду `git add`, а не в том, в котором он находится в вашем рабочем каталоге в момент выполнения `git commit`. Если вы изменили файл после выполнения `git add`, вам придётся снова выполнить `git add`, чтобы проиндексировать последнюю версию файла: [source,console] diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc index 3383a04d..54e1bda2 100644 --- a/book/02-git-basics/sections/undoing.asc +++ b/book/02-git-basics/sections/undoing.asc @@ -225,5 +225,5 @@ Changes to be committed: ===== Важно понимать, что `git restore ` -- опасная команда. Любые локальные изменения, внесённые в этот файл, исчезнут -- Git просто заменит файл последней зафиксированной версией. -Никогда не используйте эту команду, если точно не знаете, нужны ли вам эти несохранённые локальные изменения. +Никогда не используйте эту команду, если точно не знаете, нужны ли вам эти несохранённые локальные изменения. ===== 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 0c603f4f..825499a2 100644 --- a/book/03-git-branching/sections/basic-branching-and-merging.asc +++ b/book/03-git-branching/sections/basic-branching-and-merging.asc @@ -53,11 +53,11 @@ $ vim index.html $ git commit -a -m 'Create new footer [issue 53]' ---- -.Ветка iss53 движется вперёд +.Ветка iss53 движется вперёд image::images/basic-branching-3.png["Ветка iss53 двигается вперёд"] И тут вы получаете сообщение об обнаружении на сайте уязвимости, и эту уязвимость устранить нужно немедленно. -Благодаря Git вам не придётся ни пытаться реализовать исправление вместе с изменениями, которые вы сделали в ходе разработки `iss53`, ни прилагать усилия для отката этих изменений и возвращения к исходному состоянию перед началом разработки исправления. +Благодаря Git вам не придётся ни пытаться реализовать исправление вместе с изменениями, которые вы сделали в ходе разработки `iss53`, ни прилагать усилия для отката этих изменений и возвращения к исходному состоянию перед началом разработки исправления. Всё, что вам нужно -- переключиться на ветку `master`. Имейте в виду, что если рабочий каталог или индекс содержат незафиксированные изменения, конфликтующие с веткой, на которую вы хотите переключиться, то Git не позволит переключить ветки. diff --git a/book/04-git-server/sections/protocols.asc b/book/04-git-server/sections/protocols.asc index 6dda2dbd..831ddf61 100644 --- a/book/04-git-server/sections/protocols.asc +++ b/book/04-git-server/sections/protocols.asc @@ -90,7 +90,7 @@ Git может работать через HTTP в двух различных Если сервер не отвечает на умный запрос Git по HTTP, клиент Git попытается откатиться на более простой _Тупой_ HTTP-протокол. Тупой протокол ожидает, что голый репозиторий Git будет обслуживаться веб-сервером как набор файлов. Прелесть тупого протокола HTTP -- в простоте настройки. -По сути, всё, что необходимо сделать -- поместить голый репозиторий в корневой каталог HTTP и установить обработчик `post-update`(смотри <>). +По сути, всё, что необходимо сделать -- поместить голый репозиторий в корневой каталог HTTP и установить обработчик `post-update` (смотри <>). Теперь каждый может клонировать репозиторий, если имеет доступ к веб-серверу, на котором он был размещен. Таким образом, чтобы открыть доступ на чтение к вашему репозиторию посредством HTTP, нужно сделать что-то наподобие этого: diff --git a/book/06-github/sections/1-setting-up-account.asc b/book/06-github/sections/1-setting-up-account.asc index 0babfa61..a2f67824 100644 --- a/book/06-github/sections/1-setting-up-account.asc +++ b/book/06-github/sections/1-setting-up-account.asc @@ -69,7 +69,7 @@ image::images/avatar-crop.png["Редактирование загруженно ==== Ваши почтовые адреса GitHub использует ваш почтовый адрес для привязки ваших Git коммитов к вашей учётной записи. -Если вы используете несколько почтовых адресов в своих коммитах и хотите, чтобы GitHub работал с ними корректно, то вам нужно будет добавить все используемые почтовые адреса в секцию под названием «Почтовые адреса» («Emails»), расположенную на вкладке «Администрирование» («Admin»). +Если вы используете несколько почтовых адресов в своих коммитах и хотите, чтобы GitHub работал с ними корректно, то вам нужно будет добавить все используемые почтовые адреса в секцию под названием «Почтовые адреса» («Emails»), расположенную на вкладке «Администрирование» («Admin»). [[r_add_email_addresses]] .Почтовые адреса diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index 1f2130c0..edd2913c 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -27,7 +27,7 @@ image::images/newrepoform.png["Форма «New repository»"] Здесь мы не будем этого делать; если вам нужно освежить память, смотрите главу <>. Теперь ваш проект хостится на GitHub и вы можете предоставить ссылку на него любому желающему. -Все проекты на GitHub доступны как по HTTP `\https://github.com//`, так по SSH `\git@github.com:/`. +Все проекты на GitHub доступны как по HTTP `\https://github.com//`, так по SSH `\git@github.com:/`. Git может получать и отправлять изменения по обоим указанным ссылкам, при этом производится контроль доступа на основании учётных данных пользователя, осуществляющего подключение. [NOTE] diff --git a/book/07-git-tools/sections/advanced-merging.asc b/book/07-git-tools/sections/advanced-merging.asc index cb60c446..950b29a2 100644 --- a/book/07-git-tools/sections/advanced-merging.asc +++ b/book/07-git-tools/sections/advanced-merging.asc @@ -22,7 +22,7 @@ Git упрощает повторные слияния с одной и той Если при выполнении слияния вы не сохраните сделанные изменения, то некоторые из описанных ниже приёмов могут привести к утрате этих наработок. Давайте рассмотрим очень простой пример. -Допустим, у нас есть файл с исходниками на Ruby, выводящими на экран строку 'hello world'. +Допустим, у нас есть файл с исходниками на Ruby, выводящими на экран строку 'hello world'. [source,ruby] ---- diff --git a/book/07-git-tools/sections/replace.asc b/book/07-git-tools/sections/replace.asc index 37396b5a..d036602f 100644 --- a/book/07-git-tools/sections/replace.asc +++ b/book/07-git-tools/sections/replace.asc @@ -112,7 +112,7 @@ Applying: fifth commit image::images/replace4.png[] Таким образом, мы переписали нашу свежую историю поверх вспомогательного базового коммита, который теперь содержит инструкции о том, как при необходимости восстановить полную историю. -Мы можем отправить эту историю в новый проект и теперь, когда люди клонируют его репозиторий, они будут видеть только два свежих коммита и после них базовый коммит с инструкциями. +Мы можем отправить эту историю в новый проект и теперь, когда люди клонируют его репозиторий, они будут видеть только два свежих коммита и после них базовый коммит с инструкциями. Давайте представим себя на месте кого-то, кто впервые клонировал проект и хочет получить полную историю. Для получения исторических данных после клонирования усечённого репозитория, ему нужно добавить в список удалённых репозиториев исторический репозиторий и извлечь из него данные: diff --git a/book/08-customizing-git/sections/policy.asc b/book/08-customizing-git/sections/policy.asc index cd54e549..5683aefa 100644 --- a/book/08-customizing-git/sections/policy.asc +++ b/book/08-customizing-git/sections/policy.asc @@ -376,7 +376,7 @@ access = get_acl_access_data('.git/acl') Второе отличие состоит в способе получения списка изменённых файлов. Если на сервере метод извлекает его из истории коммитов, то в данный момент на стороне клиента коммит ещё не создан, поэтому извлекать этот список необходимо из индекса. -Вместо +Вместо [source,ruby] ---- diff --git a/book/10-git-internals/sections/transfer-protocols.asc b/book/10-git-internals/sections/transfer-protocols.asc index c5d4012f..4db28ddc 100644 --- a/book/10-git-internals/sections/transfer-protocols.asc +++ b/book/10-git-internals/sections/transfer-protocols.asc @@ -272,7 +272,7 @@ $ ssh -x git@server "git-upload-pack 'simplegit-progit.git'" 0000 ---- -Это очень похоже на использование `git-upload-pack` по SSH, вот только обмен данными производится отдельным запросом: +Это очень похоже на использование `git-upload-pack` по SSH, вот только обмен данными производится отдельным запросом: [source] ---- diff --git a/book/A-git-in-other-environments/sections/guis.asc b/book/A-git-in-other-environments/sections/guis.asc index 15f8a88f..2ac563e0 100644 --- a/book/A-git-in-other-environments/sections/guis.asc +++ b/book/A-git-in-other-environments/sections/guis.asc @@ -31,8 +31,8 @@ Gitk принимает много различных опций, большин Возможно, наиболее полезная опция -- `--all`, которая указывает Gitk выводить коммиты, доступные из _любой_ ссылки, а не только HEAD. Интерфейс Gitk выглядит так: -.`gitk`- инструмент для просмотра истории -image::images/gitk.png["`gitk`- инструмент для просмотра истории"] +.`gitk`- инструмент для просмотра истории +image::images/gitk.png["`gitk`- инструмент для просмотра истории"] Интерфейс на картинке похож на вывод `git log --graph`; каждая точка соответствует коммиту, линии отражают родство коммитов, а ссылки изображены цветными прямоугольниками. Жёлтая точка обозначает HEAD, а красная -- изменения, которые попадут в следующий коммит. diff --git a/book/B-embedding-git/sections/jgit.asc b/book/B-embedding-git/sections/jgit.asc index 43d1e7b7..4931a46d 100644 --- a/book/B-embedding-git/sections/jgit.asc +++ b/book/B-embedding-git/sections/jgit.asc @@ -155,6 +155,6 @@ for (Ref ref : remoteRefs) { Это лишь небольшой пример всех возможностей JGit. Если вы заинтересованы в более детальной работе с JGit, вот список источников информации для старта: -* Официальная документация по JGit API доступна в Интернете на https://www.eclipse.org/jgit/documentation[^]. +* Официальная документация по JGit API доступна в Интернете на https://www.eclipse.org/jgit/documentation[^]. Это обыкновенный Javadoc, так что ваша любимая IDE может скачать её и использовать оффлайн. * «Поваренная книга» JGit, расположенная по адресу https://github.com/centic9/jgit-cookbook[^], включает в себя много готовых рецептов использования JGit для решения тех или иных задач. diff --git a/ch05-distributed-git.asc b/ch05-distributed-git.asc index 67b08444..af09b714 100644 --- a/ch05-distributed-git.asc +++ b/ch05-distributed-git.asc @@ -16,5 +16,5 @@ include::book/05-distributed-git/sections/maintaining.asc[] === Заключение Теперь вы должны чувствовать себя достаточно свободно как внося свой вклад в проект под управлением Git, так и занимаясь поддержкой своего собственного проекта или интегрированием наработок других пользователей. -Поздравляем, вы опытный Git-разработчик! +Поздравляем, вы опытный Git-разработчик! В следующей главе вы узнаете о том, как использовать самый большой и самый популярный Git хостинг -- GitHub. From 4113bb1d17828d3a51ee48dbff6c97c6d7dfe582 Mon Sep 17 00:00:00 2001 From: Viktor Yegay Date: Thu, 1 Feb 2024 22:50:10 +0500 Subject: [PATCH 03/13] =?UTF-8?q?=D0=97=D0=B0=D0=BC=D0=B5=D0=BD=D0=B8?= =?UTF-8?q?=D1=82=D1=8C=20=D1=87=D1=91=D1=80=D1=82=D0=BE=D1=87=D0=BA=D0=B8?= =?UTF-8?q?=20=D0=BD=D0=B0=20=D1=82=D0=B8=D1=80=D0=B5?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- book/06-github/sections/2-contributing.asc | 2 +- book/06-github/sections/3-maintaining.asc | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index 11676e44..63f21e17 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -291,7 +291,7 @@ To https://github.com/tonychacon/blink .Запрос слияния без конфликтов image::images/pr-02-merge-fix.png["PR fixed"] -Одна из замечательных особенностей Git - это то, что вы можете делать это постоянно. +Одна из замечательных особенностей Git -- это то, что вы можете делать это постоянно. Если у вас очень длительный проект, вы можете легко сливать изменения из целевой ветки снова и снова и иметь дело только с конфликтами, возникшими с момента вашего последнего слияния, что делает процесс очень управляемым. Если вы очень хотите перебазировать ветку, чтобы её почистить, то, конечно, вы можете это сделать, но настоятельно не рекомендуется переписывать ветку, к которой уже открыт запрос на слияние. diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index edd2913c..eb455781 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -287,7 +287,7 @@ image::images/maint-08-notifications-page.png["Центр уведомлений ====== Email уведомления -Email уведомления - это ещё один способ, которым вы можете получать уведомления от GitHub. +Email уведомления -- это ещё один способ, которым вы можете получать уведомления от GitHub. Если эта опция включена, то вы будете получать по письму на каждое уведомление. Примеры вы видели в разделах <> и <>. Письма объединяются в цепочки, что очень удобно при использовании соответствующего почтового клиента. @@ -324,7 +324,7 @@ X-GitHub-Recipient-Address: tchacon@example.com ==== README -Первый - это файл `README`, он может быть в любом формате, который GitHub в состоянии распознать. +Первый -- это файл `README`, он может быть в любом формате, который GitHub в состоянии распознать. Например, это может быть `README`, `README.md`, `README.asciidoc` и так далее. Если GitHub увидит такой файл в вашем исходном коде, то отобразит его на заглавной странице проекта. @@ -341,7 +341,7 @@ X-GitHub-Recipient-Address: tchacon@example.com ==== CONTRIBUTING -Следующий файл - это `CONTRIBUTING`. +Следующий файл -- это `CONTRIBUTING`. Если в вашем репозитории будет файл `CONTRIBUTING` с любым расширением, то GitHub будет показывать ссылку на него при создании любого запроса на слияние. [[r_contrib_file]] From a88aceeed5cfdbce8da2e8aeb942ada65e62abe7 Mon Sep 17 00:00:00 2001 From: Viktor Yegay Date: Thu, 1 Feb 2024 23:02:52 +0500 Subject: [PATCH 04/13] =?UTF-8?q?=D0=9E=D1=82=D1=84=D0=BE=D1=80=D0=BC?= =?UTF-8?q?=D0=B0=D1=82=D0=B8=D1=80=D0=BE=D0=B2=D0=B0=D1=82=D1=8C=20=D1=82?= =?UTF-8?q?=D0=B0=D0=B1=D0=BB=D0=B8=D1=86=D1=8B?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Выровнена шапка таблиц и первая колонка --- C-git-commands.asc | 4 ++-- book/02-git-basics/sections/viewing-history.asc | 12 ++++++------ book/07-git-tools/sections/credentials.asc | 4 ++-- book/07-git-tools/sections/reset.asc | 12 ++++++------ 4 files changed, 16 insertions(+), 16 deletions(-) diff --git a/C-git-commands.asc b/C-git-commands.asc index 80e7a34d..9b645c87 100644 --- a/C-git-commands.asc +++ b/C-git-commands.asc @@ -47,9 +47,9 @@ Согласно инструкциям, приведённым в разделе <> главы 1, большинство редакторов может быть установлено следующим образом: .Исчерпывающий список команд по настройке `core.editor` -[cols="1,2",options="header"] +[cols="^.^1,2",options="header"] |============================== -|Редактор | Команда +|Редактор ^.^| Команда |Atom |`git config --global core.editor "atom --wait"` |BBEdit (Mac, with command line tools) |`git config --global core.editor "bbedit -w"` |Emacs |`git config --global core.editor emacs` diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index 82ad4d95..b41d20cf 100644 --- a/book/02-git-basics/sections/viewing-history.asc +++ b/book/02-git-basics/sections/viewing-history.asc @@ -159,9 +159,9 @@ a11bef0 - Scott Chacon, 6 years ago : Initial commit [[rpretty_format]] .Полезные опции для `git log --pretty=format` -[cols="1,4",options="header"] +[cols="^.^1,4",options="header"] |================================ -| Опция | Описания вывода +| Опция ^.^| Описания вывода | `%H` | Хеш коммита | `%h` | Сокращённый хеш коммита | `%T` | Хеш дерева @@ -209,9 +209,9 @@ $ git log --pretty=format:"%h %s" --graph [[rlog_options]] .Наиболее распространённые опции для команды `git log` -[cols="1,4",options="header"] +[cols="^.^1,4",options="header"] |================================ -| Опция | Описание +| Опция ^.^| Описание | `-p` | Показывает патч для каждого коммита. | `--stat` | Показывает статистику изменённых файлов для каждого коммита. | `--shortstat` | Отображает только строку с количеством изменений/вставок/удалений для команды --stat. @@ -271,9 +271,9 @@ $ git log -- path/to/file [[rlimit_options]] .Опции для ограничения вывода команды `git log` -[cols="2,4",options="header"] +[cols="^.^2,4",options="header"] |================================ -| Опция | Описание +| Опция ^.^| Описание | `-(n)` | Показывает только последние n коммитов. | `--since`, `--after` | Показывает только те коммиты, которые были сделаны после указанной даты. | `--until`, `--before` | Показывает только те коммиты, которые были сделаны до указанной даты. diff --git a/book/07-git-tools/sections/credentials.asc b/book/07-git-tools/sections/credentials.asc index 0bf9aec4..7ae649d0 100644 --- a/book/07-git-tools/sections/credentials.asc +++ b/book/07-git-tools/sections/credentials.asc @@ -94,9 +94,9 @@ password=s3cre7 В действительности, система управления учётными данными вызывает программы, отделённые от самого Git; какие и как зависит в том числе и от настроек `credential.helper`. Существует несколько вариантов вызова: -[options="header"] +[options="header", cols="^.^,"] |====== -| Настройки | Поведение +| Настройки ^.^| Поведение | `foo` | Выполняется `git-credential-foo` | `foo -a --opt=bcd` | Выполняется `git-credential-foo -a --opt=bcd` | `/absolute/path/foo -xyz` | Выполняется `/absolute/path/foo -xyz` diff --git a/book/07-git-tools/sections/reset.asc b/book/07-git-tools/sections/reset.asc index 8cf20a72..e2f502e2 100644 --- a/book/07-git-tools/sections/reset.asc +++ b/book/07-git-tools/sections/reset.asc @@ -14,9 +14,9 @@ В своих обычных операциях Git управляет тремя деревьями: -[cols="1,2",options="header"] +[cols="^.^1,2",options="header"] |================================ -| Дерево | Назначение +| Дерево ^.^| Назначение | HEAD | Снимок последнего коммита, родитель следующего | Индекс | Снимок следующего намеченного коммита | Рабочий Каталог | Песочница @@ -304,15 +304,15 @@ image::images/reset-checkout.png[] В столбце «HEAD» указывается «REF» если эта команда перемещает ссылку (ветку), на которую HEAD указывает, и «HEAD» если перемещается только сам HEAD. Обратите особое внимание на столбец «Сохранность рабочего каталога?» -- если в нём указано *НЕТ*, то хорошенько подумайте прежде чем выполнить эту команду. -[options="header", cols="3,1,1,1,1"] +[options="header", cols="3,^.^1,^.^1,^.^1,^.^1"] |================================ -| | HEAD | Индекс | Рабочий Каталог | Сохранность рабочего каталога? -| *На уровне коммитов* | | | | +^.^| Команда | HEAD | Индекс | Рабочий Каталог | Сохранность рабочего каталога? +^.^| *На уровне коммитов* | | | | | `reset --soft [коммит]` | REF | НЕТ | НЕТ | ДА | `reset [коммит]` | REF | ДА | НЕТ | ДА | `reset --hard [коммит]` | REF | ДА | ДА | *НЕТ* | `checkout [коммит]` | HEAD | ДА | ДА | ДА -| *На уровне файлов* | | | | +^.^| *На уровне файлов* | | | | | `reset (коммит) [путь]` | НЕТ | ДА | НЕТ | ДА | `checkout (коммит) [путь]` | НЕТ | ДА | ДА | *НЕТ* |================================ From 822430508d841d945cd4cbb2c160d73d581465d1 Mon Sep 17 00:00:00 2001 From: Viktor Yegay Date: Fri, 2 Feb 2024 01:18:12 +0500 Subject: [PATCH 05/13] =?UTF-8?q?=D0=98=D1=81=D0=BF=D1=80=D0=B0=D0=B2?= =?UTF-8?q?=D0=B8=D1=82=D1=8C=20=D0=B2=D1=8B=D0=B4=D0=B5=D0=BB=D0=B5=D0=BD?= =?UTF-8?q?=D0=B8=D0=B5=20=D1=86=D0=B2=D0=B5=D1=82=D0=BE=D0=BC?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --date=option -> выделение цветом --hard - выделение цветом --mixed -> выделение цветом --stat -> выделение цветом "detached HEAD" -> убрать выделение цветом @{5} -> выделение цветом ` --create` -> выделение цветом apply -> выделение цветом bash или csh -> выделение цветом C2, C3 -> выделение цветом C2, C3, C4 -> выделение цветом C2, C3, C4, C6, C7 -> выделение цветом C4 -> выделение цветом C4, C4 -> выделение цветом C4 -> выделение цветом LF и CRLF -> не нужно выделять цветом iss53 -> выделение цветом (рисунок) oneline, short, full, fuller и format -> выделение цветом myProject.trunk -> выделение цветом myProject.work -> выделение цветом trunk -> выдение цветом stdout -> выделение цветом pom.xml -> выделение цветом simplegit.rb -> выделение цветом old -> выделение цветом git push origin old:new -> выделение цветом git push --dry-run origin branch -> выделение цветом git push origin :branch-to-delete -> выделение цветом git reset -> выделение цветом index.html -> выделение цветом push -> выделение цветом TODO -> выделение цветом reflog -> выделение цветом README -> выделение цветом HEAD -> выделение цветом git-credential = выделение цветом git-credential-store = выделение цветом v1.0, v2.0 -> выделение цветом и дополнить v1.0.1 -> выделение цветом v1.8.0 -> выделение цветом fast-import -> выделение цветом DbConnector -> выделение цветом (%s) -> выделение цветом --- book/02-git-basics/sections/recording-changes.asc | 2 +- book/02-git-basics/sections/tagging.asc | 2 +- book/02-git-basics/sections/undoing.asc | 2 +- book/02-git-basics/sections/viewing-history.asc | 6 +++--- .../sections/basic-branching-and-merging.asc | 4 ++-- book/03-git-branching/sections/nutshell.asc | 2 +- book/03-git-branching/sections/rebasing.asc | 8 ++++---- book/04-git-server/sections/setting-up-server.asc | 2 +- book/05-distributed-git/sections/maintaining.asc | 6 +++--- book/07-git-tools/sections/credentials.asc | 8 ++++---- book/07-git-tools/sections/interactive-staging.asc | 8 ++++---- book/07-git-tools/sections/reset.asc | 4 ++-- book/07-git-tools/sections/revision-selection.asc | 4 ++-- book/07-git-tools/sections/submodules.asc | 10 +++++----- book/09-git-and-other-scms/sections/client-bzr.asc | 6 +++--- book/09-git-and-other-scms/sections/client-hg.asc | 2 +- book/09-git-and-other-scms/sections/client-svn.asc | 2 +- book/09-git-and-other-scms/sections/import-bzr.asc | 2 +- book/09-git-and-other-scms/sections/import-custom.asc | 10 +++++----- book/A-git-in-other-environments/sections/bash.asc | 2 +- book/B-embedding-git/sections/jgit.asc | 4 ++-- book/B-embedding-git/sections/libgit2.asc | 2 +- 22 files changed, 49 insertions(+), 49 deletions(-) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 13d48dd1..4ac553df 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -64,7 +64,7 @@ nothing added to commit but untracked files present (use "git add" to track) Понять, что новый файл `README` неотслеживаемый можно по тому, что он находится в секции «Untracked files» в выводе команды `status`. Статус `Untracked` означает, что Git видит файл, которого не было в предыдущем снимке состояния (коммите); Git не станет добавлять его в ваши коммиты, пока вы его явно об этом не попросите. Это предохранит вас от случайного добавления в репозиторий сгенерированных бинарных файлов или каких-либо других, которые вы и не думали добавлять. -Мы хотели добавить README, так давайте сделаем это. +Мы хотели добавить `README`, так давайте сделаем это. [[r_tracking_files]] ==== Отслеживание новых файлов diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index ae33a9bd..bb9e19d5 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -3,7 +3,7 @@ (((теги))) Как и большинство других систем контроля версий, Git имеет возможность помечать определённые моменты в истории как важные. -Как правило, эта функциональность используется для отметки моментов выпуска версий (v1.0, и т. п.). +Как правило, эта функциональность используется для отметки моментов выпуска версий (`v1.0`, `v2.0` и т. п.). Такие пометки в Git называются тегами. В этом разделе вы узнаете, как посмотреть имеющиеся теги, как создать новые или удалить существующие, а также какие типы тегов существуют в Git. diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc index 54e1bda2..c6ea2cf4 100644 --- a/book/02-git-basics/sections/undoing.asc +++ b/book/02-git-basics/sections/undoing.asc @@ -145,7 +145,7 @@ Changes to be committed: ==== Отмена действий с помощью git restore Git версии 2.23.0 представил новую команду: `git restore`. -По сути, это альтернатива git reset, которую мы только что рассмотрели. +По сути, это альтернатива `git reset`, которую мы только что рассмотрели. Начиная с версии 2.23.0, Git будет использовать `git restore` вместо `git reset` для многих операций отмены. Давайте проследим наши шаги и отменим действия с помощью `git restore` вместо `git reset`. diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index b41d20cf..12fbecd1 100644 --- a/book/02-git-basics/sections/viewing-history.asc +++ b/book/02-git-basics/sections/viewing-history.asc @@ -170,7 +170,7 @@ a11bef0 - Scott Chacon, 6 years ago : Initial commit | `%p` | Сокращённый хеш родителей | `%an` | Имя автора | `%ae` | Электронная почта автора -| `%ad` | Дата автора (формат даты можно задать опцией --date=option) +| `%ad` | Дата автора (формат даты можно задать опцией `--date=option`) | `%ar` | Относительная дата автора | `%cn` | Имя коммитера | `%ce` | Электронная почта коммитера @@ -214,13 +214,13 @@ $ git log --pretty=format:"%h %s" --graph | Опция ^.^| Описание | `-p` | Показывает патч для каждого коммита. | `--stat` | Показывает статистику изменённых файлов для каждого коммита. -| `--shortstat` | Отображает только строку с количеством изменений/вставок/удалений для команды --stat. +| `--shortstat` | Отображает только строку с количеством изменений/вставок/удалений для команды `--stat`. | `--name-only` | Показывает список изменённых файлов после информации о коммите. | `--name-status` | Показывает список файлов, которые добавлены/изменены/удалены. | `--abbrev-commit` | Показывает только несколько символов SHA-1 чек-суммы вместо всех 40. | `--relative-date` | Отображает дату в относительном формате (например, «2 weeks ago») вместо стандартного формата даты. | `--graph` | Отображает ASCII граф с ветвлениями и историей слияний. -| `--pretty` | Показывает коммиты в альтернативном формате. Возможные варианты опций: oneline, short, full, fuller и format (с помощью последней можно указать свой формат). +| `--pretty` | Показывает коммиты в альтернативном формате. Возможные варианты опций: `oneline`, `short`, `full`, `fuller` и `format` (с помощью последней можно указать свой формат). | `--oneline` | Сокращение для одновременного использования опций `--pretty=oneline --abbrev-commit`. |================================ 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 825499a2..e48b7d0d 100644 --- a/book/03-git-branching/sections/basic-branching-and-merging.asc +++ b/book/03-git-branching/sections/basic-branching-and-merging.asc @@ -53,8 +53,8 @@ $ 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`, ни прилагать усилия для отката этих изменений и возвращения к исходному состоянию перед началом разработки исправления. diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index 449097e4..b7e84c50 100644 --- a/book/03-git-branching/sections/nutshell.asc +++ b/book/03-git-branching/sections/nutshell.asc @@ -205,6 +205,6 @@ $ git log --oneline --decorate --graph --all - Переключиться на существующую ветку: `git switch testing-branch`. - Создать новую ветку и переключиться на неё: `git switch -c new-branch`. -Флаг `-c` означает создание, но также можно использовать полный формат:` --create`. +Флаг `-c` означает создание, но также можно использовать полный формат: `--create`. - Вернуться к предыдущей извлечённой ветке: `git switch -`. ==== diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc index 9e9ab6fa..effc0b39 100644 --- a/book/03-git-branching/sections/rebasing.asc +++ b/book/03-git-branching/sections/rebasing.asc @@ -191,9 +191,9 @@ image::images/perils-of-rebasing-4.png["Вы снова выполняете с К примеру, если в предыдущем сценарии вместо слияния в <> мы выполним `git rebase teamone/master`, Git будет: -* Определять, какая работа уникальна для вашей ветки (C2, C3, C4, C6, C7) -* Определять, какие коммиты не были коммитами слияния (C2, C3, C4) -* Определять, что не было перезаписано в основной ветке (только C2 и C3, поскольку C4 -- это тот же патч, что и C4') +* Определять, какая работа уникальна для вашей ветки (`C2`, `C3`, `C4`, `C6`, `C7`) +* Определять, какие коммиты не были коммитами слияния (`C2`, `C3`, `C4`) +* Определять, что не было перезаписано в основной ветке (только `C2` и `C3`, поскольку `C4` -- это тот же патч, что и `C4'`) * Применять эти коммиты к ветке `teamone/master` Таким образом, вместо результата, который мы можем наблюдать на <>, у нас получилось бы что-то вроде <>. @@ -203,7 +203,7 @@ image::images/perils-of-rebasing-4.png["Вы снова выполняете с image::images/perils-of-rebasing-5.png["Перемещение в начало force-pushed перемещённой работы"] Это возможно, если `C4` и `C4'` фактически являются одним и тем же патчем, который был сделан вашим коллегой. -В противном случае `rebase` не сможет определить дубликат и создаст ещё один патч, подобный C4 (который с большой вероятностью не удастся применить чисто, поскольку в нём уже присутствуют некоторые изменения). +В противном случае `rebase` не сможет определить дубликат и создаст ещё один патч, подобный `C4` (который с большой вероятностью не удастся применить чисто, поскольку в нём уже присутствуют некоторые изменения). Вы можете это упростить, применив `git pull --rebase` вместо обычного `git pull`. Или сделать это вручную с помощью `git fetch`, а затем `git rebase teamone/master`. diff --git a/book/04-git-server/sections/setting-up-server.asc b/book/04-git-server/sections/setting-up-server.asc index e83f2fd7..50e6733f 100644 --- a/book/04-git-server/sections/setting-up-server.asc +++ b/book/04-git-server/sections/setting-up-server.asc @@ -90,7 +90,7 @@ $ git push origin master Вы можете легко ограничить пользователя `git` только действиями, связанными с Git, с помощью ограниченной оболочки `git-shell`, поставляемой вместе с Git. Если указать её в качестве командного интерпретатора для пользователя `git`, то он не сможет получить доступ к обычной командной оболочке на вашем сервере. -Для её использования, укажите `git-shell` вместо bash или csh для пользователя `git`. +Для её использования, укажите `git-shell` вместо `bash` или `csh` для пользователя `git`. Для этого вы должны сначала добавить `git-shell` в `/etc/shells` если её там ещё нет: [source,console] diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 5ee2dd48..78d7ac25 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -35,7 +35,7 @@ $ git checkout -b sc/ruby_client master Если вы получили патч по почте и его нужно интегрировать в проект, то следует проанализировать его, применив сначала в тематической ветке. Существует два варианта применения полученного по почте патча: `git apply` или `git am`. -===== Применение патча командой apply +===== Применение патча командой `apply` (((команды git, apply))) Если полученный по почте патч был создан командой `git diff` или Unix командой `diff` (что не рекомендуется делать), то применить его можно командой `git apply`. @@ -533,7 +533,7 @@ $ git archive master --prefix='project/' --format=zip > `git describe master`.zi (((команды git, shortlog))) Сейчас самое время оповестить людей из списка рассылки, которые хотят знать что происходит с вашим проектом. С помощью команды `git shortlog` можно быстро получить список изменений, внесённых в проект с момента последнего релиза или предыдущей рассылки. -Она собирает все коммиты в заданном интервале; например, следующая команда выведет список коммитов с момента последнего релиза с названием v1.0.1: +Она собирает все коммиты в заданном интервале; например, следующая команда выведет список коммитов с момента последнего релиза с названием `v1.0.1`: [source,console] ---- @@ -553,4 +553,4 @@ Tom Preston-Werner (4): Regenerated gemspec for version 1.0.2 ---- -И так, у вас есть готовая к отправке сводка коммитов начиная с версии v1.0.1, сгруппированных по авторам. +И так, у вас есть готовая к отправке сводка коммитов начиная с версии `v1.0.1`, сгруппированных по авторам. diff --git a/book/07-git-tools/sections/credentials.asc b/book/07-git-tools/sections/credentials.asc index 7ae649d0..cf01d947 100644 --- a/book/07-git-tools/sections/credentials.asc +++ b/book/07-git-tools/sections/credentials.asc @@ -85,10 +85,10 @@ password=s3cre7 ---- <1> Это команда, которая начинает взаимодействие. -<2> После этого Git-credential ожидает данные из стандартного потока ввода. +<2> После этого `git-credential` ожидает данные из стандартного потока ввода. Мы передаём ему то, что знаем: протокол и имя сервера. <3> Пустая строка обозначает, что ввод закончен и система управления учётными данными должна ответить, что ей известно. -<4> После этого Git-credential выполняет какую-то работу и выводит обнаруженную информацию. +<4> После этого `git-credential` выполняет какую-то работу и выводит обнаруженную информацию. <5> Если учётные данные не найдены, Git спрашивает у пользователя логин/пароль, и выводит их обратно в задействованный поток вывода (в данном примере это одна и та же консоль). В действительности, система управления учётными данными вызывает программы, отделённые от самого Git; какие и как зависит в том числе и от настроек `credential.helper`. @@ -105,7 +105,7 @@ password=s3cre7 Итак, помощники, описанные выше на самом деле называются `git-credential-cache`, `git-credential-store` и т. д. и мы можем настроить их на приём аргументов командной строки. Общая форма для этого `git-credential-foo [args] `. -Протокол ввода/вывода такой же как и у git-credential, но они используют немного другой набор операций: +Протокол ввода/вывода такой же как и у `git-credential`, но они используют немного другой набор операций: * `get` запрос логина и пароля. * `store` запрос на сохранение учётных данных в памяти помощника. @@ -116,7 +116,7 @@ password=s3cre7 Если помощник не знает что-либо полезного, он может просто завершить работу не выводя ничего, но если знает -- он должен добавить к введённой информации имеющуюся у него информацию. Вывод обрабатывается как набор операций присваивания; выведенные значения заменят те, что Git знал до этого. -Ниже приведён пример, используемый ранее, но вместо git-credential напрямую вызывается git-credential-store: +Ниже приведён пример, используемый ранее, но вместо `git-credential` напрямую вызывается `git-credential-store`: [source,console] ---- diff --git a/book/07-git-tools/sections/interactive-staging.asc b/book/07-git-tools/sections/interactive-staging.asc index 18c021cf..f09eb13d 100644 --- a/book/07-git-tools/sections/interactive-staging.asc +++ b/book/07-git-tools/sections/interactive-staging.asc @@ -42,7 +42,7 @@ What now> u Update>> ---- -Для добавления в индекс файлов TODO и index.html, вы можете ввести их номера: +Для добавления в индекс файлов TODO и `index.html`, вы можете ввести их номера: [source,console] ---- @@ -72,8 +72,8 @@ What now> s 3: unchanged +5/-1 lib/simplegit.rb ---- -Как вы можете заметить, сейчас файлы TODO и index.html добавлены в индекс, а файл simplegit.rb всё ещё нет. -Если вы в этот момент хотите исключить файл TODO из индекса, вы можете использовать опции `3` или `r` (для выполнения revert): +Как вы можете заметить, сейчас файлы `TODO` и `index.html` добавлены в индекс, а файл `simplegit.rb` всё ещё нет. +Если вы в этот момент хотите исключить файл `TODO` из индекса, вы можете использовать опции `3` или `r` (для выполнения revert): [source,console] ---- @@ -140,7 +140,7 @@ index 4d07108..4335f49 100644 ==== Индексирование по частям В Git существует возможность индексировать не только файлы целиком, но и некоторые их части. -Например, если вы сделали в файле simplegit.rb два изменения и хотите добавить в индекс только одно из них, добиться этого в Git очень легко. +Например, если вы сделали в файле `simplegit.rb` два изменения и хотите добавить в индекс только одно из них, добиться этого в Git очень легко. В поле ввода в режиме интерактивного индексирования введите `5` или `p` (для выполнения patch). Git спросит у вас какие файлы вы хотите добавить в индекс частично; а затем для каждой части выбранных файлов он будет показывать изменения в ней и спрашивать хотите ли вы добавить в индекс эту часть: diff --git a/book/07-git-tools/sections/reset.asc b/book/07-git-tools/sections/reset.asc index e2f502e2..5ecf7261 100644 --- a/book/07-git-tools/sections/reset.asc +++ b/book/07-git-tools/sections/reset.asc @@ -162,7 +162,7 @@ image::images/reset-soft.png[] Если вы выполняете `reset` на `HEAD~` (родителя HEAD), то вы перемещаете ветку туда, где она была раньше, не изменяя при этом ни Индекс, ни Рабочий Каталог. Вы можете обновить Индекс и снова выполнить `git commit`, таким образом добиваясь того же, что делает команда `git commit --amend` (смотрите <>). -===== Шаг 2: Обновление Индекса (--mixed) +===== Шаг 2: Обновление Индекса (`--mixed`) Заметьте, если сейчас вы выполните `git status`, то увидите отмеченные зелёным цветом изменения между Индексом и новым HEAD. @@ -176,7 +176,7 @@ image::images/reset-mixed.png[] Снова взгляните на диаграмму и постарайтесь разобраться, что произошло: отменён не только ваш последний `commit`, но также и _добавление в индекс_ всех файлов. Вы откатились назад до момента выполнения команд `git add` и `git commit`. -===== Шаг 3: Обновление Рабочего Каталога (--hard) +===== Шаг 3: Обновление Рабочего Каталога (`--hard`) Третье, что сделает `reset` -- это приведение вашего Рабочего Каталога к тому же виду, что и Индекс. Если вы используете опцию `--hard`, то выполнение команды будет продолжено до этого шага. diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc index 4cffc549..fe48e87f 100644 --- a/book/07-git-tools/sections/revision-selection.asc +++ b/book/07-git-tools/sections/revision-selection.asc @@ -132,7 +132,7 @@ d921970 HEAD@{1}: merge phedders/rdocs: Merge made by the 'recursive' strategy. Каждый раз когда по каким-то причинам изменяется вершина вашей ветки, Git сохраняет информацию об этом в эту временную историю. И вы можете указывать старые коммиты, используя эти данные. -Например, чтобы посмотреть, куда ссылался указатель HEAD пять шагов назад, используйте ссылку @{5}, которую можно увидеть в выводимых данных команды reflog: +Например, чтобы посмотреть, куда ссылался указатель `HEAD` пять шагов назад, используйте ссылку `@{5}`, которую можно увидеть в выводимых данных команды `reflog`: [source,console] ---- @@ -246,7 +246,7 @@ $ git show "HEAD^" # OK ==== -Также вы можете указать число после `^` -- например, `d921970^2` означает «второй родитель коммита d921970». +Также вы можете указать число после `^` -- например, `d921970^2` означает «второй родитель коммита `d921970`». Такой синтаксис полезен только для коммитов слияния, которые имеют больше одного родителя. Первым родителем является ветка, в которую вы выполняли слияние, а вторым -- коммит в ветке, которую вы сливали: diff --git a/book/07-git-tools/sections/submodules.asc b/book/07-git-tools/sections/submodules.asc index e8ceffe1..a0323573 100644 --- a/book/07-git-tools/sections/submodules.asc +++ b/book/07-git-tools/sections/submodules.asc @@ -264,7 +264,7 @@ Submodule path 'DbConnector': checked out 'd0354fc054692d3906c85c3af05ddce39a1c0 Эта команда по умолчанию предполагает, что вы хотите обновить локальную копию до состояния ветки `master` из репозитория подмодуля. Однако, при желании вы можете задать другую ветку. -Например, если вы хотите, чтобы подмодуль DbConnector отслеживал ветку `stable`, то можете указать это либо в файле `.gitmodules` (тогда и другие люди также будут отслеживать эту ветку), либо в вашем локальном файле `.git/config`. +Например, если вы хотите, чтобы подмодуль `DbConnector` отслеживал ветку `stable`, то можете указать это либо в файле `.gitmodules` (тогда и другие люди также будут отслеживать эту ветку), либо в вашем локальном файле `.git/config`. Давайте настроим это в файле `.gitmodules`: [source,console] @@ -418,7 +418,7 @@ no changes added to commit (use "git add" and/or "git commit -a") По умолчанию, команда `git pull` рекурсивно получает изменения для подмодулей, что можно увидеть выше в выводе первой команды. При этом, она не *обновляет* подмодули. Это отображается в выводе команды `git status`, которая показывает, что подмодуль изменён (`modified`) и содержит новые коммиты (`new commits`). -Более того, новые коммиты обозначены символом «<», означающим, что эти коммиты добавлены в проект MainProject, но не извлечены в текущем состоянии подмодуля DbConnector. +Более того, новые коммиты обозначены символом «<», означающим, что эти коммиты добавлены в проект MainProject, но не извлечены в текущем состоянии подмодуля `DbConnector`. Для завершения обновления следует выполнить команду `git submodule update`: [source,console] @@ -459,7 +459,7 @@ $ git submodule update --init --recursive Давайте теперь рассмотрим пример, в котором мы одновременно с изменениями в основном проекте внесём изменения в подмодуль, зафиксировав и опубликовав все эти изменения в одно и то же время. -Ранее, когда мы выполняли команду `git submodule update` для извлечения изменений из репозитория подмодуля, Git получал изменения и обновлял файлы в поддиректории, но оставлял вложенный репозиторий в состоянии, называемом «отсоединённый HEAD» («`detached HEAD`»). +Ранее, когда мы выполняли команду `git submodule update` для извлечения изменений из репозитория подмодуля, Git получал изменения и обновлял файлы в поддиректории, но оставлял вложенный репозиторий в состоянии, называемом «отсоединённый HEAD» («detached HEAD»). Это значит, что локальная рабочая ветка (такая, например, как `master`), отслеживающая изменения, отсутствует. Отсутствие отслеживающей ветки означает, что даже если вы зафиксируете изменения в подмодуле, эти изменения, скорее всего, будут потеряны при следующем запуске `git submodule update`. Если хотите, чтобы изменения в подмодуле отслеживались, потребуется выполнить несколько дополнительных шагов. @@ -499,7 +499,7 @@ Fast-forward Submodule path 'DbConnector': merged in '92c7337b30ef9e0893e758dac2459d07362ab5ea' ---- -Перейдя в каталог DbConnector, можно увидеть, что новые изменения уже слиты в нашу локальную ветку `stable`. +Перейдя в каталог `DbConnector`, можно увидеть, что новые изменения уже слиты в нашу локальную ветку `stable`. Теперь давайте посмотрим что происходит, когда мы вносим локальные изменения в библиотеку, а кто-то другой в то же время отправляет другие изменения в удалённый репозиторий. [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`. diff --git a/book/09-git-and-other-scms/sections/client-bzr.asc b/book/09-git-and-other-scms/sections/client-bzr.asc index e2516201..489e0798 100644 --- a/book/09-git-and-other-scms/sections/client-bzr.asc +++ b/book/09-git-and-other-scms/sections/client-bzr.asc @@ -129,9 +129,9 @@ $ git push origin master Существуют ограничения на выполнение операций с удалённым репозиторием. В частности, следующие команды не работают: -* git push origin :branch-to-delete (Bazaar не понимает удаление ссылок таким способом.) -* git push origin old:new (будет отправлена 'old') -* git push --dry-run origin branch (push будет выполнен) +* `git push origin :branch-to-delete` (Bazaar не понимает удаление ссылок таким способом.) +* `git push origin old:new` (будет отправлена `old`) +* `git push --dry-run origin branch` (`push` будет выполнен) ===== Заключение diff --git a/book/09-git-and-other-scms/sections/client-hg.asc b/book/09-git-and-other-scms/sections/client-hg.asc index 46c7d9b9..e7161dc9 100644 --- a/book/09-git-and-other-scms/sections/client-hg.asc +++ b/book/09-git-and-other-scms/sections/client-hg.asc @@ -123,7 +123,7 @@ $ git cat-file -p ac9117f Команда `git ls-tree` выводит права доступа, тип, хеш и имя файла для содержимого дерева. Наконец, добравшись до первого элемента дерева, мы обнаружим, что это блоб с названием `ac9117f` (SHA-1 коммита, на которую указывает ветка `master`), содержащий `0a04b98` (идентификатор последней ревизии ветки `default` в Mercurial). -Всё это немного запутанно, но хорошие новости в том, что, по большому счёту, нам не нужно беспокоится об организации данных в git-remote-hg. +Всё это немного запутанно, но хорошие новости в том, что, по большому счёту, нам не нужно беспокоится об организации данных в `git-remote-hg`. В целом, работа с Mercurial сервером не сильно отличается от работы с Git сервером. Ещё одна вещь, которую следует учитывать: список игнорируемых файлов. diff --git a/book/09-git-and-other-scms/sections/client-svn.asc b/book/09-git-and-other-scms/sections/client-svn.asc index 985cf4bc..5d674713 100644 --- a/book/09-git-and-other-scms/sections/client-svn.asc +++ b/book/09-git-and-other-scms/sections/client-svn.asc @@ -378,7 +378,7 @@ $ git branch opera remotes/origin/opera После того как вы сольёте одну ветку в другую, вы не сможете просто так вернуться к работе над ней, как могли бы в Git. Команда `dcommit` удаляет всю информацию о том, какая ветка была влита, так что последующие вычисления базы слияния будут неверными -- команда `dcommit` сделает результаты выполнения `git merge` такими же, какими они были бы после выполнения `git merge --squash`. К сожалению, избежать подобной ситуации вряд ли удастся: Subversion не способен сохранять подобную информацию, так что вы всегда будете связаны этими ограничениями. -Во избежание проблем вы должны удалить локальную ветку (в нашем случае `opera`) после того, как вы вольёте её в trunk. +Во избежание проблем вы должны удалить локальную ветку (в нашем случае `opera`) после того, как вы вольёте её в `trunk`. ===== Команды Subversion diff --git a/book/09-git-and-other-scms/sections/import-bzr.asc b/book/09-git-and-other-scms/sections/import-bzr.asc index 1d1b6e33..08a5f9d1 100644 --- a/book/09-git-and-other-scms/sections/import-bzr.asc +++ b/book/09-git-and-other-scms/sections/import-bzr.asc @@ -82,7 +82,7 @@ $ bzr fast-export --plain . | git fast-import ===== Проект с основной и рабочей ветками Вы так же можете импортировать Bazaar репозиторий с несколькими ветками. -Предположим, что в вашем репозитории две ветки: одна является основной веткой проекта (myProject.trunk), другая -- рабочей (myProject.work). +Предположим, что в вашем репозитории две ветки: одна является основной веткой проекта (`myProject.trunk`), другая -- рабочей (`myProject.work`). [source,console] ---- diff --git a/book/09-git-and-other-scms/sections/import-custom.asc b/book/09-git-and-other-scms/sections/import-custom.asc index e4a58d74..3ecb1517 100644 --- a/book/09-git-and-other-scms/sections/import-custom.asc +++ b/book/09-git-and-other-scms/sections/import-custom.asc @@ -26,13 +26,13 @@ current Чтобы успешно импортировать репозиторий, давайте вспомним, как Git хранит данные. Как вы наверное помните, Git по сути представляет собой связанный список ревизий, каждая из которых указывает на слепок состояния. -Всё что от вас требуется, это указать `fast-import`'у на данные для создания слепков и порядок их применения. +Всё что от вас требуется, это указать `fast-import` на данные для создания слепков и порядок их применения. Итак, мы пробежимся по всем слепкам, создадим коммит для каждого из них и свяжем каждый новый коммит с предыдущим. Как и в разделе <> главы 8, мы проделаем это на Ruby, потому что это тот язык, с которым мы обычно работаем, и его легко читать. Вы можете использовать любой другой язык -- всё что требуется, это вывести нужную информацию в стандартный поток вывода. -Если вы работаете на Windows, будьте особо осторожными с переводами строк: `fast-import` ожидает лишь символы перевода строки (`LF`), но не возврат каретки + перевод строки (`CRLF`), как принято в Windows. +Если вы работаете на Windows, будьте особо осторожными с переводами строк: `fast-import` ожидает лишь символы перевода строки (LF), но не возврат каретки + перевод строки (CRLF), как принято в Windows. Для начала перейдём в исходный каталог и определим подкаталоги, содержащие состояния проекта в разные моменты времени, которые будут использованы для построения соответствующих коммитов. Вы поочерёдно посетите каждую из них и выполните команды, необходимые для экспорта. @@ -112,7 +112,7 @@ end $author = 'John Doe ' ---- -Теперь всё готово для вывода нужной `fast-import`'у информации. +Теперь всё готово для вывода нужной `fast-import` информации. Нужно указать, что создаётся коммит на определённой ветке, затем вывести сгенерированную метку, автора и время изменений и ссылку на предыдущий коммит, если такой имеется. Код выглядит следующим образом: @@ -197,8 +197,8 @@ return mark [NOTE] ==== Если вы используете ОС Windows есть ещё кое-что. -Как мы упоминали ранее, Windows использует `CRLF` для новых строк, в то время как `git fast-import` ожидает только `LF`. -Чтобы исправить этот недостаток Windows и осчастливить `git fast-import`, просто прикажите Ruby использовать `LF` вместо `CRLF`: +Как мы упоминали ранее, Windows использует CRLF для новых строк, в то время как `git fast-import` ожидает только LF. +Чтобы исправить этот недостаток Windows и осчастливить `git fast-import`, просто прикажите Ruby использовать LF вместо CRLF: [source,ruby] ---- diff --git a/book/A-git-in-other-environments/sections/bash.asc b/book/A-git-in-other-environments/sections/bash.asc index da7bd0fb..3e8eba7b 100644 --- a/book/A-git-in-other-environments/sections/bash.asc +++ b/book/A-git-in-other-environments/sections/bash.asc @@ -33,7 +33,7 @@ export GIT_PS1_SHOWDIRTYSTATE=1 export PS1='\w$(__git_ps1 " (%s)")\$ ' ---- -Часть `\w` означает текущий рабочий каталог, `\$` -- индикатор суперпользователя (обычно `$` или `#`), а `__git_ps1 " (%s)"` вызывает функцию, объявленную в `git-prompt.sh`, с аргументом ` (%s)` -- строкой форматирования. +Часть `\w` означает текущий рабочий каталог, `\$` -- индикатор суперпользователя (обычно `$` или `#`), а `__git_ps1 " (%s)"` вызывает функцию, объявленную в `git-prompt.sh`, с аргументом `" (%s)"` -- строкой форматирования. Теперь ваша строка приветствия будет похожа на эту, когда вы перейдёте в каталог с Git репозиторием: .Кастомизированная строка приветствия `bash` diff --git a/book/B-embedding-git/sections/jgit.asc b/book/B-embedding-git/sections/jgit.asc index 4931a46d..dba590c9 100644 --- a/book/B-embedding-git/sections/jgit.asc +++ b/book/B-embedding-git/sections/jgit.asc @@ -8,7 +8,7 @@ ==== Приступая к работе Существует несколько способов добавить JGit в проект и начать писать код с использованием предоставляемого API. -Возможно, самый простой путь -- использование Maven: подключение библиотеки происходит путём добавления следующих строк в секцию `` в вашем pom.xml: +Возможно, самый простой путь -- использование Maven: подключение библиотеки происходит путём добавления следующих строк в секцию `` в вашем `pom.xml`: [source,xml] ---- @@ -100,7 +100,7 @@ ObjectId представляют SHA-1-хеш объекта, который, Следующая строка похожа на предыдущую, но используется синтаксис rev-parse (см. детали в разделе <> главы 7); вы можете использовать любой, подходящий формат и JGit вернёт либо валидный ObjectId для указанного объекта, либо `null`. Следующие две строки показывают, как можно получить содержимое объекта. -В этом примере мы используем `ObjectLoader.copyTo()` чтобы передать содержимое файла прямиком в stdout, но у ObjectLoader есть методы для чтения типа и размера объекта, а также для считывания объекта в виде массива байтов. +В этом примере мы используем `ObjectLoader.copyTo()` чтобы передать содержимое файла прямиком в `stdout`, но у ObjectLoader есть методы для чтения типа и размера объекта, а также для считывания объекта в виде массива байтов. Для больших объектов (у которых `.isLarge()` возвращает `true`) можно использовать метод `.openStream()` для открытия потока последовательного чтения объекта без полной загрузки в память. Следующие строки показывают, как создать новую ветку. diff --git a/book/B-embedding-git/sections/libgit2.asc b/book/B-embedding-git/sections/libgit2.asc index ba942121..586a200a 100644 --- a/book/B-embedding-git/sections/libgit2.asc +++ b/book/B-embedding-git/sections/libgit2.asc @@ -234,4 +234,4 @@ pygit2.Repository("/path/to/repo") # открыть репозиторий Конечно же, полное описание возможностей Libgit2 выходит далеко за пределы этой книги. Если вы хотите подробнее ознакомиться с Libgit2, можете начать с документации к API https://libgit2.github.com/libgit2[^] и набора руководств https://libgit2.github.com/docs[^]. -Для привязок к другим языкам, загляните в README и исходники тестов, довольно часто в них встречаются ссылки на полезные материалы по теме. +Для привязок к другим языкам, загляните в `README` и исходники тестов, довольно часто в них встречаются ссылки на полезные материалы по теме. From 6084a122852fd60b3d8fe08b76791e2a745bb430 Mon Sep 17 00:00:00 2001 From: Viktor Yegay Date: Mon, 5 Feb 2024 08:15:27 +0500 Subject: [PATCH 06/13] =?UTF-8?q?=D0=94=D0=BE=D0=B1=D0=B0=D0=B2=D0=B8?= =?UTF-8?q?=D1=82=D1=8C=20=D0=BD=D0=B0=D0=B7=D0=B2=D0=B0=D0=BD=D0=B8=D0=B5?= =?UTF-8?q?=20=D0=BA=20=D1=80=D0=B8=D1=81=D1=83=D0=BD=D0=BA=D0=B0=D0=BC?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../sections/basic-branching-and-merging.asc | 4 +- book/07-git-tools/sections/replace.asc | 15 ++++-- book/07-git-tools/sections/rerere.asc | 13 +++-- book/07-git-tools/sections/reset.asc | 54 ++++++++++++------- 4 files changed, 56 insertions(+), 30 deletions(-) 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 e48b7d0d..b032b3d2 100644 --- a/book/03-git-branching/sections/basic-branching-and-merging.asc +++ b/book/03-git-branching/sections/basic-branching-and-merging.asc @@ -88,8 +88,8 @@ $ git commit -a -m 'Fix broken email address' 1 file changed, 2 insertions(+) ---- -.Ветка hotfix основана на ветке `master` -image::images/basic-branching-4.png["Ветка hotfix основана на ветке `master`"] +.Ветка `hotfix` основана на ветке `master` +image::images/basic-branching-4.png["Ветка `hotfix` основана на ветке `master`"] Вы можете прогнать тесты, чтобы убедиться, что ваше уязвимость в самом деле исправлена. И если это так -- выполнить слияние ветки `hotfix` с веткой `master` для включения изменений в продукт. diff --git a/book/07-git-tools/sections/replace.asc b/book/07-git-tools/sections/replace.asc index d036602f..361387d0 100644 --- a/book/07-git-tools/sections/replace.asc +++ b/book/07-git-tools/sections/replace.asc @@ -28,7 +28,8 @@ c1822cf First commit Одно семейство, которое начинается от первого коммита и заканчивается четвёртым, будет историческим. Второе, состоящее пока только из четвёртого и пятого коммитов -- будет семейством со свежей историей. -image::images/replace1.png[] +.Пример истории Git +image::images/replace1.png["Пример истории Git"] Создать историческое семейство легко, мы просто создаём ветку с вершиной на нужном коммите и затем отправляем эту ветку как `master` в новый удалённый репозиторий. @@ -43,7 +44,8 @@ c6e1e95 (history) Fourth commit c1822cf First commit ---- -image::images/replace2.png[] +.Создание новой ветки `history` +image::images/replace2.png["Создание новой ветки `history`"] Теперь мы можем отправить только что созданную ветвь `history` в ветку `master` нашего нового репозитория: @@ -95,7 +97,8 @@ $ echo 'Get history from blah blah blah' | git commit-tree 9c68fdc^{tree} Вы можете прочитать больше о сантехнических командах в <>. ===== -image::images/replace3.png[] +.Создание базового коммита с использованием `commit-tree` +image::images/replace3.png["Создание базового коммита с использованием `commit-tree`"] Хорошо. Теперь когда у нас есть базовый коммит, мы можем перебазировать нашу оставшуюся историю на этот коммит используя `git rebase --onto`. @@ -109,7 +112,8 @@ Applying: fourth commit Applying: fifth commit ---- -image::images/replace4.png[] +.Перебазирование истории поверх базового коммита +image::images/replace4.png["Перебазирование истории поверх базового коммита"] Таким образом, мы переписали нашу свежую историю поверх вспомогательного базового коммита, который теперь содержит инструкции о том, как при необходимости восстановить полную историю. Мы можем отправить эту историю в новый проект и теперь, когда люди клонируют его репозиторий, они будут видеть только два свежих коммита и после них базовый коммит с инструкциями. @@ -171,7 +175,8 @@ c1822cf First commit Здорово, не правда ли? Не изменяя SHA-1 всех коммитов семейства, мы можем заменить один коммит в нашей истории совершенно другим коммитом и все обычные утилиты (`bisect`, `blame` и т. д.) будут работать как от них это и ожидается. -image::images/replace5.png[] +.Объединение коммитов с помощью `git replace` +image::images/replace5.png["Объединение коммитов с помощью `git replace`"] Интересно, что для четвёртого коммита SHA-1 хеш выводится равный `81a708d`, хотя в действительности он содержит данные коммита `c6e1e95`, которым мы его заменили. Даже если вы выполните команду типа `cat-file`, она отобразит заменённые данные: diff --git a/book/07-git-tools/sections/rerere.asc b/book/07-git-tools/sections/rerere.asc index b4a25e08..658806ab 100644 --- a/book/07-git-tools/sections/rerere.asc +++ b/book/07-git-tools/sections/rerere.asc @@ -39,7 +39,8 @@ end Как и ранее, в одной ветке мы изменили слово «hello» на «hola», а в другой -- слово «world» на «mundo». -image::images/rerere1.png[] +.Две ветки по-разному меняют одну и ту же часть одного и того же файла +image::images/rerere1.png["Две ветки по-разному меняют одну и ту же часть одного и того же файла"] Когда мы будем сливать эти две ветки в одну, мы получим конфликт: @@ -142,9 +143,10 @@ Recorded resolution for 'hello.rb'. [master 68e16e5] Merge branch 'i18n' ---- -Как вы видите, при этом было «сохранено разрешение конфликта для ФАЙЛА» («Recorded resolution for FILE»). - -image::images/rerere2.png[] +Как вы видите, при этом было <>. +[[rerere2]] +.Сохранено разрешение конфликта для файла +image::images/rerere2.png["Сохранено разрешение конфликта для файла"] Теперь давайте отменим это слияние и перебазируем ветку `i18n-world` поверх `master`. Как мы видели в <>, мы можем переместить нашу ветку назад, используя команду `reset`. @@ -206,7 +208,8 @@ index a440db6,54336ba..0000000 end ---- -image::images/rerere3.png[] +.Автоматически разрешается конфликт слияния с использованием предыдущего разрешения +image::images/rerere3.png["Автоматически разрешается конфликт слияния с использованием предыдущего разрешения"] С помощью команды `checkout` вы можете вернуть этот файл назад в конфликтующее состояние: diff --git a/book/07-git-tools/sections/reset.asc b/book/07-git-tools/sections/reset.asc index 5ecf7261..a4914ef3 100644 --- a/book/07-git-tools/sections/reset.asc +++ b/book/07-git-tools/sections/reset.asc @@ -92,23 +92,27 @@ $ tree Основное предназначение Git -- это сохранение снимков последовательно улучшающихся состояний вашего проекта, путём управления этими тремя деревьями. -image::images/reset-workflow.png[] +.Типичный рабочий процесс Git +image::images/reset-workflow.png["Типичный рабочий процесс Git"] Давайте рассмотрим этот процесс: пусть вы перешли в новый каталог, содержащий один файл. Данную версию этого файла будем называть *v1* и изображать голубым цветом. Выполним команду `git init`, которая создаст Git-репозиторий, у которого ссылка HEAD будет указывать на ещё несуществующую ветку (`master` пока не существует). -image::images/reset-ex1.png[] +.Недавно инициализированный репозиторий Git с неподготовленным файлом в рабочем каталоге +image::images/reset-ex1.png["Недавно инициализированный репозиторий Git с не индексированным файлом в рабочем каталоге"] На данном этапе только дерево Рабочего Каталога содержит данные. Теперь мы хотим закоммитить этот файл, поэтому мы используем `git add` для копирования содержимого Рабочего Каталога в Индекс. -image::images/reset-ex2.png[] +.`git add` копирует файл в индекс +image::images/reset-ex2.png["`git add` копирует файл в индекс"] Затем, мы выполняем команду `git commit`, которая сохраняет содержимое Индекса как неизменяемый снимок, создаёт объект коммита, который указывает на этот снимок, и обновляет `master` так, чтобы он тоже указывал на этот коммит. -image::images/reset-ex3.png[] +.Шаг `git commit` +image::images/reset-ex3.png["Шаг `git commit`"] Если сейчас выполнить `git status`, то мы не увидим никаких изменений, так как все три дерева одинаковые. @@ -116,17 +120,20 @@ image::images/reset-ex3.png[] Мы пройдём через всё ту же процедуру; сначала мы отредактируем файл в нашем рабочем каталоге. Давайте называть эту версию файла *v2* и обозначать красным цветом. -image::images/reset-ex4.png[] +.Репозиторий Git с изменённым файлом в рабочем каталоге +image::images/reset-ex4.png["Репозиторий Git с изменённым файлом в рабочем каталоге"] Если сейчас мы выполним `git status`, то увидим, что файл выделен красным в разделе «Изменения, не подготовленные к коммиту», так как его представления в Индексе и Рабочем Каталоге различны. Затем мы выполним `git add` для этого файла, чтобы поместить его в Индекс. -image::images/reset-ex5.png[] +.Подготовленные изменения в индексе +image::images/reset-ex5.png["Подготовленные изменения в индексе"] Если сейчас мы выполним `git status`, то увидим, что этот файл выделен зелёным цветом в разделе «Изменения, которые будут закоммичены», так как Индекс и HEAD различны -- то есть, наш следующий намеченный коммит сейчас отличается от нашего последнего коммита. Наконец, мы выполним `git commit`, чтобы окончательно совершить коммит. -image::images/reset-ex6.png[] +.Шаг `git commit` с изменённым файлом +image::images/reset-ex6.png["Шаг `git commit` с изменённым файлом"] Сейчас команда `git status` не показывает ничего, так как снова все три дерева одинаковые. @@ -140,7 +147,8 @@ image::images/reset-ex6.png[] В следующих примерах предположим, что мы снова изменили файл `file.txt` и закоммитили его в третий раз. Так что наша история теперь выглядит так: -image::images/reset-start.png[] +.Репозиторий Git с тремя коммитами +image::images/reset-start.png["Репозиторий Git с тремя коммитами"] Давайте теперь внимательно проследим, что именно происходит при вызове `reset`. Эта команда простым и предсказуемым способом управляет тремя деревьями, существующими в Git. @@ -152,7 +160,8 @@ image::images/reset-start.png[] Обратите внимание, изменяется не сам HEAD (что происходит при выполнении команды `checkout`); `reset` перемещает ветку, на которую указывает HEAD. Таким образом, если HEAD указывает на ветку `master` (то есть вы сейчас работаете с веткой `master`), выполнение команды `git reset 9e5e6a4` сделает так, что `master` будет указывать на `9e5e6a4`. -image::images/reset-soft.png[] +.Soft reset +image::images/reset-soft.png["Soft reset"] Не важно с какими опциями вы вызвали команду `reset` _с указанием коммита_ (`reset` также можно вызывать с указанием пути), она всегда будет пытаться сперва сделать данный шаг. При вызове `reset --soft` на этом выполнение команды и остановится. @@ -168,7 +177,8 @@ image::images/reset-soft.png[] Следующим, что сделает `reset`, будет обновление Индекса содержимым того снимка, на который указывает HEAD. -image::images/reset-mixed.png[] +.Mixed reset +image::images/reset-mixed.png["Mixed reset"] Если вы указали опцию `--mixed`, выполнение `reset` остановится на этом шаге. Такое поведение также используется по умолчанию, поэтому если вы не указали совсем никаких опций (в нашем случае `git reset HEAD~`), выполнение команды также остановится на этом шаге. @@ -181,7 +191,8 @@ image::images/reset-mixed.png[] Третье, что сделает `reset` -- это приведение вашего Рабочего Каталога к тому же виду, что и Индекс. Если вы используете опцию `--hard`, то выполнение команды будет продолжено до этого шага. -image::images/reset-hard.png[] +.Hard reset +image::images/reset-hard.png["Hard reset"] Давайте разберёмся, что сейчас случилось. Вы отменили ваш последний коммит, результаты выполнения команд `git add` и `git commit`, а также **все** изменения, которые вы сделали в рабочем каталоге. @@ -213,12 +224,14 @@ image::images/reset-hard.png[] То есть, фактически, она копирует файл `file.txt` из HEAD в Индекс. -image::images/reset-path1.png[] +.Mixed reset с указанием пути +image::images/reset-path1.png["Mixed reset с указанием пути"] Это создаёт эффект _отмены индексации_ файла. Если вы посмотрите на диаграммы этой команды и команды `git add`, то увидите, что их действия прямо противоположные. -image::images/reset-path2.png[] +.Подготовленный файл для индексации +image::images/reset-path2.png["Подготовленный файл для индексации"] Именно поэтому в выводе `git status` предлагается использовать такую команду для отмены индексации файла. (Смотрите подробности в <>.) @@ -226,7 +239,8 @@ image::images/reset-path2.png[] Мы легко можем заставить Git «брать данные не из HEAD», указав коммит, из которого нужно взять версию этого файла. Для этого мы должны выполнить следующее `git reset eb43bf file.txt`. -image::images/reset-path3.png[] +.Soft reset с указанием пути к конкретному коммиту +image::images/reset-path3.png["Soft reset с указанием пути к конкретному коммиту"] Можно считать, что, фактически, мы в Рабочем Каталоге вернули содержимое файла к версии *v1*, выполнили для него `git add`, а затем вернули содержимое обратно к версии *v3* (в действительности все эти шаги не выполняются). Если сейчас мы выполним `git commit`, то будут сохранены изменения, которые возвращают файл к версии *v1*, но при этом файл в Рабочем Каталоге никогда не возвращался к такой версии. @@ -245,15 +259,18 @@ image::images/reset-path3.png[] Предположим, у вас есть проект, в котором первый коммит содержит один файл, второй коммит добавляет новый файл и изменяет первый, а третий коммит снова изменяет первый файл. Второй коммит был сделан в процессе работы и вы хотите слить его со следующим. -image::images/reset-squash-r1.png[] +.Git-репозиторий +image::images/reset-squash-r1.png["Git-репозиторий"] Вы можете выполнить `git reset --soft HEAD~2`, чтобы вернуть ветку HEAD на какой-то из предыдущих коммитов (на первый коммит, который вы хотите оставить): -image::images/reset-squash-r2.png[] +.Перемещение HEAD с soft reset +image::images/reset-squash-r2.png["Перемещение HEAD с soft reset"] Затем просто снова выполните `git commit`: -image::images/reset-squash-r3.png[] +.Репозиторий Git с объединёенным коммитом +image::images/reset-squash-r3.png["Репозиторий Git с объединённым коммитом"] Теперь вы можете видеть, что ваша «достижимая» история (история, которую вы впоследствии отправите на сервер), сейчас выглядит так -- у вас есть первый коммит с файлом `file-a.txt` версии *v1*, и второй, который изменяет файл `file-a.txt` до версии *v3* и добавляет `file-b.txt`. Коммита, который содержал файл версии *v2* не осталось в истории. @@ -284,7 +301,8 @@ image::images/reset-squash-r3.png[] Итак, в обоих случаях мы перемещаем HEAD на коммит A, но важное отличие состоит в том, _как_ мы это делаем. Команда `reset` переместит также и ветку, на которую указывает HEAD, а `checkout` перемещает только сам HEAD. -image::images/reset-checkout.png[] +.`git checkout` и `git reset` +image::images/reset-checkout.png["`git checkout` и `git reset`"] ===== С указанием пути From ef0833de8fe41c98a3ea946faa61ad383f6be604 Mon Sep 17 00:00:00 2001 From: Viktor Yegay Date: Mon, 5 Feb 2024 08:16:42 +0500 Subject: [PATCH 07/13] =?UTF-8?q?=D0=9E=D1=82=D1=80=D0=B5=D0=B4=D0=B0?= =?UTF-8?q?=D0=BA=D1=82=D0=B8=D1=80=D0=BE=D0=B2=D0=B0=D1=82=D1=8C=20=D0=B8?= =?UTF-8?q?=20=D0=B4=D0=BE=D0=B1=D0=B0=D0=B2=D0=B8=D1=82=D1=8C=20=D1=81?= =?UTF-8?q?=D1=81=D1=8B=D0=BB=D0=BA=D0=B8?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- book/01-introduction/sections/installing.asc | 2 +- book/06-github/sections/4-managing-organization.asc | 2 +- book/08-customizing-git/sections/policy.asc | 2 +- book/B-embedding-git/sections/dulwich.asc | 4 ++-- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/book/01-introduction/sections/installing.asc b/book/01-introduction/sections/installing.asc index 44e6a5ef..99879a57 100644 --- a/book/01-introduction/sections/installing.asc +++ b/book/01-introduction/sections/installing.asc @@ -113,7 +113,7 @@ $ sudo ln -s /usr/bin/db2x_docbook2texi /usr/bin/docbook2x-texi ---- Когда все необходимые зависимости установлены, вы можете пойти дальше и скачать самый свежий архив с исходниками из следующих мест: -с сайта Kernel.org https://www.kernel.org/pub/software/scm/git[^], или зеркала на сайте GitHub https://github.com/git/git/releases[^]. +с сайта Kernel.org https://www.kernel.org/pub/software/scm/git[^], или зеркала на сайте GitHub https://github.com/git/git/tags[^]. Конечно, немного проще скачать последнюю версию с сайта GitHub, но на странице kernel.org релизы имеют подписи, если вы хотите проверить, что скачиваете. Затем скомпилируйте и установите: diff --git a/book/06-github/sections/4-managing-organization.asc b/book/06-github/sections/4-managing-organization.asc index 337ab163..6531c483 100644 --- a/book/06-github/sections/4-managing-organization.asc +++ b/book/06-github/sections/4-managing-organization.asc @@ -24,7 +24,7 @@ image::images/neworg.png["Пункт меню «New organization»"] При создании нового репозитория, вы можете его сохранить как в персональном окружении, так и в окружении любой компании, владельцем которой вы являетесь. Так же вы автоматически начинаете отслеживать все создаваемые репозитории в организации. -Как для персонального аккаунта, так и для организации вы можете загрузить отдельную картинку. +Как для <>, так и для организации вы можете загрузить отдельную картинку. Аналогично и для главной страницы, где приводится список доступных репозиториев организации. Теперь, давайте рассмотрим отличительные черты аккаунтов организаций. diff --git a/book/08-customizing-git/sections/policy.asc b/book/08-customizing-git/sections/policy.asc index 5683aefa..97ee787b 100644 --- a/book/08-customizing-git/sections/policy.asc +++ b/book/08-customizing-git/sections/policy.asc @@ -167,7 +167,7 @@ end Теперь, когда вопрос с правами доступа решён, необходимо извлечь список путей, изменения по которым присутствуют в отправляемых коммитах, чтобы убедиться в наличии доступа к ним у отправляющего пользователя. -Список файлов одного коммита можно легко получить, используя опцию `--name-only` команды `git log` (кратко рассматривалось в Главе 2): +Список файлов одного коммита можно легко получить, используя опцию `--name-only` команды `git log` (кратко рассматривалось в <> главы 2): [source,console] ---- diff --git a/book/B-embedding-git/sections/dulwich.asc b/book/B-embedding-git/sections/dulwich.asc index 292d2061..83d48c56 100644 --- a/book/B-embedding-git/sections/dulwich.asc +++ b/book/B-embedding-git/sections/dulwich.asc @@ -2,7 +2,7 @@ (((Dulwich)))(((Python))) Так же существует реализация Git на чистом Python -- Dulwich. -Проект размещается здесь hhttps://github.com/jelmer/dulwich[^]. +Проект размещается здесь https://www.dulwich.io/[^]. Целью проекта является предоставление интерфейса к Git репозиториям (как локальным, так и удалённым) используя чистый Python, а не вызывая Git. В нём используются дополнительные расширения на С, которые существенно увеличивают производительность. @@ -39,4 +39,4 @@ porcelain.log('.', max_entries=1) ==== Дополнительные материалы -Документацию к API, руководство и множество примеров решения специфичных задач с помощью Dulwich можно найти на странице проекта https://github.com/jelmer/dulwich[^]. +Документацию к API, руководство и множество примеров решения специфичных задач с помощью Dulwich можно найти на официальном сайте https://www.dulwich.io[^]. From e2a1bd41af2d673a5f0c6d339a7f111a09e31b3c Mon Sep 17 00:00:00 2001 From: Viktor Yegay Date: Fri, 2 Feb 2024 05:06:39 +0500 Subject: [PATCH 08/13] =?UTF-8?q?=D0=98=D1=81=D0=BF=D1=80=D0=B0=D0=B2?= =?UTF-8?q?=D0=B8=D1=82=D1=8C=20=D1=80=D0=B5=D0=B3=D0=B8=D1=81=D1=82=D1=80?= =?UTF-8?q?=20=D0=B1=D1=83=D0=BA=D0=B2?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Рабочий Каталог -> рабочий каталог Индекс -> индекс Проблема -> проблема --- book/06-github/sections/2-contributing.asc | 6 +-- book/07-git-tools/sections/reset.asc | 56 +++++++++++----------- 2 files changed, 31 insertions(+), 31 deletions(-) diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index 63f21e17..fbdbd8c5 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -336,11 +336,11 @@ image::images/mentions-03-closed.png["Отображение перекрёст Кроме идентификационных номеров, можно ссылаться на конкретный коммит используя SHA-1. Следует указывать полный 40 символьный хеш SHA-1, но если GitHub увидит его в комментарии, то автоматически подставит ссылку на коммит. -Как было сказано выше, вы можете ссылаться на коммиты как в других, так и в ответвлённых репозиториях точно так же, как делали это с Проблемами. +Как было сказано выше, вы можете ссылаться на коммиты как в других, так и в ответвлённых репозиториях точно так же, как делали это с проблемами. ==== GitHub-версия разметки Markdown -Ссылки на другие Проблемы -- это лишь часть интереснейших вещей, которые вы можете делать в текстовых полях на GitHub. +Ссылки на другие проблемы -- это лишь часть интереснейших вещей, которые вы можете делать в текстовых полях на GitHub. Для «проблемы» или «запроса слияния» в полях описания, комментария, комментария кода и других вы можете использовать так называемую «GitHub-версию разметки Markdown». Разметка похожа на обычный текст, который основательно преобразуется. @@ -357,7 +357,7 @@ GitHub расширил возможности обычной разметки. Список задач -- это первая действительно важная возможность специфической разметки GitHub, особенно для запросов слияния. Список задач представляет собой список флажков для задач, которые вы хотите выполнить. -Размещение его в описании Проблемы или запроса на слияние обычно указывает на то, что должно быть сделано до того, как проблема будет считаться решённой. +Размещение его в описании проблемы или запроса на слияние обычно указывает на то, что должно быть сделано до того, как проблема будет считаться решённой. Список задач можно добавить следующим образом: diff --git a/book/07-git-tools/sections/reset.asc b/book/07-git-tools/sections/reset.asc index a4914ef3..29325b82 100644 --- a/book/07-git-tools/sections/reset.asc +++ b/book/07-git-tools/sections/reset.asc @@ -19,7 +19,7 @@ | Дерево ^.^| Назначение | HEAD | Снимок последнего коммита, родитель следующего | Индекс | Снимок следующего намеченного коммита -| Рабочий Каталог | Песочница +| Рабочий каталог | Песочница |================================ ===== Указатель HEAD @@ -69,12 +69,12 @@ $ git ls-files -s Технически, индекс не является древовидной структурой, на самом деле, он реализован как сжатый список (_flattened manifest_) -- но для наших целей такого представления будет достаточно. -===== Рабочий Каталог +===== Рабочий каталог Наконец, у вас есть рабочий каталог. Два других дерева сохраняют своё содержимое эффективным, но неудобным способом внутри каталога `.git`. -Рабочий Каталог распаковывает их в настоящие файлы, что упрощает для вас их редактирование. -Считайте Рабочий Каталог *песочницей*, где вы можете опробовать изменения перед их коммитом в индекс (область подготовленных изменений) и затем в историю. +Рабочий каталог распаковывает их в настоящие файлы, что упрощает для вас их редактирование. +Считайте рабочий каталог *песочницей*, где вы можете опробовать изменения перед их коммитом в индекс (область подготовленных изменений) и затем в историю. [source,console] ---- @@ -102,14 +102,14 @@ image::images/reset-workflow.png["Типичный рабочий процесс .Недавно инициализированный репозиторий Git с неподготовленным файлом в рабочем каталоге image::images/reset-ex1.png["Недавно инициализированный репозиторий Git с не индексированным файлом в рабочем каталоге"] -На данном этапе только дерево Рабочего Каталога содержит данные. +На данном этапе только дерево рабочего каталога содержит данные. -Теперь мы хотим закоммитить этот файл, поэтому мы используем `git add` для копирования содержимого Рабочего Каталога в Индекс. +Теперь мы хотим закоммитить этот файл, поэтому мы используем `git add` для копирования содержимого рабочего каталога в индекс. .`git add` копирует файл в индекс image::images/reset-ex2.png["`git add` копирует файл в индекс"] -Затем, мы выполняем команду `git commit`, которая сохраняет содержимое Индекса как неизменяемый снимок, создаёт объект коммита, который указывает на этот снимок, и обновляет `master` так, чтобы он тоже указывал на этот коммит. +Затем, мы выполняем команду `git commit`, которая сохраняет содержимое индекса как неизменяемый снимок, создаёт объект коммита, который указывает на этот снимок, и обновляет `master` так, чтобы он тоже указывал на этот коммит. .Шаг `git commit` image::images/reset-ex3.png["Шаг `git commit`"] @@ -123,13 +123,13 @@ image::images/reset-ex3.png["Шаг `git commit`"] .Репозиторий Git с изменённым файлом в рабочем каталоге image::images/reset-ex4.png["Репозиторий Git с изменённым файлом в рабочем каталоге"] -Если сейчас мы выполним `git status`, то увидим, что файл выделен красным в разделе «Изменения, не подготовленные к коммиту», так как его представления в Индексе и Рабочем Каталоге различны. -Затем мы выполним `git add` для этого файла, чтобы поместить его в Индекс. +Если сейчас мы выполним `git status`, то увидим, что файл выделен красным в разделе «Изменения, не подготовленные к коммиту», так как его представления в индексе и рабочем каталоге различны. +Затем мы выполним `git add` для этого файла, чтобы поместить его в индекс. .Подготовленные изменения в индексе image::images/reset-ex5.png["Подготовленные изменения в индексе"] -Если сейчас мы выполним `git status`, то увидим, что этот файл выделен зелёным цветом в разделе «Изменения, которые будут закоммичены», так как Индекс и HEAD различны -- то есть, наш следующий намеченный коммит сейчас отличается от нашего последнего коммита. +Если сейчас мы выполним `git status`, то увидим, что этот файл выделен зелёным цветом в разделе «Изменения, которые будут закоммичены», так как индекс и HEAD различны -- то есть, наш следующий намеченный коммит сейчас отличается от нашего последнего коммита. Наконец, мы выполним `git commit`, чтобы окончательно совершить коммит. .Шаг `git commit` с изменённым файлом @@ -138,7 +138,7 @@ image::images/reset-ex6.png["Шаг `git commit` с изменённым фай Сейчас команда `git status` не показывает ничего, так как снова все три дерева одинаковые. Переключение веток и клонирование проходят через похожий процесс. -Когда вы переключаетесь (checkout) на ветку, *HEAD* начинает также указывать на новую ветку, ваш *Индекс* замещается снимком коммита этой ветки, и затем содержимое *Индекса* копируется в ваш *Рабочий Каталог*. +Когда вы переключаетесь (checkout) на ветку, *HEAD* начинает также указывать на новую ветку, ваш *индекс* замещается снимком коммита этой ветки, и затем содержимое *индекса* копируется в ваш *рабочий каталог*. ==== Назначение команды `reset` @@ -168,14 +168,14 @@ image::images/reset-soft.png["Soft reset"] Теперь взгляните на диаграмму и постарайтесь разобраться, что случилось: фактически была отменена последняя команда `git commit`. Когда вы выполняете `git commit`, Git создаёт новый коммит и перемещает на него ветку, на которую указывает HEAD. -Если вы выполняете `reset` на `HEAD~` (родителя HEAD), то вы перемещаете ветку туда, где она была раньше, не изменяя при этом ни Индекс, ни Рабочий Каталог. -Вы можете обновить Индекс и снова выполнить `git commit`, таким образом добиваясь того же, что делает команда `git commit --amend` (смотрите <>). +Если вы выполняете `reset` на `HEAD~` (родителя HEAD), то вы перемещаете ветку туда, где она была раньше, не изменяя при этом ни индекс, ни рабочий каталог. +Вы можете обновить индекс и снова выполнить `git commit`, таким образом добиваясь того же, что делает команда `git commit --amend` (смотрите <>). -===== Шаг 2: Обновление Индекса (`--mixed`) +===== Шаг 2: Обновление индекса (`--mixed`) -Заметьте, если сейчас вы выполните `git status`, то увидите отмеченные зелёным цветом изменения между Индексом и новым HEAD. +Заметьте, если сейчас вы выполните `git status`, то увидите отмеченные зелёным цветом изменения между индексом и новым HEAD. -Следующим, что сделает `reset`, будет обновление Индекса содержимым того снимка, на который указывает HEAD. +Следующим, что сделает `reset`, будет обновление индекса содержимым того снимка, на который указывает HEAD. .Mixed reset image::images/reset-mixed.png["Mixed reset"] @@ -186,9 +186,9 @@ image::images/reset-mixed.png["Mixed reset"] Снова взгляните на диаграмму и постарайтесь разобраться, что произошло: отменён не только ваш последний `commit`, но также и _добавление в индекс_ всех файлов. Вы откатились назад до момента выполнения команд `git add` и `git commit`. -===== Шаг 3: Обновление Рабочего Каталога (`--hard`) +===== Шаг 3: Обновление рабочего каталога (`--hard`) -Третье, что сделает `reset` -- это приведение вашего Рабочего Каталога к тому же виду, что и Индекс. +Третье, что сделает `reset` -- это приведение вашего рабочего каталога к тому же виду, что и индекс. Если вы используете опцию `--hard`, то выполнение команды будет продолжено до этого шага. .Hard reset @@ -198,7 +198,7 @@ image::images/reset-hard.png["Hard reset"] Вы отменили ваш последний коммит, результаты выполнения команд `git add` и `git commit`, а также **все** изменения, которые вы сделали в рабочем каталоге. Важно отметить, что только указание этого флага (`--hard`) делает команду `reset` опасной, это один из немногих случаев, когда Git действительно удаляет данные. -Все остальные вызовы `reset` легко отменить, но при указании опции `--hard` команда принудительно перезаписывает файлы в Рабочем Каталоге. +Все остальные вызовы `reset` легко отменить, но при указании опции `--hard` команда принудительно перезаписывает файлы в рабочем каталоге. В данном конкретном случае, версия *v3* нашего файла всё ещё остаётся в коммите внутри базы данных Git и мы можем вернуть её, просматривая наш `reflog`, но если вы не коммитили эту версию, Git перезапишет файл и её уже нельзя будет восстановить. ===== Резюме @@ -206,23 +206,23 @@ image::images/reset-hard.png["Hard reset"] Команда `reset` в заранее определённом порядке перезаписывает три дерева Git, останавливаясь тогда, когда вы ей скажете: 1. Перемещает ветку, на которую указывает HEAD _(останавливается на этом, если указана опция `--soft`)_ -2. Делает Индекс таким же как и HEAD _(останавливается на этом, если не указана опция `--hard`)_ -3. Делает Рабочий Каталог таким же как и Индекс. +2. Делает индекс таким же как и HEAD _(останавливается на этом, если не указана опция `--hard`)_ +3. Делает рабочий каталог таким же как и индекс. ==== Reset с указанием пути Основной форме команды `reset` (без опций `--soft` и `--hard`) вы также можете передавать путь, с которым она будет оперировать. В этом случае, `reset` пропустит первый шаг, а на остальных будет работать только с указанным файлом или набором файлов. Первый шаг пропускается, так как HEAD является указателем и не может ссылаться частично на один коммит, а частично на другой. -Но Индекс и Рабочий Каталог _могут_ быть изменены частично, поэтому `reset` выполняет шаги 2 и 3. +Но индекс и рабочий каталог _могут_ быть изменены частично, поэтому `reset` выполняет шаги 2 и 3. Итак, предположим вы выполнили команду `git reset file.txt`. Эта форма записи (так как вы не указали ни SHA-1 коммита, ни ветку, ни опций `--soft` или `--hard`) является сокращением для `git reset --mixed HEAD file.txt`, которая: 1. Перемещает ветку, на которую указывает HEAD _(будет пропущено)_ -2. Делает Индекс таким же как и HEAD _(остановится здесь)_ +2. Делает индекс таким же как и HEAD _(остановится здесь)_ -То есть, фактически, она копирует файл `file.txt` из HEAD в Индекс. +То есть, фактически, она копирует файл `file.txt` из HEAD в индекс. .Mixed reset с указанием пути image::images/reset-path1.png["Mixed reset с указанием пути"] @@ -242,8 +242,8 @@ image::images/reset-path2.png["Подготовленный файл для ин .Soft reset с указанием пути к конкретному коммиту image::images/reset-path3.png["Soft reset с указанием пути к конкретному коммиту"] -Можно считать, что, фактически, мы в Рабочем Каталоге вернули содержимое файла к версии *v1*, выполнили для него `git add`, а затем вернули содержимое обратно к версии *v3* (в действительности все эти шаги не выполняются). -Если сейчас мы выполним `git commit`, то будут сохранены изменения, которые возвращают файл к версии *v1*, но при этом файл в Рабочем Каталоге никогда не возвращался к такой версии. +Можно считать, что, фактически, мы в рабочем каталоге вернули содержимое файла к версии *v1*, выполнили для него `git add`, а затем вернули содержимое обратно к версии *v3* (в действительности все эти шаги не выполняются). +Если сейчас мы выполним `git commit`, то будут сохранены изменения, которые возвращают файл к версии *v1*, но при этом файл в рабочем каталоге никогда не возвращался к такой версии. Заметим, что как и команде `git add`, `reset` можно указывать опцию `--patch` для отмены индексации части содержимого. Таким способом вы можете избирательно отменять индексацию или откатывать изменения. @@ -287,7 +287,7 @@ image::images/reset-squash-r3.png["Репозиторий Git с объедин Но между этими командами есть два важных отличия. Во-первых, в отличие от `reset --hard`, команда `checkout` бережно относится к рабочему каталогу, и проверяет, что она не трогает файлы, в которых есть изменения. -В действительности, эта команда поступает немного умнее -- она пытается выполнить в Рабочем Каталоге простые слияния так, чтобы все файлы, которые вы _не_ изменяли, были обновлены. +В действительности, эта команда поступает немного умнее -- она пытается выполнить в Рабочем каталоге простые слияния так, чтобы все файлы, которые вы _не_ изменяли, были обновлены. С другой стороны, команда `reset --hard` просто заменяет всё целиком, не выполняя проверок. Второе важное отличие заключается в том, как эти команды обновляют HEAD. @@ -324,7 +324,7 @@ image::images/reset-checkout.png["`git checkout` и `git reset`"] [options="header", cols="3,^.^1,^.^1,^.^1,^.^1"] |================================ -^.^| Команда | HEAD | Индекс | Рабочий Каталог | Сохранность рабочего каталога? +^.^| Команда | HEAD | Индекс | Рабочий каталог | Сохранность рабочего каталога? ^.^| *На уровне коммитов* | | | | | `reset --soft [коммит]` | REF | НЕТ | НЕТ | ДА | `reset [коммит]` | REF | ДА | НЕТ | ДА From 2f80f2e38cab91a4cc1cd6e07cfc86d14a13dd1c Mon Sep 17 00:00:00 2001 From: Viktor Yegay Date: Sat, 3 Feb 2024 03:55:20 +0500 Subject: [PATCH 09/13] =?UTF-8?q?=D0=9C=D0=B5=D0=BB=D0=BA=D0=B8=D0=B5=20?= =?UTF-8?q?=D0=B8=D1=81=D0=BF=D1=80=D0=B0=D0=B2=D0=BB=D0=B5=D0=BD=D0=B8?= =?UTF-8?q?=D1=8F?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit -w -> -b - то, -> -- это то, “check” -> «check» «привет, мир», используемом для обучения работе с Mercurial -> «hello world», который все используют для изучения Mercurial: («успех» ('success'), «сбой» ('failure'), «ошибка» ('error')) -> («успех» («success»), «сбой» («failure»), «ошибка» («error»)) /etc/gitconfig -> [path]/etc/gitconfig "#git и #github -> #git, #github или #gitlab" ^4832fe2 -> ^1da177e4c3f4 <имя ветки> -> 3.6 -> 6.5 git -> Git git remote rm -> git remote remove или git remote rm: Git поверх HTTP/S -> Git через HTTPS HTTP/S, Git -> HTTPS, Git git-upload-pack -> send-pack авторами. -> авторами (файлы сопоставления ветвей и тегов указываются с помощью флага -B и -T соответственно). алиасов -> псевдонимов аннотированной метке -> аннотированном теге блока -> блок в ней -> туда ветку -> ветке если он был -> был ли он загрузить -> отправить их основную -> их в основную компании -> организации который -> которые меню через -> через меню он -> она опцией -n -> опцией `--dry-run` (или `-n`) что не всегда для слабонервных -> а это не всегда по силам слабонервным получите -> увидите метке -> теге метки -> теги метки, -> теги, отображение -> отображения Можно читать системные переменные -> Он может использовать переменные среды публично доступный -> публично-доступный очистки -> `clean` применяющий изменения -> коммитер запятой -> запятыми которую -> который этого -> УДАЛИТЬ создание и редактирование команд -> создавать и редактировать команды комментирование строк -> комментировать строки 'hello world' -> «hello world» --- C-git-commands.asc | 6 ++--- .../sections/first-time-setup.asc | 3 +-- book/01-introduction/sections/help.asc | 2 +- .../sections/getting-a-repository.asc | 1 + .../sections/recording-changes.asc | 1 + book/02-git-basics/sections/remotes.asc | 2 +- book/02-git-basics/sections/tagging.asc | 4 +-- book/02-git-basics/sections/undoing.asc | 7 +++++ .../sections/viewing-history.asc | 2 +- book/04-git-server/sections/gitlab.asc | 2 +- book/04-git-server/sections/protocols.asc | 26 ++++++++++++------- .../sections/contributing.asc | 2 +- .../sections/maintaining.asc | 2 +- .../sections/1-setting-up-account.asc | 2 +- book/06-github/sections/2-contributing.asc | 2 +- .../sections/4-managing-organization.asc | 4 +-- book/06-github/sections/5-scripting.asc | 10 +++---- .../sections/advanced-merging.asc | 4 +-- book/07-git-tools/sections/debugging.asc | 2 +- .../sections/revision-selection.asc | 5 ++-- .../sections/stashing-cleaning.asc | 4 +-- book/07-git-tools/sections/submodules.asc | 4 +-- book/07-git-tools/sections/subtree-merges.asc | 1 - book/08-customizing-git/sections/config.asc | 4 +-- book/08-customizing-git/sections/hooks.asc | 2 +- book/08-customizing-git/sections/policy.asc | 4 +-- .../sections/client-hg.asc | 4 +-- .../sections/client-p4.asc | 4 +-- .../sections/client-svn.asc | 4 ++- .../sections/import-custom.asc | 8 +++--- .../sections/import-hg.asc | 2 +- .../sections/import-p4.asc | 1 - .../10-git-internals/sections/environment.asc | 2 +- book/10-git-internals/sections/objects.asc | 10 +++++-- book/10-git-internals/sections/refs.asc | 2 +- book/10-git-internals/sections/refspec.asc | 2 +- .../sections/transfer-protocols.asc | 4 +-- .../sections/eclipse.asc | 2 +- book/B-embedding-git/sections/jgit.asc | 2 +- book/B-embedding-git/sections/libgit2.asc | 4 +-- book/introduction.asc | 2 +- ch06-github.asc | 2 +- 42 files changed, 90 insertions(+), 73 deletions(-) diff --git a/C-git-commands.asc b/C-git-commands.asc index 9b645c87..de92798b 100644 --- a/C-git-commands.asc +++ b/C-git-commands.asc @@ -309,7 +309,7 @@ Мы познакомились и разобрались с ней в разделе <> главы 2 и использовали на практике в разделе <> главы 5. -Мы научились создавать подписанные с помощью GPG метки, используя флаг `-s`, и проверять их, используя флаг `-v`, в разделе <> главы 7. +Мы научились создавать подписанные с помощью GPG теги, используя флаг `-s`, и проверять их, используя флаг `-v`, в разделе <> главы 7. === Совместная работа и обновление проектов @@ -389,9 +389,9 @@ ==== git show Команда `git show` отображает объект в простом и человекопонятном виде. -Обычно она используется для просмотра информации о метке или коммите. +Обычно она используется для просмотра информации о теге или коммите. -Впервые мы использовали её для просмотра информации об аннотированной метке в разделе <> главы 2. +Впервые мы использовали её для просмотра информации об аннотированном теге в разделе <> главы 2. В разделе <> главы 7 мы использовали её для показа коммитов, подпадающих под различные селекторы диапазонов. diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index 8edf80ab..ebb067af 100644 --- a/book/01-introduction/sections/first-time-setup.asc +++ b/book/01-introduction/sections/first-time-setup.asc @@ -22,7 +22,6 @@ В системах семейства Windows Git ищет файл `.gitconfig` в каталоге `$HOME` (`C:\Users\$USER` для большинства пользователей). Кроме того, Git ищет файл `[path]/etc/gitconfig`, но уже относительно корневого каталога MSys, который находится там, куда вы решили установить Git при запуске инсталлятора. - Если вы используете Git для Windows версии 2.х или новее, то так же обрабатывается файл конфигурации уровня системы, который имеет путь `C:\Documents and Settings\All Users\Application Data\Git\config` в Windows XP или `C:\ProgramData\Git\config` в Windows Vista и новее. Этот файл может быть изменён только командой `git config -f `, запущенной с правами администратора. @@ -113,7 +112,7 @@ color.diff=auto ... ---- -Некоторые ключи (названия) настроек могут отображаться несколько раз, потому что Git читает настройки из разных файлов (например, из `/etc/gitconfig` и `~/.gitconfig`). +Некоторые ключи (названия) настроек могут отображаться несколько раз, потому что Git читает настройки из разных файлов (например, из `[path]/etc/gitconfig` и `~/.gitconfig`). В таком случае Git использует последнее значение для каждого ключа. Также вы можете проверить значение конкретного ключа, выполнив `git config `:(((команды git, config))) diff --git a/book/01-introduction/sections/help.asc b/book/01-introduction/sections/help.asc index d47f0c12..098d5dc9 100644 --- a/book/01-introduction/sections/help.asc +++ b/book/01-introduction/sections/help.asc @@ -18,7 +18,7 @@ $ git help config ---- Эти команды хороши тем, что ими можно пользоваться всегда, даже без подключения к сети. -Если руководства и этой книги недостаточно и вам нужна персональная помощь, вы можете попытаться поискать её на каналах `#git` и `#github` IRC сервера Libera Chat, который доступен по адресу https://libera.chat/[^]. +Если руководства и этой книги недостаточно и вам нужна персональная помощь, вы можете попытаться поискать её на каналах `#git`, `#github` или `#gitlab` IRC сервера Libera Chat, который доступен по адресу https://libera.chat/[^]. Обычно там сотни людей, отлично знающих Git, которые могут помочь.(((IRC))) Так же, если вам нужно посмотреть только список опций и вы не хотите читать полную документацию по команде, вы можете использовать опцию `-h` для вывода краткой инструкции по использованию: diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index 176a1e83..188f11c0 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -72,6 +72,7 @@ $ git clone https://github.com/libgit2/libgit2 Эта команда создаёт каталог `libgit2`, инициализирует в нём подкаталог `.git`, скачивает все данные для этого репозитория и извлекает рабочую копию последней версии. Если вы перейдёте в только что созданный каталог `libgit2`, то увидите в нём файлы проекта, готовые для работы или использования. + Для того, чтобы клонировать репозиторий в каталог с именем, отличающимся от `libgit2`, необходимо указать желаемое имя, как параметр командной строки: [source,console] diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 4ac553df..aed359d8 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -41,6 +41,7 @@ Git также не обнаружил неотслеживаемых файло В 2020 году GitHub изменил имя ветки по умолчанию с `master` на `main`, другие же git-хостинг платформы последовали этому примеру. Поэтому, вы можете обнаружить, что ветка по умолчанию для новых репозиториев -- `main`, а не `master`. Более того, имя ветки по умолчанию можно изменить (как вы видели в <>), поэтому вам может встретиться и другое имя. + При этом Git продолжает использовать имя `master`, поэтому далее в книге мы используем именно его. ==== diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index 611fb267..bcd1ca3f 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -230,7 +230,7 @@ paul Стоит упомянуть, что это также изменит имена удалённых веток в вашем репозитории. То, к чему вы обращались как `pb/master`, теперь стало `paul/master`. -Если по какой-то причине вы хотите удалить удалённый репозиторий -- вы сменили сервер или больше не используете определённое зеркало, или кто-то перестал вносить изменения -- вы можете использовать `git remote rm`: +Если по какой-то причине вы хотите удалить удалённый репозиторий -- вы сменили сервер или больше не используете определённое зеркало, или кто-то перестал вносить изменения -- вы можете использовать `git remote remove` или `git remote rm`: [source,console] ---- diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index bb9e19d5..1781bea7 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -41,7 +41,7 @@ v1.8.5.5 ---- [NOTE] -.Для отображение тегов согласно шаблону требуются параметры `-l` или `--list` +.Для отображения тегов согласно шаблону требуются параметры `-l` или `--list` ==== Если вы хотите посмотреть весь список тегов, запуск команды `git tag` неявно подразумевает это и выводит полный список; использование параметров `-l` или `--list` в этом случае опционально. @@ -216,7 +216,7 @@ To git@github.com:schacon/simplegit.git * [new tag] v1.4-lw -> v1.4-lw ---- -Теперь, если кто-то клонирует (clone) или выполнит `git pull` из вашего репозитория, то он получит вдобавок к остальному и ваши метки. +Теперь, если кто-то клонирует (clone) или выполнит `git pull` из вашего репозитория, то он получит вдобавок к остальному и ваши теги. [NOTE] .`git push` отправляет оба типа тегов diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc index c6ea2cf4..fb940eef 100644 --- a/book/02-git-basics/sections/undoing.asc +++ b/book/02-git-basics/sections/undoing.asc @@ -39,6 +39,13 @@ $ git commit --amend Очевидно, смысл изменения коммитов в добавлении незначительных правок в последние коммиты и, при этом, в избежании засорения истории сообщениями вида «Ой, забыл добавить файл» или «Исправление грамматической ошибки». ==== +[NOTE] +==== +Изменяйте только те коммиты, которые всё ещё локальны и не были куда-то отправлены. +Изменение ранее отправленных коммитов и принудительное отправление ветки вызовет проблемы для ваших коллег. +Подробнее о том, что происходит, когда вы это делаете, и о том, как восстановиться, если вы находитесь на принимающей стороне, читайте <>. +==== + [[r_unstaging]] ==== Отмена индексации файла diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index 12fbecd1..87853c84 100644 --- a/book/02-git-basics/sections/viewing-history.asc +++ b/book/02-git-basics/sections/viewing-history.asc @@ -181,7 +181,7 @@ a11bef0 - Scott Chacon, 6 years ago : Initial commit Вам наверное интересно, какая же разница между _автором_ и _коммитером_. Автор -- это человек, изначально сделавший работу, а коммитер -- это человек, который последним применил эту работу. -Другими словами, если вы создадите патч для какого-то проекта, а один из основных членов команды этого проекта применит этот патч, вы оба получите статус участника -- вы как автор и основной член команды как коммитер. +Другими словами, если вы создадите патч для какого-то проекта, а один из основных членов команды этого проекта применит этот патч, вы оба получите статус участника -- вы как автор, а основной член команды как коммитер. Более детально мы рассмотрим разницу в главе <>. Опции `oneline` и `format` являются особенно полезными с опцией `--graph` команды `log`. diff --git a/book/04-git-server/sections/gitlab.asc b/book/04-git-server/sections/gitlab.asc index 1a9eec52..f93702f1 100644 --- a/book/04-git-server/sections/gitlab.asc +++ b/book/04-git-server/sections/gitlab.asc @@ -125,5 +125,5 @@ $ git clone https://server/namespace/project.git Каждый запрос на слияние допускает построчное обсуждение предлагаемого изменения (поддерживая облегчённое рецензирование кода), равно как и общее обсуждение. И те и другие могут присваиваться пользователям или организовываться в вехи (milestones). -Мы в основном сосредоточились на частях GitLab, связанных с git, но это -- довольно зрелая система, и она предоставляет много других возможностей, помогающих вашей команде работать совместно, например вики-страницы для проектов и инструменты поддержки системы. +Мы в основном сосредоточились на частях GitLab, связанных с Git, но это -- довольно зрелая система, и она предоставляет много других возможностей, помогающих вашей команде работать совместно, например вики-страницы для проектов и инструменты поддержки системы. Одно из преимуществ GitLab в том, что, однажды запустив и настроив сервер, вам редко придётся изменять конфигурацию или заходить на него по SSH; большинство административных и пользовательских действий можно выполнять через веб-браузер. diff --git a/book/04-git-server/sections/protocols.asc b/book/04-git-server/sections/protocols.asc index 831ddf61..7db10e60 100644 --- a/book/04-git-server/sections/protocols.asc +++ b/book/04-git-server/sections/protocols.asc @@ -133,7 +133,7 @@ $ git clone https://example.com/gitproject.git ===== Недостатки -На некоторых серверах Git поверх HTTP/S может быть немного сложнее в настройке по сравнению с SSH. +На некоторых серверах Git поверх HTTPS может быть немного сложнее в настройке по сравнению с SSH. Кроме этого, преимущества других протоколов доступа к Git перед Умным HTTP незначительны. Если вы используете HTTP для аутентифицированной отправки изменений, ввод учётных данных зачастую сложнее, чем при использовании SSH-ключей. @@ -168,7 +168,7 @@ $ git clone [user@]server:project.git SSH имеет множество достоинств. Во-первых, SSH достаточно легко настроить -- демоны SSH распространены, многие системные администраторы имеют опыт работы с ними и во многих дистрибутивах они предустановлены или есть утилиты для управления ими. Далее, доступ по SSH безопасен -- данные передаются зашифрованными по авторизованным каналам. -Наконец, так же как и протоколы HTTP/S, Git и локальный протокол, SSH эффективен благодаря максимальному сжатию данных перед передачей. +Наконец, так же как и протоколы HTTPS, Git и локальный протокол, SSH эффективен благодаря максимальному сжатию данных перед передачей. ===== Недостатки @@ -196,10 +196,18 @@ Git-протокол ― часто самый быстрый из доступ ===== Недостатки -Недостатком Git-протокола является отсутствие аутентификации. -Поэтому обычно не следует использовать этот протокол как единственный способ доступа к вашему проекту. -Обычно он используется в паре с SSH или HTTPS для нескольких разработчиков, имеющих доступ на запись, тогда как все остальные используют `git://` с доступом только на чтение. -Кроме того, это, вероятно, самый сложный для настройки протокол. -Вы должны запустить отдельный демон, для чего необходимо дополнительно настраивать `xinetd` или `systemd` или им подобные, что не всегда легко сделать. -Также необходимо, чтобы сетевой экран позволял доступ на порт 9418, который не относится к стандартным портам, всегда разрешённым в корпоративных брандмауэрах. -За сетевыми экранами крупных корпораций этот неизвестный порт часто заблокирован. +Из-за отсутствия TLS или другой криптографии клонирование через `git://` может привести к уязвимости выполнения произвольного кода, поэтому его следует избегать, если вы не знаете, что делаете. + +* Если вы запустите `git clone git://example.com/project.git`, злоумышленник, контролирующий, например, ваш маршрутизатор, может изменить репозиторий, который вы только что клонировали, вставив в него вредоносный код. +Если вы затем скомпилируете/запустите только что клонированный код, вы запустите вредоносный код. +По той же причине следует избегать запуска `+git clone http://example.com/project.git+`. + +* Запуск `+git clone https://example.com/project.git+` не сталкивается с той же проблемой (если только злоумышленник не может предоставить сертификат TLS для `example.com`). +Запуск `+git clone git@example.com:project.git+` сталкивается с этой проблемой только в том случае, если вы принимаете неверный отпечаток ключа SSH. + +Он также не имеет аутентификации, т. е. +любой может клонировать репозиторий (хотя часто это именно то, что вам нужно). +Это также, вероятно, самый сложный протокол в настройке. +Он должен запустить свой собственный демон, для чего требуется настройка `xinetd` или `systemd` или чего-то подобного, что не всегда легко. +Для этого также требуется доступ брандмауэра к порту 9418, который не является стандартным портом, который всегда разрешают корпоративные брандмауэры. +За большими корпоративными брандмауэрами этот малоизвестный порт обычно блокируется. diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index e849054d..722b82f3 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -243,7 +243,7 @@ From jessica@githost:simplegit image::images/small-team-5.png["История коммитов Джессики после получения изменений Джона"] Джессика считает, что её тематическая ветка готова, но так же хочет знать какие изменения следует слить со своей работой перед отправкой на сервер. -Для прояснения ситуации он выполняет команду `git log`: +Для прояснения ситуации она выполняет команду `git log`: [source,console] ---- diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 78d7ac25..a2934e6f 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -375,7 +375,7 @@ image::images/large-merges-2.png["Слияние тематических вет Если конфликты отсутствуют, то вы можете просто сдвинуть состояние ветки `master`, что обеспечивает линейность истории проекта. (((команды git, cherry-pick))) -Другим способом переместить предлагаемые изменений из одной ветки в другую является их отбор коммитов (cherry-pick). +Другим способом переместить предлагаемые изменений из одной ветки в другую -- это выборочный отбор (cherry-pick). Отбор в Git похож на перебазирование для одного коммита. В таком случае формируется патч для выбранного коммита и применяется к текущей ветке. Это полезно, когда в тематической ветке присутствует несколько коммитов, а вы хотите взять только один из них, или в тематической ветке только один коммит и вы предпочитаете использовать отбор вместо перебазирования. diff --git a/book/06-github/sections/1-setting-up-account.asc b/book/06-github/sections/1-setting-up-account.asc index a2f67824..64ebdcf5 100644 --- a/book/06-github/sections/1-setting-up-account.asc +++ b/book/06-github/sections/1-setting-up-account.asc @@ -26,7 +26,7 @@ GitHub предоставляет почти все свои функции дл (((SSH-ключи, с GitHub))) На данный момент вы можете подключаться к репозиториям Git используя протокол `https://` авторизуясь при помощи только что созданного логина и пароля. -Однако для того чтобы просто клонировать публично доступный проект, вам необязательно авторизовываться на сайте, но тем не менее, только что созданный аккаунт понадобится в то время, когда вы захотите загрузить (push) сделанные вами изменения. +Однако для того чтобы просто клонировать публично-доступный проект, вам необязательно авторизовываться на сайте, но тем не менее, только что созданный аккаунт понадобится в то время, когда вы захотите отправить (push) сделанные вами изменения. Если же вы хотите использовать SSH доступ, в таком случае вам понадобится добавить публичный SSH ключ. (Если же у вас нет публичного SSH ключа, вы можете его <>) diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index fbdbd8c5..af4e9e23 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -118,7 +118,7 @@ To https://github.com/tonychacon/blink <2> Создаём тематическую ветку <3> Вносим свои изменения <4> Проверяем изменения -<5> Фиксируем изменения в тематической ветку +<5> Фиксируем изменения в тематической ветке <6> Отправляем новую ветку в нашу копию на GitHub Теперь, если мы зайдём на страничку нашей копии на GitHub, мы увидим, что GitHub заметил наши изменения и предлагает открыть запрос на слияние с помощью большой зелёной кнопки. diff --git a/book/06-github/sections/4-managing-organization.asc b/book/06-github/sections/4-managing-organization.asc index 6531c483..318414be 100644 --- a/book/06-github/sections/4-managing-organization.asc +++ b/book/06-github/sections/4-managing-organization.asc @@ -17,11 +17,11 @@ image::images/neworg.png["Пункт меню «New organization»"] Для начала, следует указать название вашей организации и ввести email адрес в качестве основного способа связи. После этого можно приглашать людей в качестве совладельцев аккаунта. -Следуйте инструкциям и в скором времени вы станете владельцем новой компании. +Следуйте инструкциям и в скором времени вы станете владельцем новой организации. Организации, как и персональные аккаунты, бесплатны, если вы планируете работать над проектами с открытым исходным кодом. Как владельцу организации, при клонировании репозитория вам будет предложено сохранить его в окружение организации. -При создании нового репозитория, вы можете его сохранить как в персональном окружении, так и в окружении любой компании, владельцем которой вы являетесь. +При создании нового репозитория, вы можете его сохранить как в персональном окружении, так и в окружении любой организации, владельцем которой вы являетесь. Так же вы автоматически начинаете отслеживать все создаваемые репозитории в организации. Как для <>, так и для организации вы можете загрузить отдельную картинку. diff --git a/book/06-github/sections/5-scripting.asc b/book/06-github/sections/5-scripting.asc index 42ad0e7f..03ec9812 100644 --- a/book/06-github/sections/5-scripting.asc +++ b/book/06-github/sections/5-scripting.asc @@ -22,7 +22,7 @@ image::images/scripting-01-services.png[Services and hooks] Вы можете выбирать из десятков сервисов, большинство из которых интегрируются в другие коммерческие системы и системы с открытым исходным кодом. Большинство из них предназначены для сервисов непрерывной интеграции, систем отслеживания ошибок и проблем, систем чатов и систем документации. Мы рассмотрим настройку очень простого хука электронной почты. -Если вы выберете «email» в раскрывающемся списке «Добавить сервис» («Add Service»), вы получите экран конфигурации, например <>. +Если вы выберете «email» в раскрывающемся списке «Добавить сервис» («Add Service»), вы увидите экран конфигурации, например <>. [[r_service_config]] .Конфигурация службы электронной почты @@ -98,14 +98,14 @@ end Чтобы разработать и протестировать что-то подобное, у вас есть хорошая консоль разработчика на том же экране, где вы устанавливаете связь. Вы можете увидеть последние несколько доставок, которые GitHub пытался сделать для этого вебхука. -Для каждого хука вы можете узнать, когда он был доставлен, если он был успешным, а также тело и заголовки как для запроса, так и для ответа. +Для каждого хука вы можете узнать, когда он был доставлен, был ли он успешным, а также тело и заголовки как для запроса, так и для ответа. Это делает невероятно простым тестирование и отладку ваших хуков. [[r_web_hook_debug]] .Информация об отладке вебхуков image::images/scripting-04-webhook-debug.png[Webhook debug] -Другая замечательная особенность этого заключается в том, что вы можете повторно доставить любые полезные данные, чтобы легко протестировать свой сервис. +Другая замечательная особенность заключается в том, что вы можете повторно доставить любые полезные данные, чтобы легко протестировать свой сервис. Для получения дополнительной информации о том, как писать вебхуки и обо всех различных типах событий, которые вы можете прослушивать, перейдите к документации GitHub Developer по адресу https://developer.github.com/webhooks/[^]. @@ -221,7 +221,7 @@ $ curl -H "Content-Type: application/json" \ .Комментарий, отправленный из GitHub API image::images/scripting-06-comment.png[API Comment] -Вы можете использовать API, чтобы делать практически всё, что вы можете делать на веб-сайте: создавать и устанавливать вехи (milestones), назначать людей для проблем и запросов на слияние, создавать и изменять метки, получать доступ к данным коммитов, создавать новые коммиты и ветки, открывать, закрывать или объединение запросов на слияние, создание и редактирование команд, комментирование строк кода в запросе на слияние, поиск по сайту и так далее. +Вы можете использовать API, чтобы делать практически всё, что вы можете делать на веб-сайте: создавать и устанавливать вехи (milestones), назначать людей для проблем и запросов на слияние, создавать и изменять метки, получать доступ к данным коммитов, создавать новые коммиты и ветки, открывать, закрывать или объединение запросов на слияние, создавать и редактировать команды, комментировать строки кода в запросе на слияние, поиск по сайту и так далее. ==== Изменение статуса запроса на слияние @@ -279,7 +279,7 @@ end Надеюсь, следовать этому довольно просто. В этом обработчике вебхука мы просматриваем каждый только что отправленный коммит, ищем строку «Signed-off-by» в сообщении коммита и, наконец, отправляем POST через HTTP в `/repos// /statuses/` Конечная точка API со статусом. -В этом случае вы можете отправить состояние («успех» ('success'), «сбой» ('failure'), «ошибка» ('error')), описание того, что произошло, целевой URL-адрес, по которому пользователь может перейти для получения дополнительной информации, и «контекст» в случае наличия нескольких статусов за один коммит. +В этом случае вы можете отправить состояние («успех» («success»), «сбой» («failure»), «ошибка» («error»)), описание того, что произошло, целевой URL-адрес, по которому пользователь может перейти для получения дополнительной информации, и «контекст» в случае наличия нескольких статусов за один коммит. Например, сервис тестирования может предоставить статус, а сервис проверки, подобная этой, также может предоставить статус — поле «контекст» — это то, как они различаются. Если кто-то откроет новый запрос на слияние на GitHub и этот хук настроен, вы можете увидеть что-то вроде <>. diff --git a/book/07-git-tools/sections/advanced-merging.asc b/book/07-git-tools/sections/advanced-merging.asc index 950b29a2..3fc86081 100644 --- a/book/07-git-tools/sections/advanced-merging.asc +++ b/book/07-git-tools/sections/advanced-merging.asc @@ -22,7 +22,7 @@ Git упрощает повторные слияния с одной и той Если при выполнении слияния вы не сохраните сделанные изменения, то некоторые из описанных ниже приёмов могут привести к утрате этих наработок. Давайте рассмотрим очень простой пример. -Допустим, у нас есть файл с исходниками на Ruby, выводящими на экран строку 'hello world'. +Допустим, у нас есть файл с исходниками на Ruby, выводящими на экран строку «hello world». [source,ruby] ---- @@ -251,7 +251,7 @@ index 36c06c8..44d0a25 100755 Итак, здесь мы можем легко увидеть что же произошло с нашей веткой, какие изменения в действительности внесло слияние в данный файл -- изменение только одной строки. Если вы хотите узнать чем результат слияния отличается от сливаемой ветки, то можете выполнить команду `git diff --theirs`. -В этом и следующем примере мы используем опцию `-w` для того, чтобы не учитывать изменения в пробельных символах, так как мы сравниваем результат с тем, что есть в Git, а не с нашим исправленным файлом `hello.theirs.rb`. +В этом и следующем примере мы используем опцию `-b` для того, чтобы не учитывать изменения в пробельных символах, так как мы сравниваем результат с тем, что есть в Git, а не с нашим исправленным файлом `hello.theirs.rb`. [source,console] ---- diff --git a/book/07-git-tools/sections/debugging.asc b/book/07-git-tools/sections/debugging.asc index e73e8c56..545292d7 100644 --- a/book/07-git-tools/sections/debugging.asc +++ b/book/07-git-tools/sections/debugging.asc @@ -33,7 +33,7 @@ b8b0618cf6fab (Cheng Renquan 2009-05-26 16:03:07 +0800 70) KBUILD_VERBOSE = $ Обратите внимание, что первое поле -- это неполная SHA-1 сумма последнего коммита, который изменял соответствующую строку. Следующими двумя полями являются значения, извлечённые из этого коммита -- имя автора и время создания коммита -- таким образом, вы можете легко увидеть кто изменял строку и когда. После этого следуют номер строки и содержимое файла. -Обратите внимание на строки со значением `^4832fe2` в поле коммита, так обозначаются те строки, которые были в первом коммите этого файла. +Обратите внимание на строки со значением `^1da177e4c3f4` в поле коммита, так обозначаются те строки, которые были в первом коммите этого файла. Этот коммит был сделан, когда данный файл был впервые добавлен в проект и с тех пор эти строки не были изменены. Немного сбивает с толку то, что вы уже видели в Git, по крайней мере, три различных варианта использования символа `^` для изменения SHA-1 коммита, в данном случае этот символ имеет такое значение. diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc index fe48e87f..a30c9be2 100644 --- a/book/07-git-tools/sections/revision-selection.asc +++ b/book/07-git-tools/sections/revision-selection.asc @@ -60,8 +60,7 @@ a11bef0 Initial commit ---- Обычно от восьми до десяти символов более чем достаточно для сохранения уникальности значений в проекте. - -Например, в ядре Linux, который является довольно большим проектом с более чем 450 тыс. коммитов и 3.6 млн. объектов, отсутствуют объекты, чьи SHA-1 совпадают более чем в 11 первых символах. +Например, по состоянию на февраль 2019 года ядро Linux (это довольно крупный проект) имеет более 875 тыс. коммитов и почти 7 млн. объектов в своей базе данных объектов, при этом нет двух объектов, у которых SHA-1 идентичны в первых 12 символах. [NOTE] .Небольшое замечание о SHA-1 @@ -80,7 +79,7 @@ a11bef0 Initial commit 2^80^ -- это 1.2 × 10^24^, или 1 миллион миллиардов миллиардов, что в 1200 раз больше количества песчинок на земле. Приведём пример, чтобы дать вам представление, чего будет стоить получение коллизии SHA-1. -Если бы все 6.5 миллиардов человек на Земле были программистами, и ежесекундно каждый из них производил количество кода, эквивалентное всей истории ядра Linux (3.6 миллиона Git-объектов), и отправлял его в один огромный Git репозитории, то потребовалось бы около 2 лет, пока этот репозиторий накопил бы количество объектов, достаточное для 50% вероятности возникновения SHA-1 коллизии. +Если бы все 6.5 миллиардов человек на Земле были программистами, и ежесекундно каждый из них производил количество кода, эквивалентное всей истории ядра Linux (6.5 миллиона Git-объектов), и отправлял его в один огромный Git репозитории, то потребовалось бы около 2 лет, пока этот репозиторий накопил бы количество объектов, достаточное для 50% вероятности возникновения SHA-1 коллизии. Более вероятно, что каждый член вашей команды в одну и туже ночь будет атакован и убит волками в несвязанных друг с другом происшествиях. Если выделить на это несколько тысяч долларов вычислительной мощности, можно будет синтезировать два файла с одним и тем же хешем, что было доказано проектом https://shattered.io/[^] в феврале 2017 года. diff --git a/book/07-git-tools/sections/stashing-cleaning.asc b/book/07-git-tools/sections/stashing-cleaning.asc index fc34c3e5..59594fb8 100644 --- a/book/07-git-tools/sections/stashing-cleaning.asc +++ b/book/07-git-tools/sections/stashing-cleaning.asc @@ -238,7 +238,7 @@ Dropped refs/stash@{0} (29d385a81d163dfd45a452a2ce816487a6b8b014) Для удаления всех неотслеживаемых файлов в вашем рабочем каталоге, вы можете выполнить команду `git clean -f -d`, которая удалит все файлы и также все каталоги, которые в результате станут пустыми. Параметр `-f` (сокращение от слова force -- заставить) означает принудительное удаление, подчёркивая, что вы действительно хотите это сделать, и требуется, если переменная конфигурации Git `clean.requireForce` явным образом не установлена в `false`. -Если вы хотите только посмотреть, что будет сделано, вы можете запустить команду с опцией `-n`, которая означает «имитируй работу команды и скажи мне, что ты _будешь_ удалять». +Если вы хотите только посмотреть, что будет сделано, вы можете запустить команду с опцией `--dry-run` (или `-n`), которая означает «имитируй работу команды и скажи мне, что ты _будешь_ удалять». [source,console] ---- @@ -271,7 +271,7 @@ Would remove tmp/ Если вы не знаете, что сделает при запуске команда `git clean`, всегда сначала выполняйте её с опцией `-n`, чтобы проверить дважды, перед заменой `-n` на `-f` и выполнением настоящей очистки. Другой способ, который позволяет вам более тщательно контролировать сам процесс -- это выполнение команды с опцией `-i` (в «интерактивном» режиме). -Ниже выполнена команда очистки в интерактивном режиме. +Ниже выполнена команда `clean` в интерактивном режиме. [source,console] ---- diff --git a/book/07-git-tools/sections/submodules.asc b/book/07-git-tools/sections/submodules.asc index a0323573..ef096627 100644 --- a/book/07-git-tools/sections/submodules.asc +++ b/book/07-git-tools/sections/submodules.asc @@ -608,7 +608,7 @@ to push them to a remote. Как видите, эта команда также даёт нам некоторые полезные советы о том, что мы могли бы делать дальше. Самый простой вариант -- это пройти по всем подмодулям и вручную отправить изменения на удалённые серверы, чтобы гарантировать доступность изменений другим людям, а затем попытать отправить изменения снова. -Если вы хотите использовать поведение "`check`" при каждом выполнении `git push`, то его можно установить поведением по умолчанию, выполнив команду `git config push.recurseSubmodules check`. +Если вы хотите использовать поведение «check» при каждом выполнении `git push`, то его можно установить поведением по умолчанию, выполнив команду `git config push.recurseSubmodules check`. Другой вариант -- это использовать значение «`on-demand`», тогда Git попытается сделать всё вышеописанное за вас. @@ -880,7 +880,7 @@ $ git config alias.supdate 'submodule update --remote --merge' ===== Переключение веток Например, переключение веток с подмодулями в них может оказаться довольно запутанным, особенно для версий Git старше 2.13. -Если вы создадите новую ветку и добавите в ней подмодуль, а затем переключитесь обратно на ветку без подмодуля, то каталог подмодуля всё равно останется и будет неотслеживаемым: +Если вы создадите новую ветку и добавите туда подмодуль, а затем переключитесь обратно на ветку без подмодуля, то каталог подмодуля всё равно останется и будет неотслеживаемым: [source,console] ---- diff --git a/book/07-git-tools/sections/subtree-merges.asc b/book/07-git-tools/sections/subtree-merges.asc index 1a9f83fe..3b58599a 100644 --- a/book/07-git-tools/sections/subtree-merges.asc +++ b/book/07-git-tools/sections/subtree-merges.asc @@ -67,7 +67,6 @@ $ git pull ---- Затем мы можем слить эти изменения обратно в нашу ветку `master`. - Для того, чтобы получить изменения и заполнить сообщение коммита используйте параметр `--squash`, вместе с опцией `-Xsubtree` рекурсивной стратегии слияния. Вообще-то, по умолчанию используется именно рекурсивная стратегия слияния, но мы указали и её тоже для пущей ясности. diff --git a/book/08-customizing-git/sections/config.asc b/book/08-customizing-git/sections/config.asc index e340aa46..98a97b01 100644 --- a/book/08-customizing-git/sections/config.asc +++ b/book/08-customizing-git/sections/config.asc @@ -14,7 +14,7 @@ $ git config --global user.email johndoe@example.com Сейчас вы познакомитесь с несколькими наиболее интересными опциями, которые можно установить для настройки поведения Git. Кратко: Git использует набор конфигурационных файлов для изменения стандартного поведения, если это необходимо. -Вначале, Git ищет настройки в файле `/etc/gitconfig`, который содержит настройки для всех пользователей в системе и всех репозиториев. +Вначале, Git ищет настройки в файле `[path]/etc/gitconfig`, который содержит настройки для всех пользователей в системе и всех репозиториев. Если передать опцию `--system` команде `git config`, то операции чтения и записи будут производиться именно с этим файлом. Следующее место, куда смотрит Git -- это файл `~/.gitconfig` (или `~/.config/git/config`), который хранит настройки конкретного пользователя. @@ -24,7 +24,7 @@ $ git config --global user.email johndoe@example.com Эти значения относятся только к текущему репозиторию и доступны при передаче параметра `--local` команде `git config`. (Если уровень настроек не указан явно, то подразумевается локальный.) -Каждый из этих уровней (системный, глобальный, локальный) переопределяет значения предыдущего уровня, например, значения из `.git/config` важнее значений из `/etc/gitconfig`. +Каждый из этих уровней (системный, глобальный, локальный) переопределяет значения предыдущего уровня, например, значения из `.git/config` важнее значений из `[path]/etc/gitconfig`. [NOTE] ==== diff --git a/book/08-customizing-git/sections/hooks.asc b/book/08-customizing-git/sections/hooks.asc index bfc4c902..9ca295d0 100644 --- a/book/08-customizing-git/sections/hooks.asc +++ b/book/08-customizing-git/sections/hooks.asc @@ -25,7 +25,7 @@ [NOTE] ==== -Необходимо отметить, что клиентские хуки *НЕ* копируются при клонировании репозитория. +Необходимо отметить, что клиентские хуки *не* копируются при клонировании репозитория. Если вы намерены использовать такие скрипты для обеспечения соблюдения политики, то вам следует использовать серверные хуки; например <>. ==== diff --git a/book/08-customizing-git/sections/policy.asc b/book/08-customizing-git/sections/policy.asc index 97ee787b..a64b6c9b 100644 --- a/book/08-customizing-git/sections/policy.asc +++ b/book/08-customizing-git/sections/policy.asc @@ -116,7 +116,7 @@ check_message_format Затем обновить хук `update`, чтобы он использовал эти правила при просмотре списка файлов в отправляемых коммитах для определения наличия прав доступа ко всем этим файлам у отправляющего пользователя. Первое, что надо сделать -- это создать список контроля доступа. -Здесь следует использовать формат, который очень похож на CVS и представляет собой список строк, в каждой из которых первое поле имеет значение `avail` или `unavail`, второе поле содержит список пользователей, разделённых запятой, а третье поле -- это путь к файлу или каталогу, для которого применяется это правило (пустое значение подразумевает отсутствие ограничения). +Здесь следует использовать формат, который очень похож на CVS и представляет собой список строк, в каждой из которых первое поле имеет значение `avail` или `unavail`, второе поле содержит список пользователей, разделённых запятыми, а третье поле -- это путь к файлу или каталогу, для которого применяется это правило (пустое значение подразумевает отсутствие ограничения). В качестве разделителя для этих полей применяется вертикальная черта (`|`). В случае, когда у вас есть группа администраторов, несколько технических писателей с доступом к каталогу `doc` и один разработчик, у которого есть доступ только к каталогам `lib` и `tests`, файл со списком контроля доступа будет выглядеть так: @@ -282,7 +282,7 @@ error: failed to push some refs to 'git@gitserver:project.git' ==== Клиентские хуки Недостатком этого подхода является неизбежное нытьё ваших пользователей, к которому приводит отклонение отправки коммитов. -Получение отказа в последний момент при отправке тщательно продуманной работы может сильно расстроить и вызвать непонимание; кроме этого, придётся ещё актуализировать историю, что не всегда для слабонервных. +Получение отказа в последний момент при отправке тщательно продуманной работы может сильно расстроить и вызвать непонимание; кроме этого, придётся ещё актуализировать историю, а это не всегда по силам слабонервным. Решением в данной ситуации является предоставление клиентских хуков, которые пользователи могут использовать для получения уведомлений, когда они делают то, что сервер скорее всего отклонит. Таким образом они могут исправить любые проблемы до создания коммита и до того, как исправление проблемы станет гораздо сложнее. diff --git a/book/09-git-and-other-scms/sections/client-hg.asc b/book/09-git-and-other-scms/sections/client-hg.asc index e7161dc9..3c21c408 100644 --- a/book/09-git-and-other-scms/sections/client-hg.asc +++ b/book/09-git-and-other-scms/sections/client-hg.asc @@ -38,7 +38,7 @@ $ pip install mercurial Теперь можно отжигать! Всё что потребуется -- репозиторий Mercurial с которым вы можете работать. -К счастью, подойдёт любой, так что мы воспользуемся репозиторием «привет, мир», используемом для обучения работе с Mercurial. +К счастью, подойдёт любой, так что мы воспользуемся репозиторием «hello world», используемом для обучения работе с Mercurial. [source,console] ---- @@ -121,7 +121,7 @@ $ git cat-file -p ac9117f Итак, `refs/notes/hg` указывает на дерево, которое содержит список других объектов и имён. Команда `git ls-tree` выводит права доступа, тип, хеш и имя файла для содержимого дерева. -Наконец, добравшись до первого элемента дерева, мы обнаружим, что это блоб с названием `ac9117f` (SHA-1 коммита, на которую указывает ветка `master`), содержащий `0a04b98` (идентификатор последней ревизии ветки `default` в Mercurial). +Наконец, добравшись до первого элемента дерева, мы обнаружим, что это блоб с названием `ac9117f` (SHA-1 коммита, на который указывает ветка `master`), содержащий `0a04b98` (идентификатор последней ревизии ветки `default` в Mercurial). Всё это немного запутанно, но хорошие новости в том, что, по большому счёту, нам не нужно беспокоится об организации данных в `git-remote-hg`. В целом, работа с Mercurial сервером не сильно отличается от работы с Git сервером. diff --git a/book/09-git-and-other-scms/sections/client-p4.asc b/book/09-git-and-other-scms/sections/client-p4.asc index 1bef84d9..ef21173c 100644 --- a/book/09-git-and-other-scms/sections/client-p4.asc +++ b/book/09-git-and-other-scms/sections/client-p4.asc @@ -162,10 +162,8 @@ view = //depot/project1/main/... project1/... Последний файл, который мы обсудим, это `users/p4gf_usermap`; в нём задаётся отображение пользователей Perforce на пользователей Git. Возможно, вам не пригодится этот файл. - -Когда Git Fusion преобразовывает набор изменений Perforce в Git коммит, он находит пользователя в этом файле и использует хранящиеся здесь адрес электронной почты и полное имя для заполнения полей «автор» и «применяющий изменения» в Git. +Когда Git Fusion преобразовывает набор изменений Perforce в Git коммит, он находит пользователя в этом файле и использует хранящиеся здесь адрес электронной почты и полное имя для заполнения полей «автор» и «коммитер» в Git. При обратном процессе ищется пользователь Perforce с адресом электронной почты из поля «автор» Git коммитов и используется далее для изменения. - В большинстве случаев это нормальное поведение, но что будет, если соответствия выглядят так: [source] diff --git a/book/09-git-and-other-scms/sections/client-svn.asc b/book/09-git-and-other-scms/sections/client-svn.asc index 5d674713..b57d6422 100644 --- a/book/09-git-and-other-scms/sections/client-svn.asc +++ b/book/09-git-and-other-scms/sections/client-svn.asc @@ -309,10 +309,12 @@ Fast-forwarded master to refs/remotes/origin/trunk. ===== Проблемы с Git-ветвлением -После того как вы привыкните к Git, вам понравится создавать тематические ветки, работать в них и сливать их основную ветку разработки. +После того как вы привыкните к Git, вам понравится создавать тематические ветки, работать в них и сливать их в основную ветку разработки. Если работаете с Subversion сервером через `git svn`, вам придётся перемещать изменения, а не проводить слияния. Причина кроется в линейности истории в Subversion -- в нём принята несколько иная концепция ветвления и слияния -- так что `git svn` учитывает лишь первого родителя любого коммита при преобразовании её в SVN формат. +Предположим, ваша история выглядит следующим образом: вы создали ветку `experiment`, сделали два коммита, а затем слили их обратно в `master`. Когда вы выполните `dcommit`, вы увидите такой вывод: + [source,console] ---- $ git svn dcommit diff --git a/book/09-git-and-other-scms/sections/import-custom.asc b/book/09-git-and-other-scms/sections/import-custom.asc index 3ecb1517..6ccad138 100644 --- a/book/09-git-and-other-scms/sections/import-custom.asc +++ b/book/09-git-and-other-scms/sections/import-custom.asc @@ -31,7 +31,6 @@ current Как и в разделе <> главы 8, мы проделаем это на Ruby, потому что это тот язык, с которым мы обычно работаем, и его легко читать. Вы можете использовать любой другой язык -- всё что требуется, это вывести нужную информацию в стандартный поток вывода. - Если вы работаете на Windows, будьте особо осторожными с переводами строк: `fast-import` ожидает лишь символы перевода строки (LF), но не возврат каретки + перевод строки (CRLF), как принято в Windows. Для начала перейдём в исходный каталог и определим подкаталоги, содержащие состояния проекта в разные моменты времени, которые будут использованы для построения соответствующих коммитов. @@ -55,10 +54,9 @@ Dir.chdir(ARGV[0]) do end ---- -Вы выполняете функцию `print_export` внутри каждого каталога. -Она принимает на вход текущий каталог и результат предыдущего вызова и помечает текущий каталог, возвращая данные для последующих вызовов, таким образом связывая коммиты. -Метки используются для связи коммитов вместе. -Итак, первым делом нужно сгенерировать метку по каталогу: +Вы запускаете `print_export` внутри каждого каталога, который принимает манифест и метку предыдущего снимка и возвращает манифест и метку этого; таким образом вы сможете правильно связать их. +«Mark» -- это термин `fast-import` для идентификатора, который вы присваиваете коммиту; создавая коммиты, вы присваиваете каждому из них метку, которую можно использовать для ссылки на него из других коммитов. +Итак, первое, что нужно сделать в вашем методе `print_export` -- это сгенерировать метку из имени каталога: [source,ruby] ---- diff --git a/book/09-git-and-other-scms/sections/import-hg.asc b/book/09-git-and-other-scms/sections/import-hg.asc index 2c498f67..7395dbb9 100644 --- a/book/09-git-and-other-scms/sections/import-hg.asc +++ b/book/09-git-and-other-scms/sections/import-hg.asc @@ -63,7 +63,7 @@ $ cd /tmp/converted $ /tmp/fast-export/hg-fast-export.sh -r /tmp/hg-repo -A /tmp/authors ---- -Флаг `-r` указывает на подлежащий конвертации Mercurial репозиторий, а флаг `-A` задаёт файл с соответствиями между авторами. +Флаг `-r` указывает на подлежащий конвертации Mercurial репозиторий, а флаг `-A` задаёт файл с соответствиями между авторами (файлы сопоставления ветвей и тегов указываются с помощью флага `-B` и `-T` соответственно). Скрипт пробегается по наборам изменений Mercurial и преобразует их в скрипт для `fast-import` в Git (мы поговорим об этом инструменте чуть позже). Процесс конвертации займёт некоторое время (хотя и _намного_ меньше, чем при конвертации по сети), а мы пока можем наблюдать за подробным выводом в консоли: diff --git a/book/09-git-and-other-scms/sections/import-p4.asc b/book/09-git-and-other-scms/sections/import-p4.asc index 33c2fe4d..22031286 100644 --- a/book/09-git-and-other-scms/sections/import-p4.asc +++ b/book/09-git-and-other-scms/sections/import-p4.asc @@ -17,7 +17,6 @@ Git Fusion делает процесс переноса вполне безбо `git-p4` также можно использовать для переноса репозитория. В качестве примера мы импортируем проект «Jam» из публичного депо Perforce. - Вначале нужно указать адрес депо в переменной окружения `P4PORT`. [source,console] diff --git a/book/10-git-internals/sections/environment.asc b/book/10-git-internals/sections/environment.asc index a389a7a9..d5f23b25 100644 --- a/book/10-git-internals/sections/environment.asc +++ b/book/10-git-internals/sections/environment.asc @@ -131,7 +131,7 @@ Git ведёт достаточно подробный логи выполняе * Абсолютный путь, начинающийся с `/` -- вывод будет производиться в указанный файл. *`GIT_TRACE`* задаёт журналирование действий, не подпадающих под какую-либо определённую категорию. -Это включает в себя раскрытие алиасов и вызовы внешних программ. +Это включает в себя раскрытие псевдонимов и вызовы внешних программ. [source,console] ---- diff --git a/book/10-git-internals/sections/objects.asc b/book/10-git-internals/sections/objects.asc index fe3094bc..788c0bb3 100644 --- a/book/10-git-internals/sections/objects.asc +++ b/book/10-git-internals/sections/objects.asc @@ -91,7 +91,7 @@ $ find .git/objects -type f .git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 ---- -Теперь можно откатить файл к его первой версии: +На этом этапе вы можете удалить локальную копию этого файла `test.txt`, а затем использовать Git для получения из базы данных объектов либо первой сохранённой версии: [source,console] ---- @@ -257,7 +257,13 @@ $ echo 'First commit' | git commit-tree d8329f fdf4fc3344e67ab068f836878b6c4951e3b15f3d ---- -Полученный вами хеш будет отличаться, так как отличается дата создания и информация об авторе. +[NOTE] +==== +Вы получите другое значение хеш-функции из-за разного времени создания и данных автора. +Более того, хотя в принципе любой объект коммита может быть воспроизведён точно с учетом этих данных, исторические детали конструкции этой книги означают, что напечатанные хеши коммитов могут не соответствовать данным коммитам. +Далее в этой главе замените хэши коммитов и тегов своими собственными контрольными суммами. +==== + Далее в этой главе используйте собственные хеши коммитов и тегов. Просмотреть созданный объект коммита можно командой `cat-file`: diff --git a/book/10-git-internals/sections/refs.asc b/book/10-git-internals/sections/refs.asc index c5e018bb..d27b4867 100644 --- a/book/10-git-internals/sections/refs.asc +++ b/book/10-git-internals/sections/refs.asc @@ -67,7 +67,7 @@ image::images/data-model-4.png["Объекты в каталоге .git, а та [[r_the_head]] ==== HEAD -Как же Git получает хеш последнего коммита при выполнении `git branch <имя ветки>`? +Как же Git получает хеш последнего коммита при выполнении `git branch `? Ответ кроется в файле HEAD. Файл HEAD -- это символическая ссылка на текущую ветку. diff --git a/book/10-git-internals/sections/refspec.asc b/book/10-git-internals/sections/refspec.asc index efd4671b..192b50c5 100644 --- a/book/10-git-internals/sections/refspec.asc +++ b/book/10-git-internals/sections/refspec.asc @@ -2,7 +2,7 @@ === Спецификации ссылок На протяжении всей книги мы использовали довольно простые соответствия между локальными ветками и ветками в удалённых репозиториях, но всё может быть чуть сложнее. -Допустим, вы добавили удалённый репозиторий: +Допустим, вы следовали последним парам разделов и создали небольшой локальный репозиторий Git, а теперь хотите добавить к нему _удалённый_: [source,console] ---- diff --git a/book/10-git-internals/sections/transfer-protocols.asc b/book/10-git-internals/sections/transfer-protocols.asc index 4db28ddc..85b718e4 100644 --- a/book/10-git-internals/sections/transfer-protocols.asc +++ b/book/10-git-internals/sections/transfer-protocols.asc @@ -200,8 +200,8 @@ $ ssh -x git@server "git-receive-pack 'simplegit-progit.git'" 0000 ---- -Это всё, что передаётся в ответ на первый запрос. -Затем клиент делает второй запрос, на этот раз `POST`, передавая данные, полученные от команды `git-upload-pack`. +Вот и закончился первый обмен клиент-сервер. +Затем клиент делает ещё один запрос, на этот раз `POST`, с данными, которые предоставляет `send-pack`. [source] ---- diff --git a/book/A-git-in-other-environments/sections/eclipse.asc b/book/A-git-in-other-environments/sections/eclipse.asc index 1c4996e0..51d56faf 100644 --- a/book/A-git-in-other-environments/sections/eclipse.asc +++ b/book/A-git-in-other-environments/sections/eclipse.asc @@ -7,4 +7,4 @@ .EGit в Eclipse image::images/egit.png["EGit в Eclipse"] -EGit поставляется с неплохой документацией, доступной меню через `Help` > `Help Contents` в разделе `EGit Documentation`. +EGit поставляется с неплохой документацией, доступной через меню `Help` > `Help Contents` в разделе `EGit Documentation`. diff --git a/book/B-embedding-git/sections/jgit.asc b/book/B-embedding-git/sections/jgit.asc index dba590c9..ce2f4938 100644 --- a/book/B-embedding-git/sections/jgit.asc +++ b/book/B-embedding-git/sections/jgit.asc @@ -53,7 +53,7 @@ Repository existingRepo = new FileRepositoryBuilder() ---- Вызовы методов билдера можно объединять в цепочку чтобы указать всю информацию для поиска репозитория независимо от того, знает ли ваша программа его точное месторасположение или нет. -Можно читать системные переменные (`.readEnvironment()`), начать поиск с произвольного места в рабочем каталоге (`.setWorkTree(…).findGitDir()`), или просто открыть каталог `.git` по указанному пути. +Он может использовать переменные среды (`.readEnvironment()`), начать поиск с произвольного места в рабочем каталоге (`.setWorkTree(…).findGitDir()`), или просто открыть каталог `.git` по указанному пути. После создания объекта типа `Repository`, вам будет доступен широкий набор операций над ним. Краткий пример: diff --git a/book/B-embedding-git/sections/libgit2.asc b/book/B-embedding-git/sections/libgit2.asc index 586a200a..63a9ca9c 100644 --- a/book/B-embedding-git/sections/libgit2.asc +++ b/book/B-embedding-git/sections/libgit2.asc @@ -40,7 +40,7 @@ git_repository_free(repo); `git_object` является «родительским» для некоторых других типов; внутренняя структура всех этих типов одинаковая и соответствует `git_object`, так что вы можете относительно безопасно преобразовывать типы друг в друга. В нашем случае `git_object_type(head_commit)` вернёт `GIT_OBJ_COMMIT`, так что мы вправе привести тип к `git_commit`. -Следующий блока кода показывает как получить доступ к свойствам коммита. +Следующий блок кода показывает как получить доступ к свойствам коммита. Последняя строчка в этом фрагменте кода использует тип `git_oid` -- это внутреннее представление SHA-1 в Libgit2. Глядя на этот пример, можно сделать несколько выводов: @@ -189,7 +189,7 @@ int git_odb_backend_mine(git_odb_backend **backend_out, /*…*/) ===== LibGit2Sharp (((.NET)))(((C#)))(((Mono))) -Если вы пишете под платформы .NET / Mono, LibGit2Sharp (https://github.com/libgit2/libgit2sharp[^]) -- то, что вы искали. +Если вы пишете под платформы .NET / Mono, LibGit2Sharp (https://github.com/libgit2/libgit2sharp[^]) -- то, это то что вы искали. Эта библиотека написана на C# и все прямые вызовы методов Libgit2 тщательно обёрнуты в управляемый CLR код. Вот как будет выглядеть наш пример: diff --git a/book/introduction.asc b/book/introduction.asc index 71be0874..92d646bb 100644 --- a/book/introduction.asc +++ b/book/introduction.asc @@ -25,7 +25,7 @@ После этой главы вы будете мастерски справляться с множеством удалённых репозиториев, работать с Git через почту, ловко жонглировать несколькими удалёнными ветвями и новыми патчами. *Глава 6* посвящена хостингу GitHub и его инструментам. -Мы разберём регистрацию, управление учётной записью, создание и использование Git репозиториев, как вносить вклад в чужие проекты и как принимать чужой вклад в собственный проект, а также программный интерфейс GitHub и ещё множество мелочей, который облегчат вам жизнь. +Мы разберём регистрацию, управление учётной записью, создание и использование Git репозиториев, как вносить вклад в чужие проекты и как принимать чужой вклад в собственный проект, а также программный интерфейс GitHub и ещё множество мелочей, которые облегчат вам жизнь. *Глава 7* про дополнительные Git команды. Здесь раскроются темы освоения пугающей команды 'reset', использования бинарного поиска для нахождения багов, правки истории, инспекции кода и многие другие. diff --git a/ch06-github.asc b/ch06-github.asc index 07d2631f..995f88b8 100644 --- a/ch06-github.asc +++ b/ch06-github.asc @@ -7,7 +7,7 @@ GitHub -- это крупнейшее хранилище Git репозитор Так что, пока всё это не часть открытого Git проекта, наверняка вы захотите, или вам придётся взаимодействовать с GitHub при профессиональном использовании Git. Эта глава про эффективное использование GitHub. -Мы разберём регистрацию, управление учётной записью, создание и использование Git репозиториев, как вносить вклад в чужие проекты и как принимать чужой вклад в собственный проект, а так же программный интерфейс GitHub и ещё множество мелочей, который облегчат вам жизнь. +Мы разберём регистрацию, управление учётной записью, создание и использование Git репозиториев, как вносить вклад в чужие проекты и как принимать чужой вклад в собственный проект, а так же программный интерфейс GitHub и ещё множество мелочей, которые облегчат вам жизнь. Если вас не интересует использование GitHub для размещения собственных проектов или сотрудничества с другими проектами, размещёнными на нём, вы можете смело перейти к главе <>. From 428a15391797f686da373a84820d591aa1c26f08 Mon Sep 17 00:00:00 2001 From: Viktor Yegay Date: Sun, 4 Feb 2024 04:27:37 +0500 Subject: [PATCH 10/13] =?UTF-8?q?=D0=A4=D0=BE=D1=80=D0=BC=D0=B0=D1=82?= =?UTF-8?q?=D0=B8=D1=80=D0=BE=D0=B2=D0=B0=D1=82=D1=8C=20=D1=81=D0=BB=D0=BE?= =?UTF-8?q?=D0=B2=D0=B0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit снимков (snapshot) -> курсив спецификация ссылок -> курсив блоб -> курсив вашем -> курсив игнорированием -> курсив настоящий -> курсив отслеживаемые -> отслеживаемый курсив неотслеживаемые -> неотслеживаемый курсив Индекс -> курсив рабочая копия -> курсив рабочий каталог -> курсив где -> убрать толщину, курсив когда -> убрать толщину, курсив вторым -> курсив можно Первым -> курсив можно нашей -> убрать курсив их -> убрать курсив общей -> убрать курсив этом -> убрать курсив все -> тонким а также -> толстым ими -> убрать жирный шрифт похожие -> убрать жирный шрифт --- book/02-git-basics/sections/recording-changes.asc | 4 ++-- book/03-git-branching/sections/nutshell.asc | 4 ++-- book/03-git-branching/sections/rebasing.asc | 4 ++-- book/07-git-tools/sections/advanced-merging.asc | 2 +- book/07-git-tools/sections/debugging.asc | 2 +- book/07-git-tools/sections/reset.asc | 6 +++--- book/07-git-tools/sections/revision-selection.asc | 4 ++-- book/07-git-tools/sections/searching.asc | 2 +- book/07-git-tools/sections/stashing-cleaning.asc | 2 +- book/10-git-internals/sections/refspec.asc | 2 +- 10 files changed, 16 insertions(+), 16 deletions(-) diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index aed359d8..8323ee6c 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -1,9 +1,9 @@ === Запись изменений в репозиторий -Итак, у вас имеется настоящий Git-репозиторий и рабочая копия файлов для некоторого проекта. +Итак, у вас имеется _настоящий_ Git-репозиторий и _рабочая копия_ файлов для некоторого проекта. Вам нужно делать некоторые изменения и фиксировать «снимки» состояния (snapshots) этих изменений в вашем репозитории каждый раз, когда проект достигает состояния, которое вам хотелось бы сохранить. -Запомните, каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем (отслеживаемые) и нет (неотслеживаемые). +Запомните, каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем (_отслеживаемые_) и нет (_неотслеживаемые_). Отслеживаемые файлы -- это те файлы, которые были в последнем снимке состояния проекта; они могут быть неизменёнными, изменёнными или подготовленными к коммиту. Если кратко, то отслеживаемые файлы -- это те файлы, о которых знает Git. diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index b7e84c50..105c1d03 100644 --- a/book/03-git-branching/sections/nutshell.asc +++ b/book/03-git-branching/sections/nutshell.asc @@ -3,7 +3,7 @@ Для точного понимания механизма ветвлений, необходимо вернуться назад и изучить то, как Git хранит данные. -Как вы можете помнить из <>, Git не хранит данные в виде последовательности изменений, он использует набор снимков (snapshot). +Как вы можете помнить из <>, Git не хранит данные в виде последовательности изменений, он использует набор _снимков_ (_snapshot_). Когда вы делаете коммит, Git сохраняет его в виде объекта, который содержит указатель на снимок (snapshot) подготовленных данных. Этот объект так же содержит имя автора и email, сообщение и указатель на коммит или коммиты непосредственно предшествующие данному (его родителей): отсутствие родителя для первоначального коммита, один родитель для обычного коммита, и несколько родителей для результатов слияния двух и более веток. @@ -20,7 +20,7 @@ $ git commit -m 'Initial commit' Когда вы создаёте коммит командой `git commit`, Git вычисляет контрольные суммы каждого подкаталога (в нашем случае, только основной каталог проекта) и сохраняет его в репозитории как объект дерева каталогов. Затем Git создаёт объект коммита с метаданными и указателем на основное дерево проекта для возможности воссоздать этот снимок в случае необходимости.(((команды git, commit))) -Ваш репозиторий Git теперь хранит пять объектов: три блоб объекта (по одному на каждый файл), объект _дерева_ каталогов, содержащий список файлов и соответствующих им блобов, а так же объект _коммита_, содержащий метаданные и указатель на объект дерева каталогов. +Ваш репозиторий Git теперь хранит пять объектов: три _блоб_ объекта (по одному на каждый файл), объект _дерева_ каталогов, содержащий список файлов и соответствующих им блобов, а так же объект _коммита_, содержащий метаданные и указатель на объект дерева каталогов. .Коммит и его дерево image::images/commit-and-tree.png["Коммит и его дерево"] diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc index effc0b39..2ed283c0 100644 --- a/book/03-git-branching/sections/rebasing.asc +++ b/book/03-git-branching/sections/rebasing.asc @@ -143,7 +143,7 @@ image::images/interesting-rebase-5.png["Окончательная истори Если вы будете придерживаться этого правила, всё будет хорошо. Если не будете, люди возненавидят вас, а ваши друзья и семья будут вас презирать. -Когда вы что-то перемещаете, вы отменяете существующие коммиты и создаёте новые, *похожие* на старые, но являющиеся другими. +Когда вы что-то перемещаете, вы отменяете существующие коммиты и создаёте новые, похожие на старые, но являющиеся другими. Если вы куда-нибудь отправляете свои коммиты и другие люди забирают их себе и в дальнейшем основывают на них свою работу, а затем вы переделываете эти коммиты командой `git rebase` и выкладываете их снова, то ваши коллеги будут вынуждены заново выполнять слияние для своих наработок. В итоге, когда вы в очередной раз попытаетесь включить их работу в свою, вы получите путаницу. @@ -182,7 +182,7 @@ image::images/perils-of-rebasing-4.png["Вы снова выполняете с ==== Меняя базу, меняй основание Если вы попали в такую ситуацию, у Git есть особая магия чтобы вам помочь. -Если кто-то в вашей команде форсирует отправку изменений на сервер, переписывающих работу, на которых базировалась ваша работа, то ваша задача будет состоять в определении того, что именно было ваше, а что было переписано *ими*. +Если кто-то в вашей команде форсирует отправку изменений на сервер, переписывающих работу, на которых базировалась ваша работа, то ваша задача будет состоять в определении того, что именно было ваше, а что было переписано ими. Оказывается, что помимо контрольной суммы коммита SHA-1, Git также вычисляет контрольную сумму отдельно для патча, входящего в этот коммит. Это контрольная сумма называется «patch-id». diff --git a/book/07-git-tools/sections/advanced-merging.asc b/book/07-git-tools/sections/advanced-merging.asc index 3fc86081..84239d79 100644 --- a/book/07-git-tools/sections/advanced-merging.asc +++ b/book/07-git-tools/sections/advanced-merging.asc @@ -165,7 +165,7 @@ Merge made by the 'recursive' strategy. Как мы будем делать это? Во-первых, мы перейдём в состояние конфликта слияния. -Затем нам необходимо получить копии _нашей_ версии файла, _их_ версии файла (из ветки, которую мы сливаем) и _общей_ версии (от которой ответвились первые две). +Затем нам необходимо получить копии нашей версии файла, их версии файла (из ветки, которую мы сливаем) и общей версии (от которой ответвились первые две). Затем мы исправим либо их версию, либо нашу и повторим слияние только для этого файла. Получить эти три версии файла, на самом деле, довольно легко. diff --git a/book/07-git-tools/sections/debugging.asc b/book/07-git-tools/sections/debugging.asc index 545292d7..50657449 100644 --- a/book/07-git-tools/sections/debugging.asc +++ b/book/07-git-tools/sections/debugging.asc @@ -63,7 +63,7 @@ ad11ac80 GITPackUpload.m (Scott 2009-03-24 150) ---- Это, действительно, полезно. -Обычно вы получаете в качестве изначального коммит, в котором вы скопировали код, так как это первый коммит, в котором вы обращаетесь к этим строкам в _этом_ файле. +Обычно вы получаете в качестве изначального коммит, в котором вы скопировали код, так как это первый коммит, в котором вы обращаетесь к этим строкам в этом файле. Но в данном случае Git сообщает вам первый коммит, в котором эти строки были написаны, даже если это было сделано в другом файле. [[r_binary_search]] diff --git a/book/07-git-tools/sections/reset.asc b/book/07-git-tools/sections/reset.asc index 29325b82..febdc696 100644 --- a/book/07-git-tools/sections/reset.asc +++ b/book/07-git-tools/sections/reset.asc @@ -51,7 +51,7 @@ $ git ls-tree -r HEAD [[r_the_index]] ===== Индекс -Индекс -- это ваш *следующий намеченный коммит*. +_Индекс_ -- это ваш *следующий намеченный коммит*. Мы также упоминали это понятие как «область подготовленных изменений» Git -- то, что Git просматривает, когда вы выполняете `git commit`. Git заполняет индекс списком изначального содержимого всех файлов, выгруженных в последний раз в ваш рабочий каталог. @@ -71,7 +71,7 @@ $ git ls-files -s ===== Рабочий каталог -Наконец, у вас есть рабочий каталог. +Наконец, у вас есть _рабочий каталог_. Два других дерева сохраняют своё содержимое эффективным, но неудобным способом внутри каталога `.git`. Рабочий каталог распаковывает их в настоящие файлы, что упрощает для вас их редактирование. Считайте рабочий каталог *песочницей*, где вы можете опробовать изменения перед их коммитом в индекс (область подготовленных изменений) и затем в историю. @@ -195,7 +195,7 @@ image::images/reset-mixed.png["Mixed reset"] image::images/reset-hard.png["Hard reset"] Давайте разберёмся, что сейчас случилось. -Вы отменили ваш последний коммит, результаты выполнения команд `git add` и `git commit`, а также **все** изменения, которые вы сделали в рабочем каталоге. +Вы отменили ваш последний коммит, результаты выполнения команд `git add` и `git commit`, *а также* все изменения, которые вы сделали в рабочем каталоге. Важно отметить, что только указание этого флага (`--hard`) делает команду `reset` опасной, это один из немногих случаев, когда Git действительно удаляет данные. Все остальные вызовы `reset` легко отменить, но при указании опции `--hard` команда принудительно перезаписывает файлы в рабочем каталоге. diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc index a30c9be2..8d35f75d 100644 --- a/book/07-git-tools/sections/revision-selection.asc +++ b/book/07-git-tools/sections/revision-selection.asc @@ -171,7 +171,7 @@ Date: Thu Dec 11 15:08:43 2008 -0800 Merge commit 'phedders/rdocs' ---- -Важно отметить, что информация в журнале ссылок строго локальная -- это лог того, что вы делали в вашем репозитории. +Важно отметить, что информация в журнале ссылок строго локальная -- это лог того, что вы делали в _вашем_ репозитории. Ссылки не будут такими же в других копиях репозитория; а сразу после первоначального клонирования репозитория, у вас будет пустой журнал ссылок, так как никаких действий в вашем репозитории пока не производилось. Команда `git show HEAD@{2.months.ago}` будет работать только если вы клонировали проект по крайней мере два месяца назад -- если вы клонировали его пять минут назад, то не получите никаких результатов. @@ -247,7 +247,7 @@ $ git show "HEAD^" # OK Также вы можете указать число после `^` -- например, `d921970^2` означает «второй родитель коммита `d921970`». Такой синтаксис полезен только для коммитов слияния, которые имеют больше одного родителя. -Первым родителем является ветка, в которую вы выполняли слияние, а вторым -- коммит в ветке, которую вы сливали: +_Первым_ родителем является ветка, в которую вы выполняли слияние, а _вторым_ -- коммит в ветке, которую вы сливали: [source,console] ---- diff --git a/book/07-git-tools/sections/searching.asc b/book/07-git-tools/sections/searching.asc index 00108fd6..d75a28f2 100644 --- a/book/07-git-tools/sections/searching.asc +++ b/book/07-git-tools/sections/searching.asc @@ -93,7 +93,7 @@ v1.8.0:zlib.c ==== Поиск в журнале Git -Возможно, вы ищете не **где** присутствует некоторое выражение, а **когда** оно существовало или было добавлено. +Возможно, вы ищете не _где_ присутствует некоторое выражение, а _когда_ оно существовало или было добавлено. Команда `git log` обладает некоторыми мощными инструментами для поиска определённых коммитов по содержимому их сообщений или содержимому сделанных в них изменений. Например, если вы хотите найти, когда была добавлена константа `ZLIB_BUF_MAX`, то вы можете с помощью опции `-S` попросить Git показывать только те коммиты, в которых была добавлена или удалена эта строка. diff --git a/book/07-git-tools/sections/stashing-cleaning.asc b/book/07-git-tools/sections/stashing-cleaning.asc index 59594fb8..b92f8722 100644 --- a/book/07-git-tools/sections/stashing-cleaning.asc +++ b/book/07-git-tools/sections/stashing-cleaning.asc @@ -151,7 +151,7 @@ M index.html Другой распространённый вариант, который вы, возможно, захотите использовать -- это припрятать помимо отслеживаемых файлов также и неотслеживаемые. По умолчанию `git stash` будет сохранять только изменённые и проиндексированные _отслеживаемые_ файлы. Если вы укажете опцию `--include-untracked` или `-u`, Git также припрячет все неотслеживаемые файлы, которые вы создали. -Однако включение этой опции по-прежнему не будет прятать файлы с явным игнорированием; чтобы дополнительно припрятать игнорируемые файлы, используйте `--all` (или просто `-a`). +Однако включение этой опции по-прежнему не будет прятать файлы с явным _игнорированием_; чтобы дополнительно припрятать игнорируемые файлы, используйте `--all` (или просто `-a`). [source,console] ---- diff --git a/book/10-git-internals/sections/refspec.asc b/book/10-git-internals/sections/refspec.asc index 192b50c5..fedb0df8 100644 --- a/book/10-git-internals/sections/refspec.asc +++ b/book/10-git-internals/sections/refspec.asc @@ -9,7 +9,7 @@ $ git remote add origin https://github.com/schacon/simplegit-progit ---- -Эта команда добавляет секцию в файл `.git/config`, в которой заданы имя удалённого репозитория (`origin`), его URL и спецификация ссылок для извлечения данных: +Эта команда добавляет секцию в файл `.git/config`, в которой заданы имя удалённого репозитория (`origin`), его URL и _спецификация ссылок_ для извлечения данных: [source,ini] ---- From 0ce6871ef49e6b1a37743ee71f3e45dfa94eeb2b Mon Sep 17 00:00:00 2001 From: Viktor Yegay Date: Sun, 4 Feb 2024 07:30:16 +0500 Subject: [PATCH 11/13] =?UTF-8?q?=D0=9E=D1=82=D0=BE=D0=B1=D1=80=D0=B0?= =?UTF-8?q?=D0=B7=D0=B8=D1=82=D1=8C=20=D0=BC=D0=B5=D0=BD=D1=8E=20=D0=B8=20?= =?UTF-8?q?=D0=BA=D0=BD=D0=BE=D0=BF=D0=BA=D0=B8?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- attributes.asc | 1 + book/04-git-server/sections/gitlab.asc | 4 ++-- .../sections/contributing.asc | 2 +- .../sections/1-setting-up-account.asc | 6 ++--- book/06-github/sections/2-contributing.asc | 10 ++++----- book/06-github/sections/3-maintaining.asc | 22 +++++++++---------- .../sections/4-managing-organization.asc | 4 ++-- book/06-github/sections/5-scripting.asc | 6 ++--- .../sections/interactive-staging.asc | 2 +- .../sections/client-p4.asc | 4 ++-- .../sections/eclipse.asc | 4 ++-- .../sections/guis.asc | 16 +++++++------- .../sections/visualstudio.asc | 2 +- .../sections/zsh.asc | 2 +- 14 files changed, 43 insertions(+), 42 deletions(-) diff --git a/attributes.asc b/attributes.asc index 6f6b39c6..8f1bd6fc 100644 --- a/attributes.asc +++ b/attributes.asc @@ -6,3 +6,4 @@ ifdef::lang[include::attributes-{lang}.adoc[]] :icons: font :toc: :toclevels: 2 +:experimental: diff --git a/book/04-git-server/sections/gitlab.asc b/book/04-git-server/sections/gitlab.asc index f93702f1..2197a2e5 100644 --- a/book/04-git-server/sections/gitlab.asc +++ b/book/04-git-server/sections/gitlab.asc @@ -84,10 +84,10 @@ GitLab включает поддержку хуков (перехватчико ==== Базовое использование Первое, чего вы захотите от GitLab, это создать новый проект. -Это достигается нажатием иконки «+» на панели инструментов. +Это достигается нажатием иконки kbd:[+] на панели инструментов. Будут запрошены имя проекта, пространство имён, которому он должен принадлежать, и уровень видимости. Большинство из этих настроек можно потом изменить через интерфейс настроек. -Нажмите «Создать проект» («Create Project»), чтобы закончить. +Нажмите kbd:[Create Project] («Создать проект»), чтобы закончить. Когда проект создан, вы, наверное, захотите соединить его с локальным git-репозиторием. Каждый проект может быть доступен через HTTPS или SSH, каждый из которых может быть использован для указания удалённого репозитория. diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index 722b82f3..31dbf24a 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -527,7 +527,7 @@ $ git commit Возможно, вы захотите использовать `rebase -i`, чтобы объединить несколько коммитов в один или переставить их местами, чтобы сопровождающему было легче проверять патч -- смотрите раздел <> для получения детальной информации об интерактивном перебазировании. ==== -Когда работа в тематической ветке завершена и вы готовы передать изменения исходному проекту, перейдите на страницу исходного проекта и нажмите кнопку «Fork», тем самым создавая доступный для записи форк проекта. +Когда работа в тематической ветке завершена и вы готовы передать изменения исходному проекту, перейдите на страницу исходного проекта и нажмите кнопку kbd:[Fork], тем самым создавая доступный для записи форк проекта. Затем нужно добавить URL на созданный проект как второй удалённый репозиторий, в нашем случае с именем `myfork`: [source,console] diff --git a/book/06-github/sections/1-setting-up-account.asc b/book/06-github/sections/1-setting-up-account.asc index 64ebdcf5..8a31cf25 100644 --- a/book/06-github/sections/1-setting-up-account.asc +++ b/book/06-github/sections/1-setting-up-account.asc @@ -3,7 +3,7 @@ (((GitHub, учётные записи))) Первым делом нужно создать бесплатную учётную запись. -Просто зайдите на https://github.com[^], выберите имя которое ещё не занято, укажите адрес электронной почты и пароль, а затем нажмите большую зелёную кнопку «Sign up for GitHub». +Просто зайдите на https://github.com[^], выберите имя которое ещё не занято, укажите адрес электронной почты и пароль, а затем нажмите большую зелёную кнопку kbd:[Sign up for GitHub]. .Форма регистрации на GitHub image::images/signup.png["Форма регистрации на GitHub"] @@ -40,7 +40,7 @@ image::images/account-settings.png["Ссылка «Настройка учётн .Ссылка («SSH keys») image::images/ssh-keys.png["Ссылка «Ключи SSH» («SSH keys»)"] -Затем нажмите на кнопку «Добавить ключ SSH» («Add an SSH key»), задайте имя ключа, а так же скопируйте и вставьте сам публичный ключ из `~/.ssh/id_rsa.pub` (ну или как бы у вас не назывался этот файл) в текстовое поле, затем нажмите «Добавить ключ» («Add key»). +Затем нажмите на кнопку kbd:[Add an SSH key] («Добавить ключ SSH»), задайте имя ключа, а так же скопируйте и вставьте сам публичный ключ из `~/.ssh/id_rsa.pub` (ну или как бы у вас не назывался этот файл) в текстовое поле, затем нажмите kbd:[Add key] («Добавить ключ»). [NOTE] ==== @@ -92,6 +92,6 @@ image::images/email-settings.png["Добавьте все ваши почтов .Двухфакторная аутентификация («Two-factor Authentication») image::images/2fa-1.png["Двухфакторная аутентификация («Two-factor Authentication»)"] -При нажатии на кнопку «Настроить двухфакторную аутентификацию» («Set up two-factor authentication») вы будете перенаправлены на страницу, где вам нужно будет настроить использование мобильного приложения для генерации вторичного кода проверки (так называемый «одноразовый пароль основанный на времени»), так же можно настроить GitHub таким образом, чтобы он отправлял вам СМС с кодом в момент, когда вам нужно авторизоваться на сайте. +При нажатии на кнопку kbd:[Set up two-factor authentication] («Настроить двухфакторную аутентификацию») вы будете перенаправлены на страницу, где вам нужно будет настроить использование мобильного приложения для генерации вторичного кода проверки (так называемый «одноразовый пароль основанный на времени»), так же можно настроить GitHub таким образом, чтобы он отправлял вам СМС с кодом в момент, когда вам нужно авторизоваться на сайте. После того, как вы выберете предпочитаемый вами метод и выполните предлагаемые инструкции, ваша учётная запись будет в большей безопасности, и вам будет предоставляться дополнительный код во время авторизации на сайте. diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index af4e9e23..f5cf0ecb 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -18,7 +18,7 @@ Люди просто могут создавать свои собственные ветвления (fork), вносить туда изменения, а затем отправлять свои внесённые изменения в оригинальный репозиторий проекта путём создания запроса на принятие изменений (Pull Request), сами же запросы на принятие изменений (Pull Request) будут описаны далее. Запрос на принятие изменений (Pull Request) откроет новую ветвь с обсуждением отправляемого кода, и автор оригинального проекта, а так же другие его участники, могут принимать участие в обсуждении предлагаемых изменений до тех пор, пока автор проекта не будет ими доволен, после чего автор проекта может добавить предлагаемые изменения в проект. -Для того, чтобы создать ответвление проекта, зайдите на страницу проекта и нажмите кнопку «Создать ответвление» («Fork»), которая расположена в правом верхнем углу. +Для того, чтобы создать ответвление проекта, зайдите на страницу проекта и нажмите кнопку kbd:[Fork] («Создать ответвление»), которая расположена в правом верхнем углу. .Кнопка «Создать ответвление» («Fork») image::images/forkbutton.png["Кнопка «Создать ответвление» («Fork»)"] @@ -67,7 +67,7 @@ image::images/blink-01-start.png["Проект, над которым мы хо Единственная проблема в том, что светодиод моргает слишком быстро; нам кажется, лучше установить задержку в три секунды, не одну. Так давайте исправим это и предложим изменения автору. -Для начала, нажмите кнопку «Fork», как было сказано выше, чтобы заполучить собственную копию проекта. +Для начала, нажмите кнопку kbd:[Fork], как было сказано выше, чтобы заполучить собственную копию проекта. Мы зарегистрированы на GitHub под именем «tonychacon», так что наша копия окажется по адресу `https://github.com/tonychacon/blink`, где мы сможем редактировать её. Мы клонируем её, создадим тематическую ветку, внесём необходимые изменения и, наконец, отправим их на GitHub. @@ -137,7 +137,7 @@ image::images/blink-02-pr.png["Кнопка открытия запроса на .Страница создания запроса на слияние image::images/blink-03-pull-request-open.png["Создание запроса на слияние"] -После создания запроса на слияние (путём нажатия кнопки «Create pull request» на этой странице) владелец форкнутого проекта получит уведомление о предложенных изменениях со ссылкой на страницу с информацией о запросе. +После создания запроса на слияние (путём нажатия кнопки kbd:[Create pull request] на этой странице) владелец форкнутого проекта получит уведомление о предложенных изменениях со ссылкой на страницу с информацией о запросе. [NOTE] ==== @@ -222,7 +222,7 @@ GitHub так же проверяет может ли запрос на слия Например, если вы вернётесь и посмотрите на <>, то увидите, что участник не делал перебазирование своего коммита и не отправлял новый запрос на слияние. Вместо этого были сделаны новые коммиты и отправлены в существующую ветку. Таким образом, если вы в будущем вернётесь к этому запросу слияния, то легко найдёте весь контекст принятого решения. -По нажатию кнопки «Merge» целенаправленно создаётся коммит слияния, который указывает на запрос слияния, оставляя возможность возврата к цепочке обсуждения. +По нажатию кнопки kbd:[Merge] целенаправленно создаётся коммит слияния, который указывает на запрос слияния, оставляя возможность возврата к цепочке обсуждения. ===== Следование за исходным репозиторием @@ -417,7 +417,7 @@ image::images/markdown-04-fenced-code.png["Отображение обрамлё Если вы отвечаете только на часть большого комментария, то можно цитировать только выбранную часть, предваряя её символом `>`. Это настолько часто используется, что даже существует комбинация клавиш для этого. -Если в комментарии выделить текст, на который вы собираетесь ответить, и нажать клавишу `r`, то выделенный текст будет включён как цитата в ваш комментарий. +Если в комментарии выделить текст, на который вы собираетесь ответить, и нажать клавишу kbd:[r], то выделенный текст будет включён как цитата в ваш комментарий. Цитаты выглядят примерно так: diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index eb455781..1885968a 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -6,7 +6,7 @@ ==== Создание нового репозитория Давайте создадим новый репозиторий для распространения кода нашего проекта. -В панели управления справа нажмите кнопку «New repository» или воспользуйтесь кнопкой `+` на панели инструментов, рядом с вашим именем пользователя как показано на рисунке <>. +В панели управления справа нажмите кнопку kbd:[New repository] или воспользуйтесь кнопкой kbd:[+] на панели инструментов, рядом с вашим именем пользователя как показано на рисунке <>. .Раздел «Your repositories» image::images/newrepo.png["Раздел «Your repositories»"] @@ -21,7 +21,7 @@ image::images/new-repo.png["Выпадающее меню «New repository»"] image::images/newrepoform.png["Форма «New repository»"] Всё, что в действительности нужно сделать, так это указать название проекта, все остальные поля опциональны. -Сейчас, просто нажмите кнопку «Create Repository» и ваш новый репозиторий с названием `<пользователь>/<имя_проекта>` готов. +Сейчас, просто нажмите кнопку kbd:[Create Repository] и ваш новый репозиторий с названием `<пользователь>/<имя_проекта>` готов. Так как в репозитории ещё нет кода, GitHub отобразит инструкции о том, как создать совершенно новый репозиторий или подключить существующий Git проект. Здесь мы не будем этого делать; если вам нужно освежить память, смотрите главу <>. @@ -49,9 +49,9 @@ Git может получать и отправлять изменения по image::images/reposettingslink.png["Ссылка на настройки репозитория"] Затем выберите «Collaborators» в меню слева. -Напишите имя пользователя в поле для ввода и нажмите кнопку «Add collaborator». +Напишите имя пользователя в поле для ввода и нажмите кнопку kbd:[Add collaborator]. Так вы можете добавить неограниченное количество пользователей. -Чтобы отозвать доступ, просто нажмите «X» справа от имени пользователя. +Чтобы отозвать доступ, просто нажмите kbd:[X] справа от имени пользователя. .Участники проекта image::images/collaborators.png["Окно участников проекта"] @@ -104,9 +104,9 @@ image::images/maint-03-email-resp.png["Email ответ"] Когда вы готовы слить код, вы можете стянуть его себе и слить локально, слить используя команду `git pull `, которую мы видели ранее, или добавив ответвлённый репозиторий как удалённый получить и слить изменения. -Если слияние тривиально, то можно просто нажать кнопку «Merge» на сайте GitHub. +Если слияние тривиально, то можно просто нажать кнопку kbd:[Merge] на сайте GitHub. Это всегда приводит с созданию коммита слияния, даже если доступно слияние перемоткой вперёд. -Это значит, что в любом случае создаётся коммит слияния, как только вы нажимаете кнопку «Merge». +Это значит, что в любом случае создаётся коммит слияния, как только вы нажимаете кнопку kbd:[Merge]. Как можно увидеть на <>, GitHub отображает информацию об этом при вызове подсказки. [[r_merge_button]] @@ -214,7 +214,7 @@ Switched to a new branch 'pr/2' ---- Особо внимательные из вас заметили `head` в конце спецификации, относящейся к удалённому репозиторию. -Так же на стороне GitHub существует ссылка `refs/pull/#/merge`, которая представляет коммит, формируемый при нажатии кнопки «merge» на сайте. +Так же на стороне GitHub существует ссылка `refs/pull/#/merge`, которая представляет коммит, формируемый при нажатии кнопки kbd:[Merge] на сайте. Это позволяет вам протестировать слияние перед нажатием этой кнопки. @@ -226,7 +226,7 @@ Switched to a new branch 'pr/2' Если вы видите толковый запрос слияния и у вас есть идея как его улучшить или вы не уверены, что это хорошая идея, или у вас просто нет прав записи в целевую ветку, то в таком случае вы можете открыть запрос слияния, указывающий на данный запрос. При открытии запроса на слияние вверху страницы вы увидите меню для выбора целевой и исходной веток. -Если нажать кнопку `Edit` справа, то станет доступным выбор не только исходной ветки, а ещё и форка. +Если нажать кнопку kbd:[Edit] справа, то станет доступным выбор не только исходной ветки, а ещё и форка. [[r_pr_targets]] .Ручное изменение форка и ветки для запроса слияния @@ -251,7 +251,7 @@ image::images/maint-05-mentions.png["Упоминания"] Если кто-то будет упомянут в запросе слияния или проблеме, то он автоматически «подписывается» и будет получать уведомления о последующей активности. Вы так же будете подписаны на некоторые уведомления если просто откроете запрос слияния или проблему, станете отслеживать репозиторий или если оставите комментарий. -Для прекращения отправки вам уведомлений нажмите кнопку «Unsubscribe». +Для прекращения отправки вам уведомлений нажмите кнопку kbd:[Unsubscribe]. .Отказ от подписки на проблему или запрос слияния @@ -314,7 +314,7 @@ X-GitHub-Recipient-Address: tchacon@example.com Для задачи вместо «pull» будет указано «issues». Заголовки `List-Post` и `List-Unsubscribe`, при наличии у вас почтового клиента, который их понимает, позволяют легко написать в список рассылки или отписаться от неё. -Это то же самое, что и нажать кнопку «mute» в веб версии уведомлений или «Unsubscribe» на странице задачи или запроса на слияние. +Это то же самое, что и нажать кнопку kbd:[Mute] в веб версии уведомлений или «Unsubscribe» на странице задачи или запроса на слияние. Если включены оба типа уведомлений и ваш почтовый клиент отображает картинки, то при просмотре email версии уведомления, веб версия так же будет отмечена как прочитанная. @@ -367,7 +367,7 @@ image::images/maint-10-default-branch.png["Основная ветка прое ===== Передача проекта -Если вы хотите передать проект другому пользователю или организации на GitHub, то это можно сделать нажатием кнопки «Transfer ownership» в настройках репозитория на закладке «Options». +Если вы хотите передать проект другому пользователю или организации на GitHub, то это можно сделать нажатием кнопки kbd:[Transfer] в настройках репозитория на закладке «Options». [[r_transfer_project]] .Передача проекта другому пользователю или организации на GitHub diff --git a/book/06-github/sections/4-managing-organization.asc b/book/06-github/sections/4-managing-organization.asc index 318414be..f248d00f 100644 --- a/book/06-github/sections/4-managing-organization.asc +++ b/book/06-github/sections/4-managing-organization.asc @@ -9,7 +9,7 @@ ==== Основы организаций -Создать новую организацию очень легко; просто нажмите на иконку «+» в правом верхнем углу страницы GitHub и выберите пункт «New organization» из меню. +Создать новую организацию очень легко; просто нажмите на иконку kbd:[+] в правом верхнем углу страницы GitHub и выберите пункт «New organization» из меню. .Пункт меню «New organization» image::images/neworg.png["Пункт меню «New organization»"] @@ -46,7 +46,7 @@ image::images/orgs-01-page.png["Страница организации"] Для управления командами нужно перейти на закладку 'Teams' справа вверху на странице <>. Это приведёт вас на страницу где можно добавлять пользователей в команду, добавлять команде репозитории или управлять настройками и правами доступа. Каждая команда может иметь только следующие уровни доступа к репозиториям: «только чтение», «чтение/запись» или «администратор». -Уровень доступа может быть изменён нажатием кнопки «Settings» на странице <>. +Уровень доступа может быть изменён нажатием кнопки kbd:[Settings] на странице <>. [[r_team_page]] .Страница команды diff --git a/book/06-github/sections/5-scripting.asc b/book/06-github/sections/5-scripting.asc index 03ec9812..bce8610e 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»), указанный нами адрес электронной почты будет получать электронное письмо каждый раз, когда кто-то отправляет в репозиторий. +В этом случае, если мы нажмём кнопку kbd:[Add Service] («Добавить сервис»), указанный нами адрес электронной почты будет получать электронное письмо каждый раз, когда кто-то отправляет в репозиторий. Сервисы могут прослушивать множество различных типов событий, но большинство из них прослушивают только push-события, а затем что-то делают с этими данными. Если вы используете систему, которую хотите интегрировать с GitHub, вам следует проверить здесь, чтобы узнать, доступна ли существующая интеграция сервиса. @@ -42,7 +42,7 @@ image::images/scripting-02-email-service.png[Email service] Как правило, это работает так: вы можете настроить небольшой веб-сервис для прослушивания полезных данных хука GitHub, а затем что-то делать с данными, когда они будут получены. -Чтобы включить хук, вы нажимаете кнопку «Добавить вебхук» («Add webhook») в <>. +Чтобы включить хук, вы нажимаете кнопку kbd:[Add webhook] («Добавить вебхук») в <>. Это приведёт вас на страницу, которая выглядит как <>. [[r_web_hook]] @@ -50,7 +50,7 @@ image::images/scripting-02-email-service.png[Email service] image::images/scripting-03-webhook.png[Web hook] Конфигурация вебхука довольно проста. -В большинстве случаев вы просто вводите URL и секретный ключ и нажимаете «Добавить вебхук» («Add webhook»). +В большинстве случаев вы просто вводите URL и секретный ключ и нажимаете kbd:[Add webhook] («Добавить вебхук»). Есть несколько вариантов, для каких событий вы хотите, чтобы GitHub отправлял вам полезные данные -- по умолчанию вы получаете полезные данные только для события `push`, когда кто-то отправляет новый код в любую ветку вашего репозитория. Давайте рассмотрим небольшой пример веб-сервиса, который вы можете настроить для обработки вебхука. diff --git a/book/07-git-tools/sections/interactive-staging.asc b/book/07-git-tools/sections/interactive-staging.asc index f09eb13d..c8fdd947 100644 --- a/book/07-git-tools/sections/interactive-staging.asc +++ b/book/07-git-tools/sections/interactive-staging.asc @@ -55,7 +55,7 @@ Update>> ---- Символ `*` у каждого из этих файлов означает, что файл выбран для индексирования. -Если вы нажмёте Enter, не вводя ничего в поле ввода `Update>>`, Git добавит в индекс всё, чтобы было выбрано ранее: +Если вы нажмёте kbd:[Enter], не вводя ничего в поле ввода `Update>>`, Git добавит в индекс всё, чтобы было выбрано ранее: [source,console] ---- diff --git a/book/09-git-and-other-scms/sections/client-p4.asc b/book/09-git-and-other-scms/sections/client-p4.asc index ef21173c..7f0ca7cc 100644 --- a/book/09-git-and-other-scms/sections/client-p4.asc +++ b/book/09-git-and-other-scms/sections/client-p4.asc @@ -30,7 +30,7 @@ image::images/git-fusion-boot.png["Экран виртуальной машин Запомните IP адрес, он пригодится в будущем. Далее, создадим пользователя Perforce. -Выберите внизу опцию «Login» и нажмите `Enter` (или используйте SSH) и войдите как пользователь `root`. +Выберите внизу опцию «Login» и нажмите kbd:[Enter] (или используйте SSH) и войдите как пользователь `root`. Используйте приведённые ниже команды, чтобы создать пользователя: [source,console] @@ -40,7 +40,7 @@ $ p4 -p localhost:1666 -u john passwd $ exit ---- -Первая команда откроет редактор для уточнения данных пользователя, но вы можете принять настройки по умолчанию, введя `:wq` и нажав `Enter`. +Первая команда откроет редактор для уточнения данных пользователя, но вы можете принять настройки по умолчанию, введя `:wq` и нажав kbd:[Enter]. Вторая команда дважды попросит ввести пароль. Это всё, что требовалось выполнить в оболочке ОС, можете завершить сессию. diff --git a/book/A-git-in-other-environments/sections/eclipse.asc b/book/A-git-in-other-environments/sections/eclipse.asc index 51d56faf..5fd20928 100644 --- a/book/A-git-in-other-environments/sections/eclipse.asc +++ b/book/A-git-in-other-environments/sections/eclipse.asc @@ -2,9 +2,9 @@ (((Eclipse))) В составе IDE Eclipse есть плагин под названием Egit, который предоставляет довольно полнофункциональный интерфейс для операций с Git. -Воспользоваться им можно, включив Git-перспективу (`Window` > `Open Perspective` > `Other`…, и выбрать `Git`). +Воспользоваться им можно, включив Git-перспективу (menu:Window[Open Perspective > Other > …], и выбрать menu:Git[]). .EGit в Eclipse image::images/egit.png["EGit в Eclipse"] -EGit поставляется с неплохой документацией, доступной через меню `Help` > `Help Contents` в разделе `EGit Documentation`. +EGit поставляется с неплохой документацией, доступной через меню menu:Help[Help Contents] в разделе menu:EGit Documentation[]. diff --git a/book/A-git-in-other-environments/sections/guis.asc b/book/A-git-in-other-environments/sections/guis.asc index 2ac563e0..5d33f659 100644 --- a/book/A-git-in-other-environments/sections/guis.asc +++ b/book/A-git-in-other-environments/sections/guis.asc @@ -59,9 +59,9 @@ image::images/git-gui.png["`git gui` -- инструмент редактиро Можно добавлять отдельные кусочки или строки в индекс из контекстного меню в этой области. Справа снизу находится область для ввода сообщения коммита и несколько кнопок. -Введите сообщение и нажмите кнопку «Commit» чтобы выполнить коммит. -Также можно изменить предыдущий коммит, выбрав радиокнопку «Amend», что приведёт к обновлению индекса содержимым предыдущего коммита. -После этого вы можете как обычно добавлять или удалять файлы из индекса, изменить сообщение коммита и, нажав кнопку «Commit» создать новый коммит, заменив им предыдущий. +Введите сообщение и нажмите кнопку kbd:[Commit] чтобы выполнить коммит. +Также можно изменить предыдущий коммит, выбрав радиокнопку kbd:[Amend], что приведёт к обновлению индекса содержимым предыдущего коммита. +После этого вы можете как обычно добавлять или удалять файлы из индекса, изменить сообщение коммита и, нажав кнопку kbd:[Commit] создать новый коммит, заменив им предыдущий. `gitk` и `git-gui` -- это примеры инструментов, ориентированных на задачи. Каждый из них наиболее подходит для решения определённой задачи (просмотр истории или создание коммитов соответственно) и не поддерживает дополнительные функции Git, ненужные для её решения. @@ -82,11 +82,11 @@ image::images/github_win.png["GitHub для Windows"] Они спроектированы по одному шаблону, поэтому мы будет рассматривать их как один продукт в этой главе. Мы не будем разбирать по косточкам эти инструменты (в конце-концов у них есть документация), а лишь быстренько взглянем на экран изменений (место, где вы будете зависать больше всего). -* Слева расположен список отслеживаемых репозиториев; можно добавить репозиторий (клонировав его, либо указав путь к существующей копии) нажатием кнопки `+` над списком. +* Слева расположен список отслеживаемых репозиториев; можно добавить репозиторий (клонировав его, либо указав путь к существующей копии) нажатием кнопки kbd:[+] над списком. * В центре экрана расположена область редактирования коммита: тут можно ввести сообщение коммита и выбрать файлы для включение в него. (На Windows, история коммитов расположена под этой областью, на Mac это отдельная вкладка.) * Справа -- просмотр изменений: что изменилось в рабочем каталоге, какие изменения войдут в коммит. -* И стоит обратить внимание на кнопку «Sync» справа вверху, которая используется для синхронизации по сети. +* И стоит обратить внимание на кнопку kbd:[Sync] справа вверху, которая используется для синхронизации по сети. [NOTE] ==== @@ -126,11 +126,11 @@ image::images/branch_widget_win.png["Создание ветки в Windows"] После создания ветки добавление коммитов в неё довольно тривиально. Измените что-нибудь в рабочем каталоге и, переключившись в окно клиента GitHub, вы увидите свои изменения. -Введите сообщение коммита, выберете файлы для включения в коммит и нажмите кнопку «Commit» (ctrl-enter или ⌘-enter). +Введите сообщение коммита, выберете файлы для включения в коммит и нажмите кнопку kbd:[Commit] (kbd:[Ctrl]+kbd:[Enter] или kbd:[⌘]+kbd:[Enter]). -Взаимодействие с удалёнными репозиториями происходит в первую очередь посредством кнопки «Sync». +Взаимодействие с удалёнными репозиториями происходит в первую очередь посредством кнопки kbd:[Sync]. В Git есть отдельные команды для отправки изменений на сервер, слияния изменений воедино и перемещения веток друг относительно друга, но клиент GitHub совмещает все эти команды в одну. -Вот что происходит когда вы жмёте «Sync»: +Вот что происходит когда вы жмёте kbd:[Sync]: . `git pull --rebase`. Если эта команда выполнится с ошибкой, будет выполнено `git pull --no-rebase`. diff --git a/book/A-git-in-other-environments/sections/visualstudio.asc b/book/A-git-in-other-environments/sections/visualstudio.asc index 7e4d809a..d6bddb4a 100644 --- a/book/A-git-in-other-environments/sections/visualstudio.asc +++ b/book/A-git-in-other-environments/sections/visualstudio.asc @@ -12,7 +12,7 @@ Visual Studio уже в течение достаточно долгого вр image::images/vs-1.png["Подключение к Git-репозиторию из окна Team Explorer (Командный обозреватель)"] Visual Studio запоминает все проекты, управляемые с помощью Git, которые Вы открыли, и они доступны в списке в нижней части окна. -Если в списке нет проекта, который вам нужен, нажмите кнопку «Add» («Добавить») и укажите путь к рабочему каталогу. +Если в списке нет проекта, который вам нужен, нажмите кнопку kbd:[Add] («Добавить») и укажите путь к рабочему каталогу. Двойной клик по одному из локальных Git-репозиториев откроет главную страницу репозитория, которая выглядит примерно так <>. Это центр управления Git; когда вы _пишете_ код, вы, вероятно, проводите большую часть своего времени на странице «Changes» («Изменения»), но когда приходит время получать изменения, сделанные вашими коллегами по работе, вам необходимо использовать страницы «Unsynced Commits» («Несинхронизированные коммиты») и «Branches» («Ветки»). diff --git a/book/A-git-in-other-environments/sections/zsh.asc b/book/A-git-in-other-environments/sections/zsh.asc index 68fc760f..6827547e 100644 --- a/book/A-git-in-other-environments/sections/zsh.asc +++ b/book/A-git-in-other-environments/sections/zsh.asc @@ -16,7 +16,7 @@ cherry -- find commits not merged upstream cherry-pick -- apply changes introduced by some existing commits ---- -Возможные варианты автодополнения не просто перечислены; они снабжены полезными описаниями и вы можете выбрать нужный вариант из предложенных, перемещаясь по ним нажатием клавиши `Tab`. +Возможные варианты автодополнения не просто перечислены; они снабжены полезными описаниями и вы можете выбрать нужный вариант из предложенных, перемещаясь по ним нажатием клавиши kbd:[Tab]. Это работает не только для команд Git, но и для их аргументов, названий объектов внутри репозитория (например, ссылки и удалённые репозитории), а также для имён файлов и прочего. В состав Zsh входит фреймворк `vcs_info`, предназначенный для извлечения информации из систем контроля версий. From b381c4c1d21ad17a20bab4df5c31051741446c3b Mon Sep 17 00:00:00 2001 From: Viktor Yegay Date: Tue, 6 Feb 2024 17:20:15 +0500 Subject: [PATCH 12/13] =?UTF-8?q?=D0=9F=D1=80=D0=B8=D0=B2=D0=B5=D1=81?= =?UTF-8?q?=D1=82=D0=B8=20=D0=BA=20=D0=B5=D0=B4=D0=B8=D0=BD=D0=BE=D0=BE?= =?UTF-8?q?=D0=B1=D1=80=D0=B0=D0=B7=D0=B8=D1=8E=20"=D0=B7=D0=B0=D0=BF?= =?UTF-8?q?=D1=80=D0=BE=D1=81=20=D0=BD=D0=B0=20=D1=81=D0=BB=D0=B8=D1=8F?= =?UTF-8?q?=D0=BD=D0=B8=D0=B5"?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- TRANSLATION_NOTES.asc | 2 + .../sections/contributing.asc | 4 +- book/06-github/sections/2-contributing.asc | 62 +++++++++---------- book/06-github/sections/3-maintaining.asc | 60 +++++++++--------- .../sections/jetbrainsides.asc | 2 +- .../sections/visualstudiocode.asc | 2 +- 6 files changed, 67 insertions(+), 65 deletions(-) diff --git a/TRANSLATION_NOTES.asc b/TRANSLATION_NOTES.asc index 7e857cdc..2a97aa94 100644 --- a/TRANSLATION_NOTES.asc +++ b/TRANSLATION_NOTES.asc @@ -62,6 +62,8 @@ stashed -- припрятано, припрятали === Working Directory → рабочий каталог Каталог файловой системы, содержащий рабочую копию. +=== Pull Request → запрос на слияние + === Кавычки В тексте книги следует использовать кавычки «ёлочки» во всех случаях, за исключением ситуации, когда слово или фраза в кавычках входит в состав другой фразы заключённой в кавычки. Например: «Фраза с „выделенным“ словом­­». diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index 31dbf24a..11468ec5 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -549,10 +549,10 @@ $ git push -u myfork featureA (((команды git, request-pull))) Когда ваши изменения отправлены в ваш форк, следует уведомить сопровождающих исходного проекта о том, что у вас есть изменения для интеграции. -Обычно, это называется _запросом слияния_, который вы можете создать используя как веб сайт -- GitHub использует собственный механизм запросов слияния, который будет рассмотрен в главе <> -- так и команду `git request-pull`, отправив её вывод по почте. +Обычно, это называется _запросом на слияние_, который вы можете создать используя как веб сайт -- GitHub использует собственный механизм запросов на слияние, который будет рассмотрен в главе <> -- так и команду `git request-pull`, отправив её вывод по почте. Команда `git request-pull` принимает в качестве аргументов название базовой ветки, в которую следует влить изменения из вашей тематической ветки, и ссылку на Git репозиторий, из которого следует получать изменения, а результатом будет список всех изменений, которые вы предлагаете внести. -Например, если Джессика хочет отправить Джону запрос слияния и она отправила два коммита в тематическую ветку, то ей следует выполнить команду: +Например, если Джессика хочет отправить Джону запрос на слияние и она отправила два коммита в тематическую ветку, то ей следует выполнить команду: [source,console] ---- diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index f5cf0ecb..f02761c4 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -15,8 +15,8 @@ ==== Таким образом, проекты не обеспокоены тем, чтобы пользователи, которые хотели бы выступать в роли соавторов, имели право на внесение изменений путём их отправки (push). -Люди просто могут создавать свои собственные ветвления (fork), вносить туда изменения, а затем отправлять свои внесённые изменения в оригинальный репозиторий проекта путём создания запроса на принятие изменений (Pull Request), сами же запросы на принятие изменений (Pull Request) будут описаны далее. -Запрос на принятие изменений (Pull Request) откроет новую ветвь с обсуждением отправляемого кода, и автор оригинального проекта, а так же другие его участники, могут принимать участие в обсуждении предлагаемых изменений до тех пор, пока автор проекта не будет ими доволен, после чего автор проекта может добавить предлагаемые изменения в проект. +Люди просто могут создавать свои собственные ветвления (fork), вносить туда изменения, а затем отправлять свои внесённые изменения в оригинальный репозиторий проекта путём создания запроса на слияние (Pull Request), сами же запросы на слияние будут описаны далее. +Запрос на слияние откроет новую ветвь с обсуждением отправляемого кода, и автор оригинального проекта, а так же другие его участники, могут принимать участие в обсуждении предлагаемых изменений до тех пор, пока автор проекта не будет ими доволен, после чего автор проекта может добавить предлагаемые изменения в проект. Для того, чтобы создать ответвление проекта, зайдите на страницу проекта и нажмите кнопку kbd:[Fork] («Создать ответвление»), которая расположена в правом верхнем углу. @@ -123,7 +123,7 @@ To https://github.com/tonychacon/blink Теперь, если мы зайдём на страничку нашей копии на GitHub, мы увидим, что GitHub заметил наши изменения и предлагает открыть запрос на слияние с помощью большой зелёной кнопки. -Также можно зайти на страницу «Branches», по адресу `\https://github.com///branches`, найти интересующую ветку и открыть запрос оттуда. +Также можно зайти на страницу «Branches», по адресу `\https://github.com///branches`, найти интересующую ветку и открыть запрос на слияние оттуда. .Кнопка открытия запроса на слияние image::images/blink-02-pr.png["Кнопка открытия запроса на слияние"] @@ -137,13 +137,13 @@ image::images/blink-02-pr.png["Кнопка открытия запроса на .Страница создания запроса на слияние image::images/blink-03-pull-request-open.png["Создание запроса на слияние"] -После создания запроса на слияние (путём нажатия кнопки kbd:[Create pull request] на этой странице) владелец форкнутого проекта получит уведомление о предложенных изменениях со ссылкой на страницу с информацией о запросе. +После создания запроса на слияние (путём нажатия кнопки kbd:[Create pull request] на этой странице) владелец форкнутого проекта получит уведомление о предложенных изменениях со ссылкой на страницу с информацией о запросе на слияние. [NOTE] ==== Запросы на слияние широко используются для публичных проектов типа описанного выше, когда участник уже подготовил все изменения для слияния с основным репозиторием. Тем не менее, часто можно встретить использование запросов на слияние во внутренних проектах _в самом начале_ цикла разработки. -Объяснение простое: вы можете обновлять тематическую ветку *после* открытия запроса на слияние, поэтому сам запрос открывается как можно раньше чтобы отслеживать прогресс разработки. +Объяснение простое: вы можете обновлять тематическую ветку *после* открытия запроса на слияние, поэтому сам запрос на слияние открывается как можно раньше чтобы отслеживать прогресс разработки. ==== ===== Обработка запроса на слияние @@ -177,7 +177,7 @@ image::images/blink-05-general-comment.png["Страница обсуждени Используя почту, вам потребуется заново отправить свои изменения в список рассылки, а при использовании GitHub вы просто делаете коммит в тематическую ветку и повторяете push, что автоматически обновляет запрос на слияние. На рисунке <> также видно, что в обновлённом запросе на слияние старый комментарий к коду был свёрнут, так как он относится к строке, которая с тех пор изменилась. -Когда участник сделает это, владелец проекта снова получит уведомление, а на странице запроса будет отмечено, что проблема решена. +Когда участник сделает это, владелец проекта снова получит уведомление, а на странице запроса на слияние будет отмечено, что проблема решена. Фактически, как только строка кода имеющая комментарий будет изменена, GitHub заметит это и удалит устаревшее отличие. [[r_pr_final]] @@ -210,9 +210,9 @@ GitHub так же проверяет может ли запрос на слия На текущий момент мы рассмотрели основы участия в проекте на GitHub, давайте рассмотрим некоторые интересные секреты и уловки касательно запросов слияния, чтобы вы могли более эффективно их использовать. -===== Запросы слияния как Патчи +===== Запросы на слияние как патчи -Важно понимать, что многие проекты не воспринимают запросы слияния как очередь идеальных патчей, которые должны применяться аккуратно и по порядку, как и большинство проектов, участие в которых основывается на отправке набора патчей через списки почтовых рассылок. +Важно понимать, что многие проекты не воспринимают запросы на слияние как очередь идеальных патчей, которые должны применяться аккуратно и по порядку, как и большинство проектов, участие в которых основывается на отправке набора патчей через списки почтовых рассылок. Большинство проектов на GitHub понимают ветки запросов на слияние как беседу относительно предлагаемого изменения, завершающуюся слиянием унифицированных изменений. Это важное различие, так как изменение предлагается до того, как код станет считаться идеальным, что гораздо реже происходит с распространяемыми наборами патчей через списки рассылок. @@ -221,8 +221,8 @@ GitHub так же проверяет может ли запрос на слия Например, если вы вернётесь и посмотрите на <>, то увидите, что участник не делал перебазирование своего коммита и не отправлял новый запрос на слияние. Вместо этого были сделаны новые коммиты и отправлены в существующую ветку. -Таким образом, если вы в будущем вернётесь к этому запросу слияния, то легко найдёте весь контекст принятого решения. -По нажатию кнопки kbd:[Merge] целенаправленно создаётся коммит слияния, который указывает на запрос слияния, оставляя возможность возврата к цепочке обсуждения. +Таким образом, если вы в будущем вернётесь к этому запросу на слияние, то легко найдёте весь контекст принятого решения. +По нажатию кнопки kbd:[Merge] целенаправленно создаётся коммит слияния, который указывает на запрос на слияние, оставляя возможность возврата к цепочке обсуждения. ===== Следование за исходным репозиторием @@ -230,7 +230,7 @@ GitHub так же проверяет может ли запрос на слия GitHub проверит это за вас и под каждым из запросов на слияние отобразит уведомление, можно ли его слить без конфликтов или нет. [[r_pr_fail]] -.Запрос имеет конфликты слияния +.Запрос на слияние имеет конфликты слияния image::images/pr-01-fail.png["PR merge failure"] Если вы видите что-то вроде <>, то вам следует изменить свою ветку так, чтобы исключить конфликты и сопровождающий не делал лишнюю работу. @@ -300,39 +300,39 @@ image::images/pr-02-merge-fix.png["PR fixed"] ===== Ссылки -Возможно, ваш следующий вопрос будет: «Как мне сослаться на предыдущий запрос слияния?» +Возможно, ваш следующий вопрос будет: «Как мне сослаться на предыдущий запрос на слияние?» Оказывается, существует много способов ссылаться на другие вещи практически везде, где у вас есть права записи на GitHub. -Давайте начнём с перекрёстных ссылок для запросов слияния или проблем. -Всем запросам слияния и проблемам присваиваются уникальные номера в пределах проекта. +Давайте начнём с перекрёстных ссылок для запросов на слияние или проблем. +Всем запросам на слияние и проблемам присваиваются уникальные номера в пределах проекта. Например, у вас не может быть запроса на слияние с номером #3 и проблемы с номером #3. -Если вы хотите сослаться на любой запрос слияния или проблему из другого места, просто добавьте `+#+` в комментарий или описание. -Так же можно указывать более конкретно, если проблема или запрос слияния находятся где-то ещё; пишите `+username#+` если ссылаетесь на проблему или запрос слияния, находящиеся в ответвлённом репозитории, или `+username/repo#+` если ссылаетесь на другой репозиторий. +Если вы хотите сослаться на любой запрос на слияние или проблему из другого места, просто добавьте `+#+` в комментарий или описание. +Так же можно указывать более конкретно, если проблема или запрос на слияние находятся где-то ещё; пишите `+username#+` если ссылаетесь на проблему или запрос на слияние, находящиеся в ответвлённом репозитории, или `+username/repo#+` если ссылаетесь на другой репозиторий. Рассмотрим это на примере. -Предположим, что мы перебазировали ветку в предыдущем примере, создали новый запрос слияния для неё и сейчас хотим сослаться на предыдущий запрос слияния из нового. +Предположим, что мы перебазировали ветку в предыдущем примере, создали новый запрос на слияние для неё и сейчас хотим сослаться на предыдущий запрос на слияние из нового. Так же мы хотим сослаться на проблему, находящуюся в ответвлённом репозитории, и на проблему из совершенно другого проекта. Мы можем составить описание как указано на <>. [[r_pr_references]] -.Перекрёстные ссылки в запросе слияния -image::images/mentions-01-syntax.png["Перекрёстные ссылки в запросе слияния"] +.Перекрёстные ссылки в запросе на слияние +image::images/mentions-01-syntax.png["Перекрёстные ссылки в запросе на слияние"] Когда мы отправим запрос на слияние, то увидим что-то вроде <>. [[r_pr_references_render]] -.Отображение перекрёстных ссылок в запросе слияния -image::images/mentions-02-render.png["Отображение перекрёстных ссылок в запросе слияния"] +.Отображение перекрёстных ссылок в запросе на слияние +image::images/mentions-02-render.png["Отображение перекрёстных ссылок в запросе на слияние"] Заметьте, что указанная полная ссылка на GitHub была сокращена до необходимого минимума. -Если Тони сейчас вернётся назад и закроет оригинальный запрос слияния, то мы это увидим, так как он упомянут в новом, а GitHub автоматически создаст отслеживающее событие в хронике запроса слияния. -Это значит, что все, кто просматривает закрытый запрос слияния, могут легко перейти к запросу слияния, который его заменил. +Если Тони сейчас вернётся назад и закроет оригинальный запрос на слияние, то мы это увидим, так как он упомянут в новом, а GitHub автоматически создаст отслеживающее событие в хронике запроса на слияние. +Это значит, что все, кто просматривает закрытый запрос на слияние, могут легко перейти к запросу на слияние, который его заменил. Ссылка будет выглядеть как указано на <>. [[r_pr_closed]] -.Отображение перекрёстных ссылок в закрытом запросе слияния -image::images/mentions-03-closed.png["Отображение перекрёстных ссылок в закрытом запросе слияния"] +.Отображение перекрёстных ссылок в закрытом запросе на слияние +image::images/mentions-03-closed.png["Отображение перекрёстных ссылок в закрытом запросе на слияние"] Кроме идентификационных номеров, можно ссылаться на конкретный коммит используя SHA-1. Следует указывать полный 40 символьный хеш SHA-1, но если GitHub увидит его в комментарии, то автоматически подставит ссылку на коммит. @@ -341,7 +341,7 @@ image::images/mentions-03-closed.png["Отображение перекрёст ==== GitHub-версия разметки Markdown Ссылки на другие проблемы -- это лишь часть интереснейших вещей, которые вы можете делать в текстовых полях на GitHub. -Для «проблемы» или «запроса слияния» в полях описания, комментария, комментария кода и других вы можете использовать так называемую «GitHub-версию разметки Markdown». +Для «проблемы» или «запроса на слияние» в полях описания, комментария, комментария кода и других вы можете использовать так называемую «GitHub-версию разметки Markdown». Разметка похожа на обычный текст, который основательно преобразуется. Смотрите <> для примера как использовать разметку при написании комментариев и текста. @@ -351,11 +351,11 @@ image::images/mentions-03-closed.png["Отображение перекрёст image::images/markdown-01-example.png["Пример разметки"] GitHub расширил возможности обычной разметки. -Эти возможности могут быть очень полезными при создании запросов слияния или комментариев и описаний к проблемам. +Эти возможности могут быть очень полезными при создании запросов на слияние или комментариев и описаний к проблемам. ===== Списки задач -Список задач -- это первая действительно важная возможность специфической разметки GitHub, особенно для запросов слияния. +Список задач -- это первая действительно важная возможность специфической разметки GitHub, особенно для запросов на слияние. Список задач представляет собой список флажков для задач, которые вы хотите выполнить. Размещение его в описании проблемы или запроса на слияние обычно указывает на то, что должно быть сделано до того, как проблема будет считаться решённой. @@ -374,16 +374,16 @@ GitHub расширил возможности обычной разметки. .Отображение списка задач в комментарии image::images/markdown-02-tasks.png["Пример списка задач"] -Он часто используется в запросах на слияние для отображения списка того, что вы хотите сделать до того, как запрос будет готов к слиянию. +Он часто используется в запросах на слияние для отображения списка того, что вы хотите сделать до того, как запрос на слияние будет готов к слиянию. Вы можете просто кликнуть по флажку, чтобы обновить комментарий -- не нужно редактировать комментарий вручную, чтобы пометить задачу как выполненную. Так же GitHub ищет списки задач в запросах на слияние и проблемах и отображает их как метаданные на страницах, где они упоминаются. -Например, если в вашем запросе на слияние есть задачи и вы просматриваете список всех запросов, то можно увидеть на сколько готов каждый из них. +Например, если в вашем запросе на слияние есть задачи и вы просматриваете список всех запросов на слияние, то можно увидеть на сколько готов каждый из них. Это позволяет разбивать запрос на слияние на несколько подзадач и помогает другим людям отслеживать прогресс ветки. Пример приведён на <>. [[r_task_list_progress]] -.Статистика задач в списке запросов слияния +.Статистика задач в списке запросов на слияние image::images/markdown-03-task-summary.png["Пример списка задач"] Такая возможность невероятно полезна когда вы открываете запрос на слияние на раннем этапе реализации и отслеживаете прогресс с помощью него. diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index 1885968a..6164ba8c 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -72,32 +72,32 @@ image::images/collaborators.png["Окно участников проекта"] Вы должны получить письмо с уведомлением о новом запросе слияния, которое выглядит как на <>. [[r_email_pr]] -.Email уведомление о новом запросе слияния -image::images/maint-01-email.png["Email уведомление о запросе слияния"] +.Email уведомление о новом запросе на слияние +image::images/maint-01-email.png["Email уведомление о запросе на слияние"] Следует сказать о некоторых особенностях этого уведомления. -В нём содержится краткая статистика отличий -- количество изменений и список файлов, которые были изменены в этом запросе слияния, ссылка на страницу запроса слияния на GitHub, а так же несколько ссылок, которые вы можете использовать в командной строке. +В нём содержится краткая статистика отличий -- количество изменений и список файлов, которые были изменены в этом запросе на слияние, ссылка на страницу запроса на слияние на GitHub, а так же несколько ссылок, которые вы можете использовать в командной строке. Если вы видите строку с текстом `git pull patch-1`, то это самый простой способ слить удалённую ветку без добавления удалённого репозитория. Это кратко описывалось в <>. -Если хотите, то можно сначала переключиться в тематическую ветку и только потом выполнить эту команду для изменений запроса слияния. +Если хотите, то можно сначала переключиться в тематическую ветку и только потом выполнить эту команду для изменений запроса на слияние. Другие ссылки, которые представляют интерес, это `.diff` и `.patch` ссылки. -Как вы догадались, они указывают на версии унифицированной разницы и патча запроса слияния. -Технически, вы можете слить изменения из запроса слияния командой: +Как вы догадались, они указывают на версии унифицированной разницы и патча запроса на слияние. +Технически, вы можете слить изменения из запроса на слияние командой: [source,console] ---- $ curl https://github.com/tonychacon/fade/pull/1.patch | git am ---- -===== Взаимодействие по запросу слияния +===== Взаимодействие по запросу на слияние Как описано в разделе <> главы 6, вы можете общаться с тем, кто открыл запрос на слияние. -Вы можете добавлять комментарии к отдельным строкам кода, коммитам или ко всему запросу целиком, используя усовершенствованную разметку GitHub где угодно. +Вы можете добавлять комментарии к отдельным строкам кода, коммитам или ко всему запросу на слияние целиком, используя усовершенствованную разметку GitHub где угодно. -Каждый раз, когда кто-то другой оставляет комментарий к запросу слияния, вы будете получать email уведомления по каждому событию. -Каждое уведомление будет содержать ссылку на страницу запроса слияния где была зафиксирована активность и, чтобы оставить комментарий в основной ветке запроса на слияние, вы можете просто ответить на это письмо. +Каждый раз, когда кто-то другой оставляет комментарий к запросу на слияние, вы будете получать email уведомления по каждому событию. +Каждое уведомление будет содержать ссылку на страницу запроса на слияние где была зафиксирована активность и, чтобы оставить комментарий в основной ветке запроса на слияние, вы можете просто ответить на это письмо. .Ответы на письма включены в диалог image::images/maint-03-email-resp.png["Email ответ"] @@ -110,18 +110,18 @@ image::images/maint-03-email-resp.png["Email ответ"] Как можно увидеть на <>, GitHub отображает информацию об этом при вызове подсказки. [[r_merge_button]] -.Кнопка Merge и инструкции по ручному слиянию запроса +.Кнопка Merge и инструкции по ручному слиянию запроса на слияние image::images/maint-02-merge.png["Кнопка Merge"] Если вы решаете не сливать запрос, то вы можете просто закрыть запрос на слияние, а открывший его участник будет уведомлён. [[r_pr_refs]] -===== Ссылки на запрос слияния +===== Ссылки на запрос на слияние -Если у вас *много* запросов слияния и вы не хотите добавлять пачку удалённых репозиториев или постоянно делать однократный «pull», то у GitHub есть хитрый трюк, позволяющий это делать. +Если у вас *много* запросов на слияние и вы не хотите добавлять пачку удалённых репозиториев или постоянно делать однократный «pull», то у GitHub есть хитрый трюк, позволяющий это делать. Этот трюк очень сложный, но полезный и мы рассмотрим его немного позже в <>. -Фактически, GitHub представляет ветки запросов слияния как псевдоветки на сервере. +Фактически, GitHub представляет ветки запросов на слияние как псевдоветки на сервере. По умолчанию, они не копируются при клонировании, а существуют в замаскированном виде и вы можете легко получить доступ к ним. В качестве примера мы используем низкоуровневую команду `ls-remote` (часто упоминается как «plumbing» команда, более подробно о ней будет рассказано в <>). @@ -144,12 +144,12 @@ a5a7751a33b7e86c5e9bb07b26001bb17d775d1a refs/pull/4/head Аналогично, если вы, находясь в своём репозитории, выполните команду `git ls-remote origin` или укажете любой другой удалённый репозиторий, то результат будет схожим. -Если репозиторий находится на GitHub и существуют открытые запросы слияния, то эти ссылки будут отображены с префиксами `refs/pull/`. +Если репозиторий находится на GitHub и существуют открытые запросы на слияние, то эти ссылки будут отображены с префиксами `refs/pull/`. По сути это ветки, но так как они находятся не в `refs/heads/`, то они не копируются при клонировании или получении изменений с сервера -- процесс получения изменений игнорирует их по умолчанию. -Для каждого запроса слияния существует две ссылки, одна из которых записана в `/head` и указывает на последний коммит в ветке запроса на слияние. +Для каждого запроса на слияние существует две ссылки, одна из которых записана в `/head` и указывает на последний коммит в ветке запроса на слияние. Таким образом, если кто-то открывает запрос на слияние в наш репозиторий из своей ветки `bug-fix`, которая указывает на коммит `a5a775`, то в *нашем* репозитории не будет ветки `bug-fix` (так как она находится в форке), при этом у нас _появится_ `pull//head`, которая указывает на `a5a775`. -Это означает, что мы можем стянуть все ветки запросов слияния одной командой не добавляя набор удалённых репозиториев. +Это означает, что мы можем стянуть все ветки запросов на слияние одной командой не добавляя набор удалённых репозиториев. Теперь можно получить ссылки напрямую. @@ -165,7 +165,7 @@ Git с радостью слушается и выкачивает всё нео Далее, вы можете слить изменения в нужную ветку при помощи команды `git merge FETCH_HEAD`, однако сообщение коммита слияния будет выглядеть немного странно. Так же это становится утомительным, если вы просматриваете *много* запросов на слияние. -Существует способ получать _все_ запросы слияния и поддерживать их в актуальном состоянии при подключении к удалённому репозиторию. +Существует способ получать _все_ запросы на слияние и поддерживать их в актуальном состоянии при подключении к удалённому репозиторию. Откройте файл `.git/config` в текстовом редакторе и обратите внимание на секцию удалённого репозитория `origin`. Она должна выглядеть как-то так: @@ -203,7 +203,7 @@ $ git fetch ---- Все запросы слияния из удалённого репозитория представлены в локальном репозитории как ветки слежения; они только для чтения и обновляются каждый раз при выполнении `git fetch`. -Таким образом, локальное тестирование кода запроса слияния становится очень простым: +Таким образом, локальное тестирование кода запроса на слияние становится очень простым: [source,console] ---- @@ -218,21 +218,21 @@ Switched to a new branch 'pr/2' Это позволяет вам протестировать слияние перед нажатием этой кнопки. -===== Запросы слияния на запросы слияния +===== Запросы на слияние на запросы на слияние -Вы можете открыть запрос слияния не только в ветку `master`, запросы слияния могут указывать на любую ветку любого репозитория в сети. -По сути, вы можете даже открыть запрос слияния, указывающий на другой запрос слияния. +Вы можете открыть запрос на слияние не только в ветку `master`, запросы на слияние могут указывать на любую ветку любого репозитория в сети. +По сути, вы можете даже открыть запрос на слияние, указывающий на другой запрос на слияние. -Если вы видите толковый запрос слияния и у вас есть идея как его улучшить или вы не уверены, что это хорошая идея, или у вас просто нет прав записи в целевую ветку, то в таком случае вы можете открыть запрос слияния, указывающий на данный запрос. +Если вы видите толковый запрос на слияние и у вас есть идея как его улучшить или вы не уверены, что это хорошая идея, или у вас просто нет прав записи в целевую ветку, то в таком случае вы можете открыть запрос на слияние, указывающий на данный запрос на слияние. При открытии запроса на слияние вверху страницы вы увидите меню для выбора целевой и исходной веток. Если нажать кнопку kbd:[Edit] справа, то станет доступным выбор не только исходной ветки, а ещё и форка. [[r_pr_targets]] -.Ручное изменение форка и ветки для запроса слияния -image::images/maint-04-target.png["Объекты запроса слияния"] +.Ручное изменение форка и ветки для запроса на слияние +image::images/maint-04-target.png["Объекты запроса на слияние"] -Здесь можно указать вашу новую ветку для слияния с другим запросом слияния или другим форком проекта. +Здесь можно указать вашу новую ветку для слияния с другим запросом на слияние или другим форком проекта. ==== Упоминания и уведомления @@ -247,14 +247,14 @@ image::images/maint-05-mentions.png["Упоминания"] Как только вы оставите комментарий с упоминанием пользователя, ему будет отправлено уведомление. Таким образом, можно более эффективно вовлекать пользователей в обсуждение, не опрашивая их непосредственно. -Очень часто в запросах слияния на GitHub пользователи приглашают других людей в свои команды или компании для рецензии проблем или запросов слияния. +Очень часто в запросах на слияние на GitHub пользователи приглашают других людей в свои команды или компании для рецензии проблем или запросов на слияние. -Если кто-то будет упомянут в запросе слияния или проблеме, то он автоматически «подписывается» и будет получать уведомления о последующей активности. -Вы так же будете подписаны на некоторые уведомления если просто откроете запрос слияния или проблему, станете отслеживать репозиторий или если оставите комментарий. +Если кто-то будет упомянут в запросе на слияние или проблеме, то он автоматически «подписывается» и будет получать уведомления о последующей активности. +Вы так же будете подписаны на некоторые уведомления если просто откроете запрос на слияние или проблему, станете отслеживать репозиторий или если оставите комментарий. Для прекращения отправки вам уведомлений нажмите кнопку kbd:[Unsubscribe]. -.Отказ от подписки на проблему или запрос слияния +.Отказ от подписки на проблему или запрос на слияние image::images/maint-06-unsubscribe.png["Отказ от подписки"] ===== Страница уведомлений diff --git a/book/A-git-in-other-environments/sections/jetbrainsides.asc b/book/A-git-in-other-environments/sections/jetbrainsides.asc index 878f952c..c7fe31a4 100644 --- a/book/A-git-in-other-environments/sections/jetbrainsides.asc +++ b/book/A-git-in-other-environments/sections/jetbrainsides.asc @@ -1,7 +1,7 @@ === Git в IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine JetBrains IDE (такие как IntelliJ IDEA, PyCharm, WebStorm, PhpStorm, RubyMine и другие) поставляются с соответствующим плагином для интеграции с Git. -Он предоставляет собственный интерфейс для работы с запросами слияния Git и GitHub. +Он предоставляет собственный интерфейс для работы с запросами на слияние Git и GitHub. .Окно версионного контроля в JetBrains IDE image::images/jb.png["Окно версионного контроля в средах JetBrains"] diff --git a/book/A-git-in-other-environments/sections/visualstudiocode.asc b/book/A-git-in-other-environments/sections/visualstudiocode.asc index a7011f47..6e5de9ec 100644 --- a/book/A-git-in-other-environments/sections/visualstudiocode.asc +++ b/book/A-git-in-other-environments/sections/visualstudiocode.asc @@ -15,7 +15,7 @@ Visual Studio Code имеет встроенную поддержку Git. ** Push/pull/sync с удалённой веткой. ** Разрешение конфликтов слияния. ** Просмотр изменений. -* С помощью плагина можно работать с запросами слияния на GitHub: +* С помощью плагина можно работать с запросами на слияние на GitHub: https://marketplace.visualstudio.com/items?itemName=GitHub.vscode-pull-request-github[^]. Официальная документация доступна здесь: https://code.visualstudio.com/Docs/editor/versioncontrol[^]. From 9be0989d8f1bcf70923e4703dcbbee218dd0abc7 Mon Sep 17 00:00:00 2001 From: Viktor Yegay Date: Wed, 7 Feb 2024 06:12:55 +0500 Subject: [PATCH 13/13] =?UTF-8?q?=D0=9F=D1=80=D0=B8=D0=B2=D0=B5=D1=81?= =?UTF-8?q?=D1=82=D0=B8=20=D0=BA=20=D0=B5=D0=B4=D0=B8=D0=BD=D0=BE=D0=BE?= =?UTF-8?q?=D0=B1=D1=80=D0=B0=D0=B7=D0=B8=D1=8E=20"=D0=BF=D0=B5=D1=80?= =?UTF-8?q?=D0=B5=D0=B1=D0=B0=D0=B7=D0=B8=D1=80=D0=BE=D0=B2=D0=B0=D0=BD?= =?UTF-8?q?=D0=B8=D0=B5"?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- book/03-git-branching/sections/rebasing.asc | 26 +++++++++---------- .../sections/client-svn.asc | 2 +- 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc index 2ed283c0..e7459218 100644 --- a/book/03-git-branching/sections/rebasing.asc +++ b/book/03-git-branching/sections/rebasing.asc @@ -60,7 +60,7 @@ image::images/basic-rebase-4.png["Перемотка ветки `master`"] Учтите, что снимок, на который ссылается ваш последний коммит -- является ли он последним коммитом после перебазирования или коммитом слияния после слияния -- в обоих случаях это один и тот же снимок, отличаются только истории коммитов. Перебазирование повторяет изменения из одной ветки поверх другой в том порядке, в котором эти изменения были сделаны, в то время как слияние берёт две конечные точки и сливает их вместе. -==== Более интересные перемещения +==== Более интересные перебазирования Также возможно сделать так, чтобы при перебазировании воспроизведение коммитов применялось к совершенно другой ветке. Для примера возьмём <>. @@ -83,8 +83,8 @@ $ git rebase --onto master server client В этой команде говорится: «Переключись на ветку `client`, найди изменения относительно ветки `server` и примени их для ветки `master`». Несмотря на некоторую сложность этого способа, результат впечатляет. -.Перемещение тематической ветки, ответвлённой от другой тематической ветки -image::images/interesting-rebase-2.png["Перемещение тематической ветки, ответвлённой от другой тематической ветки"] +.Перебазирование тематической ветки, ответвлённой от другой тематической ветки +image::images/interesting-rebase-2.png["Перебазирование тематической ветки, ответвлённой от другой тематической ветки"] Теперь вы можете выполнить перемотку (fast-forward) для ветки `master` (см <>): @@ -133,21 +133,21 @@ $ git branch -d server image::images/interesting-rebase-5.png["Окончательная история коммитов"] [[r_rebase_peril]] -==== Опасности перемещения +==== Опасности перебазирования (((перебазирование, опасности))) Но даже перебазирование, при всех своих достоинствах, не лишено недостатков, которые можно выразить одной строчкой: -**Не перемещайте коммиты, уже отправленные в публичный репозиторий** +**Не перебазируйте коммиты, уже отправленные в публичный репозиторий** Если вы будете придерживаться этого правила, всё будет хорошо. Если не будете, люди возненавидят вас, а ваши друзья и семья будут вас презирать. -Когда вы что-то перемещаете, вы отменяете существующие коммиты и создаёте новые, похожие на старые, но являющиеся другими. +Когда вы что-то перебазируете, вы отменяете существующие коммиты и создаёте новые, похожие на старые, но являющиеся другими. Если вы куда-нибудь отправляете свои коммиты и другие люди забирают их себе и в дальнейшем основывают на них свою работу, а затем вы переделываете эти коммиты командой `git rebase` и выкладываете их снова, то ваши коллеги будут вынуждены заново выполнять слияние для своих наработок. В итоге, когда вы в очередной раз попытаетесь включить их работу в свою, вы получите путаницу. -Давайте рассмотрим пример того, как перемещение публично доступных наработок может вызвать проблемы. +Давайте рассмотрим пример того, как перебазирование публично доступных наработок может вызвать проблемы. Предположим, вы клонировали репозиторий с сервера и сделали какую-то работу. И ваша история коммитов выглядит так: @@ -179,7 +179,7 @@ image::images/perils-of-rebasing-4.png["Вы снова выполняете с Логично предположить, что разработчик не хочет, чтобы `C4` и `C6` были в истории, и именно поэтому она перебазируется в первую очередь. [[r_rebase_rebase]] -==== Меняя базу, меняй основание +==== При перебазировании, перебазируйте Если вы попали в такую ситуацию, у Git есть особая магия чтобы вам помочь. Если кто-то в вашей команде форсирует отправку изменений на сервер, переписывающих работу, на которых базировалась ваша работа, то ваша задача будет состоять в определении того, что именно было ваше, а что было переписано ими. @@ -199,8 +199,8 @@ image::images/perils-of-rebasing-4.png["Вы снова выполняете с Таким образом, вместо результата, который мы можем наблюдать на <>, у нас получилось бы что-то вроде <>. [[r_rebase_rebase_work]] -.Перемещение в начало force-pushed перемещённой работы -image::images/perils-of-rebasing-5.png["Перемещение в начало force-pushed перемещённой работы"] +.Перебазирование в начало force-pushed перебазированной работы +image::images/perils-of-rebasing-5.png["Перебазирование в начало force-pushed перебазированной работы"] Это возможно, если `C4` и `C4'` фактически являются одним и тем же патчем, который был сделан вашим коллегой. В противном случае `rebase` не сможет определить дубликат и создаст ещё один патч, подобный `C4` (который с большой вероятностью не удастся применить чисто, поскольку в нём уже присутствуют некоторые изменения). @@ -211,14 +211,14 @@ image::images/perils-of-rebasing-5.png["Перемещение в начало f Если вы используете `git pull` и хотите использовать `--rebase` по умолчанию, вы можете установить соответствующее значение конфигурации `pull.rebase` с помощью команды `git config --global pull.rebase true`. Если вы рассматриваете перебазирование как способ наведения порядка и работаете с коммитами локально до их отправки или ваши коммиты никогда не будут доступны публично -- у вас всё будет хорошо. -Однако, если вы перемещаете коммиты, отправленные в публичный репозиторий, и есть вероятность, что работа некоторых людей основывается на этих коммитах, то ваши действия могут вызвать существенные проблемы, а вы -- вызвать презрение вашей команды. +Однако, если вы перебазируете коммиты, отправленные в публичный репозиторий, и есть вероятность, что работа некоторых людей основывается на этих коммитах, то ваши действия могут вызвать существенные проблемы, а вы -- вызвать презрение вашей команды. Если в какой-то момент вы или ваш коллега находите необходимость в этом, убедитесь, что все знают, как применять команду `git pull --rebase` для минимизации последствий от подобных действий. -==== Перемещение vs. Слияние +==== Перебазирование в сравнении со слиянием (((перебазирование, против слияния)))(((слияние, против перебазирования))) -Теперь, когда вы увидели перемещение и слияние в действии, вы можете задаться вопросом, что из них лучше. +Теперь, когда вы увидели перебазирование и слияние в действии, вы можете задаться вопросом, что из них лучше. Прежде чем ответить на этот вопрос, давайте вернёмся немного назад и поговорим о том, что означает история. Одна из точек зрения заключается в том, что история коммитов в вашем репозитории -- это *запись того, что на самом деле произошло*. diff --git a/book/09-git-and-other-scms/sections/client-svn.asc b/book/09-git-and-other-scms/sections/client-svn.asc index b57d6422..fb3c4114 100644 --- a/book/09-git-and-other-scms/sections/client-svn.asc +++ b/book/09-git-and-other-scms/sections/client-svn.asc @@ -233,7 +233,7 @@ ones (if any) seem to be successfully integrated into the working tree. Please see the above messages for details. ---- -Чтобы решить эту проблему запустите `git svn rebase`, которая заберёт все ревизии с сервера, которых у вас пока нет, и переместит (rebase) ваши локальные наработки на них: +Чтобы решить эту проблему запустите `git svn rebase`, которая заберёт все ревизии с сервера, которых у вас пока нет, и перебазирует (rebase) ваши локальные наработки на них: [source,console] ----