From 2c3000a47699de3a77ab0cb78a2df8e6872244b0 Mon Sep 17 00:00:00 2001 From: Dexter Morganov Date: Sun, 31 Jan 2021 17:28:24 +0300 Subject: [PATCH 01/12] =?UTF-8?q?=D0=94=D0=B8=D1=80=D0=B5=D0=BA=D1=82?= =?UTF-8?q?=D0=BE=D1=80=D0=B8=D1=8F=20=D0=B8=D1=81=D0=BF=D1=80=D0=B0=D0=B2?= =?UTF-8?q?=D0=BB=D0=B5=D0=BD=D0=B0=20=D0=BD=D0=B0=20=D0=BA=D0=B0=D1=82?= =?UTF-8?q?=D0=B0=D0=BB=D0=BE=D0=B3?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- C-git-commands.asc | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/C-git-commands.asc b/C-git-commands.asc index e2b343e5..4bf9c5ba 100644 --- a/C-git-commands.asc +++ b/C-git-commands.asc @@ -37,7 +37,7 @@ В главе <> мы использовали её для задания хранилища ваших HTTP паролей. -В главе <> мы показали как настроить фильтры содержимого для данных, перемещаемых между индексом и рабочей директорией. +В главе <> мы показали как настроить фильтры содержимого для данных, перемещаемых между индексом и рабочей копией. Ну и практически вся глава <> посвящена этой команде. @@ -88,11 +88,11 @@ === Клонирование и создание репозиториев Существует два способа создать Git репозиторий. -Первый -- клонировать его из существующего репозитория (например, по сети); второй -- создать репозиторий в существующей директории. +Первый -- клонировать его из существующего репозитория (например, по сети); второй -- создать репозиторий в существующем каталоге. ==== git init -Чтобы превратить обычную директорию в Git репозиторий и начать версионировать файлы в ней, просто запустите `git init`. +Чтобы превратить обычный каталог в Git репозиторий и начать версионировать файлы в нём, просто запустите `git init`. Впервые мы продемонстрировали эту команду в главе <> на примере создания нового репозитория для последующей работы с ним. @@ -105,13 +105,13 @@ ==== git clone На самом деле `git clone` работает как обёртка над некоторыми другими командами. -Она создаёт новую директорию, переходит внутрь и выполняет `git init` для создания пустого репозитория, затем она добавляет новый удалённый репозиторий (`git remote add`) для указанного URL (по умолчанию он получит имя `origin`), выполняет `git fetch` для этого репозитория и, наконец, обновляет вашу рабочую директорию до последнего коммита, используя `git checkout`. +Она создаёт новый каталог, переходит внутрь и выполняет `git init` для создания пустого репозитория, затем она добавляет новый удалённый репозиторий (`git remote add`) для указанного URL (по умолчанию он получит имя `origin`), выполняет `git fetch` для этого репозитория и, наконец, извлекает последний коммит в ваш рабочий каталог, используя `git checkout`. Команда `git clone` используется в десятке различных мест в этой книге, но мы перечислим наиболее интересные упоминания. Первоначальное знакомство происходит в главе <>, где мы даём немного объяснений и приводим несколько примеров. -В главе <> мы рассмотрели как использовать опцию `--bare`, чтобы создать копию Git репозитория без рабочей директории. +В главе <> мы рассмотрели как использовать опцию `--bare`, чтобы создать копию Git репозитория без рабочей копии. В главе <> мы использовали `git clone` для распаковки упакованного с помощью `git bundle` репозитория. @@ -126,7 +126,7 @@ ==== git add -Команда `git add` добавляет содержимое рабочей директории в индекс (staging area) для последующего коммита. +Команда `git add` добавляет содержимое рабочего каталога в индекс (staging area) для последующего коммита. По умолчанию `git commit` использует лишь этот индекс, так что вы можете использовать `git add` для сборки слепка вашего следующего коммита. Это одна из ключевых команд Git, мы упоминали о ней десятки раз на страницах книги. @@ -142,7 +142,7 @@ ==== git status -Команда `git status` показывает состояния файлов в рабочей директории и индексе: какие файлы изменены, но не добавлены в индекс; какие ожидают коммита в индексе. +Команда `git status` показывает состояния файлов в рабочем каталоге и индексе: какие файлы изменены, но не добавлены в индекс; какие ожидают коммита в индексе. Вдобавок к этому выводятся подсказки о том, как изменить состояние файлов. Мы познакомили вас с этой командой в главе <>, разобрали стандартный и упрощённый формат вывода. @@ -151,7 +151,7 @@ ==== git diff Команда `git diff` используется для вычисления разницы между любыми двумя Git деревьями. -Это может быть разница между вашей рабочей директорией и индексом (собственно `git diff`), разница между индексом и последним коммитом (`git diff --staged`), или между любыми двумя коммитами (`git diff master branchB`). +Это может быть разница между вашей рабочей копией и индексом (собственно `git diff`), разница между индексом и последним коммитом (`git diff --staged`), или между любыми двумя коммитами (`git diff master branchB`). Мы познакомили вас с основами этой команды в главе <>, где показали как посмотреть какие изменения уже добавлены в индекс, а какие -- ещё нет. @@ -188,7 +188,7 @@ Команда `git reset`, как можно догадаться из названия, используется в основном для отмены изменений. Она изменяет указатель `HEAD` и, опционально, состояние индекса. -Также эта команда может изменить файлы в рабочей директории при использовании параметра `--hard`, что может привести к потере наработок при неправильном использовании, так что убедитесь в серьёзности своих намерений прежде чем использовать его. +Также эта команда может изменить файлы в рабочем каталоге при использовании параметра `--hard`, что может привести к потере наработок при неправильном использовании, так что убедитесь в серьёзности своих намерений прежде чем использовать его. Мы рассказали об основах использования `git reset` в главе <>, где эта команда использовалась для удаления файла из индекса, добавленного туда с помощью `git add`. @@ -198,10 +198,10 @@ ==== git rm -Команда `git rm` используется в Git для удаления файлов из индекса и рабочей директории. +Команда `git rm` используется в Git для удаления файлов из индекса и рабочей копии. Она похожа на `git add` с тем лишь исключением, что она удаляет, а не добавляет файлы для следующего коммита. -Мы немного разобрались с этой командой в главе <>, показали как удалять файлы из рабочей директории и индекса и только из индекса, используя флаг `--cached`. +Мы немного разобрались с этой командой в главе <>, показали как удалять файлы из рабочего каталога и индекса и только из индекса, используя флаг `--cached`. Ещё один вариант использования `git rm` приведён в главе <>, где мы вкратце объяснили как использовать опцию `--ignore-unmatch` при выполнении `git filter-branch`, которая подавляет ошибки удаления несуществующих файлов. Это может быть полезно для автоматически выполняемых скриптов. @@ -214,7 +214,7 @@ ==== git clean -Команда `git clean` используется для удаления мусора из рабочей директории. +Команда `git clean` используется для удаления мусора из рабочего каталога. Это могут быть результаты сборки проекта или файлы конфликтов слияний. Мы рассмотрели множество опций и сценариев использования этой команды в главе <>. @@ -237,7 +237,7 @@ ==== git checkout -Команда `git checkout` используется для переключения веток и выгрузки их содержимого в рабочую директорию. +Команда `git checkout` используется для переключения веток и выгрузки их содержимого в рабочий каталог. Мы познакомились с этой командой в главе <> вместе с `git branch`. @@ -298,7 +298,7 @@ ==== git stash -Команда `git stash` используется для временного сохранения всех незакоммиченных изменений для очистки рабочей директории без необходимости коммитить незавершённую работу в новую ветку. +Команда `git stash` используется для временного сохранения всех незафиксированных изменений с целью очистки рабочего каталога без необходимости фиксировать незавершённую работу в текущей ветке. Эта команда практически целиком раскрыта в главе <>. From c097ba656d7ec439268c358011830f28bdcafed5 Mon Sep 17 00:00:00 2001 From: Dexter Morganov Date: Sun, 31 Jan 2021 17:55:20 +0300 Subject: [PATCH 02/12] =?UTF-8?q?=D0=9E=D0=B1=D0=BD=D0=BE=D0=B2=D0=BB?= =?UTF-8?q?=D1=91=D0=BD=20=D1=80=D0=B0=D0=B7=D0=B4=D0=B5=D0=BB=203?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- book/03-git-branching/sections/nutshell.asc | 4 ++-- book/03-git-branching/sections/remote-branches.asc | 2 +- ch03-git-branching.asc | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index 8bde239d..80e2cfa2 100644 --- a/book/03-git-branching/sections/nutshell.asc +++ b/book/03-git-branching/sections/nutshell.asc @@ -8,7 +8,7 @@ Когда вы делаете коммит, Git сохраняет его в виде объекта, который содержит указатель на снимок (snapshot) подготовленных данных. Этот объект так же содержит имя автора и email, сообщение и указатель на коммит или коммиты непосредственно предшествующие данному (его родителей): отсутствие родителя для первоначального коммита, один родитель для обычного коммита, и несколько родителей для результатов слияния двух и более веток. -Предположим, в вашей рабочей директории есть три файла и вы добавляете их все в индекс и создаёте коммит. +Предположим, у вас есть каталог с тремя файлами и вы добавляете их все в индекс и создаёте коммит. Во время индексации вычисляется контрольная сумма каждого файла (SHA-1 как мы узнали из <>), затем каждый файл сохраняется в репозиторий (Git называет такой файл _блоб_ -- большой бинарный объект), а контрольная сумма попадёт в индекс: [source,console] @@ -147,7 +147,7 @@ image::images/checkout-master.png["HEAD перемещается когда вы [NOTE] .Переключение веток меняет файлы в рабочем каталоге ==== -Важно запомнить, что при переключении веток в Git происходит изменение файлов в рабочей директории. +Важно запомнить, что при переключении веток в Git происходит изменение файлов в рабочем каталоге. Если вы переключаетесь на старую ветку, то рабочий каталог будет выглядеть так же, как выглядел на момент последнего коммита в ту ветку. Если Git по каким-то причинам не может этого сделать -- он не позволит вам переключиться вообще. ==== diff --git a/book/03-git-branching/sections/remote-branches.asc b/book/03-git-branching/sections/remote-branches.asc index d98dc754..f82d9c42 100644 --- a/book/03-git-branching/sections/remote-branches.asc +++ b/book/03-git-branching/sections/remote-branches.asc @@ -212,7 +212,7 @@ $ git fetch --all; git branch -vv ==== Получение изменений (((pulling))) -Команда `git fetch` получает с сервера все изменения, которых у вас ещё нет, но не будет изменять состояние вашей рабочей директории. +Команда `git fetch` получает с сервера все изменения, которых у вас ещё нет, но не будет изменять состояние вашей рабочей копии. Эта команда просто получает данные и позволяет вам самостоятельно сделать слияние. Тем не менее, существует команда `git pull`, которая в большинстве случаев является командой `git fetch`, за которой непосредственно следует команда `git merge`. Если у вас настроена ветка слежения как показано в предыдущем разделе, или она явно установлена, или она была создана автоматически командами `clone` или `checkout`, `git pull` определит сервер и ветку, за которыми следит ваша текущая ветка, получит данные с этого сервера и затем попытается слить удалённую ветку. diff --git a/ch03-git-branching.asc b/ch03-git-branching.asc index a54c1d2f..19752542 100644 --- a/ch03-git-branching.asc +++ b/ch03-git-branching.asc @@ -4,7 +4,7 @@ (((branches))) Почти каждая система контроля версий (СКВ) в какой-то форме поддерживает ветвление. Используя ветвление, Вы отклоняетесь от основной линии разработки и продолжаете работу независимо от неё, не вмешиваясь в основную линию. -Во многих СКВ создание веток -- это очень затратный процесс, часто требующий создания новой копии директории, что может занять много времени для большого проекта. +Во многих СКВ создание веток -- это очень затратный процесс, часто требующий создания новой копии каталога с исходным кодом, что может занять много времени для большого проекта. Некоторые люди, говоря о модели ветвления Git, называют ее «киллер-фича», что выгодно выделяет Git на фоне остальных СКВ. Что в ней такого особенного? From 019459e74c09339f912a52cb04e32f4dfb7b5d3c Mon Sep 17 00:00:00 2001 From: Dexter Morganov Date: Sun, 31 Jan 2021 18:01:22 +0300 Subject: [PATCH 03/12] =?UTF-8?q?=D0=9E=D0=B1=D0=BD=D0=BE=D0=B2=D0=BB?= =?UTF-8?q?=D1=91=D0=BD=20=D1=80=D0=B0=D0=B7=D0=B4=D0=B5=D0=BB=201?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- book/01-introduction/sections/about-version-control.asc | 4 ++-- book/01-introduction/sections/what-is-git.asc | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/book/01-introduction/sections/about-version-control.asc b/book/01-introduction/sections/about-version-control.asc index 943e6a48..6ef726b8 100644 --- a/book/01-introduction/sections/about-version-control.asc +++ b/book/01-introduction/sections/about-version-control.asc @@ -13,9 +13,9 @@ ==== Локальные системы контроля версий (((version control,local))) -Многие люди в качестве метода контроля версий применяют копирование файлов в отдельную директорию (возможно даже, директорию с отметкой по времени, если они достаточно сообразительны). +Многие люди в качестве метода контроля версий применяют копирование файлов в отдельный каталог (возможно даже, каталог с отметкой по времени, если они достаточно сообразительны). Данный подход очень распространён из-за его простоты, однако он невероятно сильно подвержен появлению ошибок. -Можно легко забыть, в какой директории вы находитесь, и случайно изменить не тот файл или скопировать не те файлы, которые вы хотели. +Можно легко забыть в каком каталоге вы находитесь и случайно изменить не тот файл или скопировать не те файлы, которые вы хотели. Для того, чтобы решить эту проблему, программисты давным-давно разработали локальные СКВ с простой базой данных, которая хранит записи о всех изменениях в файлах, осуществляя тем самым контроль ревизий. diff --git a/book/01-introduction/sections/what-is-git.asc b/book/01-introduction/sections/what-is-git.asc index 38dae889..38d861b3 100644 --- a/book/01-introduction/sections/what-is-git.asc +++ b/book/01-introduction/sections/what-is-git.asc @@ -51,7 +51,7 @@ Git переосмысливает практически все аспекты В Git для всего вычисляется хеш-сумма, и только потом происходит сохранение. В дальнейшем обращение к сохранённым объектам происходит по этой хеш-сумме. -Это значит, что невозможно изменить содержимое файла или директории так, чтобы Git не узнал об этом. +Это значит, что невозможно изменить содержимое файла или каталога так, чтобы Git не узнал об этом. Данная функциональность встроена в Git на низком уровне и является неотъемлемой частью его философии. Вы не потеряете информацию во время её передачи и не получите повреждённый файл без ведома Git. From 1cae3bd0f593f3e66a24f74256772e94784c1855 Mon Sep 17 00:00:00 2001 From: Dexter Morganov Date: Sun, 31 Jan 2021 18:15:26 +0300 Subject: [PATCH 04/12] =?UTF-8?q?=D0=9E=D0=B1=D0=BD=D0=BE=D0=B2=D0=BB?= =?UTF-8?q?=D1=91=D0=BD=20=D1=80=D0=B0=D0=B7=D0=B4=D0=B5=D0=BB=202?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../sections/getting-a-repository.asc | 14 ++++++------- .../sections/recording-changes.asc | 20 +++++++++---------- .../sections/viewing-history.asc | 2 +- 3 files changed, 18 insertions(+), 18 deletions(-) diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index 1fd32cce..620a4522 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -8,9 +8,9 @@ В обоих случаях вы получите готовый к работе Git репозиторий на вашем компьютере. -==== Создание репозитория в существующей директории +==== Создание репозитория в существующем каталоге -Если у вас уже есть проект в директории, которая не находится под версионным контролем Git, то для начала нужно перейти в эту директорию. +Если у вас уже есть проект в каталоге, который не находится под версионным контролем Git, то для начала нужно перейти в него. Если вы не делали этого раньше, то для разных операционных систем это выглядит по-разному: для Linux: @@ -36,9 +36,9 @@ $ cd C:/Users/user/my_project $ git init ---- -Эта команда создаёт в текущей директории новую поддиректорию с именем `.git`, содержащую все необходимые файлы репозитория -- структуру Git-репозитория. +Эта команда создаёт в текущем каталоге новый подкаталог с именем `.git`, содержащий все необходимые файлы репозитория -- структуру Git репозитория. На этом этапе ваш проект ещё не находится под версионным контролем. -(Подробное описание файлов содержащихся в только что созданной вами директории `.git` приведено в главе <>)(((git commands, init))) +Подробное описание файлов, содержащихся в только что созданном вами каталоге `.git`, приведено в главе <>(((git commands, init))) Если вы хотите добавить под версионный контроль существующие файлы (в отличие от пустого каталога), вам стоит добавить их в индекс и осуществить первый коммит изменений. Добиться этого вы сможете запустив команду `git add` несколько раз, указав индексируемые файлы, а затем выполнив `git commit`: @@ -70,9 +70,9 @@ $ git commit -m 'Initial project version' $ git clone https://github.com/libgit2/libgit2 ---- -Эта команда создаёт директорию `libgit2`, инициализирует в ней поддиректорию `.git`, скачивает все данные для этого репозитория и извлекает рабочую копию последней версии. -Если вы зайдёте в новую директорию `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 fc38530e..113912c0 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -194,8 +194,8 @@ M lib/simplegit.rb Новые неотслеживаемые файлы помечены `??` слева от них, файлы добавленные в отслеживаемые помечены `A`, отредактированные файлы помечены `M` и так далее. В выводе содержится два столбца -- в левом указывается статус файла, а в правом модифицирован ли он после этого. -К примеру в нашем выводе, файл `README` модифицирован в рабочей директории и не проиндексирован, файл `lib/simplegit.rb` модифицирован и проиндексирован. -Файл `Rakefile` модифицирован, проиндексирован и ещё раз модифицирован, таким образом на данный момент у него есть изменения которые попадут в коммит и те которые не попадут. +К примеру в нашем выводе, файл `README` модифицирован в рабочем каталоге, но не проиндексирован, а файл `lib/simplegit.rb` модифицирован и проиндексирован. +Файл `Rakefile` модифицирован, проиндексирован и ещё раз модифицирован, таким образом на данный момент у него есть те изменения, которые попадут в коммит, и те, которые не попадут. [[r_ignoring]] ==== Игнорирование файлов @@ -227,7 +227,7 @@ $ cat .gitignore Glob-шаблоны представляют собой упрощённые регулярные выражения, используемые командными интерпретаторами. Символ (`+*+`) соответствует 0 или более символам; последовательность `[abc]` -- любому символу из указанных в скобках (в данном примере a, b или c); знак вопроса (`?`) соответствует одному символу; и квадратные скобки, в которые заключены символы, разделённые дефисом (`[0-9]`), соответствуют любому символу из интервала (в данном случае от 0 до 9). -Вы также можете использовать две звёздочки, чтобы указать на вложенные директории: `a/**/z` соответствует `a/z`, `a/b/z`, `a/b/c/z`, и так далее. +Вы также можете использовать две звёздочки, чтобы указать на вложенные каталоги: `a/**/z` соответствует `a/z`, `a/b/z`, `a/b/c/z`, и так далее. Вот ещё один пример файла `.gitignore`: @@ -239,16 +239,16 @@ Glob-шаблоны представляют собой упрощённые р # Но отслеживать файл lib.a даже если он подпадает под исключение выше !lib.a -# Исключить файл TODO в корневой директории, но не файл в subdir/TODO +# Исключить файл TODO в корневом каталоге, но не файл в subdir/TODO /TODO -# Игнорировать все файлы в директории build/ +# Игнорировать все файлы в каталоге build/ build/ # Игнорировать файл doc/notes.txt, но не файл doc/server/arch.txt doc/*.txt -# Игнорировать все .txt файлы в директории doc/ +# Игнорировать все .txt файлы в каталоге doc/ doc/**/*.txt ---- @@ -259,9 +259,9 @@ GitHub поддерживает довольно полный список пр [NOTE] ==== -В простейшем случае репозиторий будет иметь один файл `.gitignore` в корневой директории, правила из которого будут рекурсивно применяться ко всем поддиректориям. -Так же возможно использовать `.gitignore` файлы в поддиректориях. -Правила из этих файлов будут применяться только к директории, в которой находятся. +В простейшем случае репозиторий будет иметь один файл `.gitignore` в корневом каталоге, правила из которого будут рекурсивно применяться ко всем подкаталогам. +Так же возможно использовать `.gitignore` файлы в подкаталогах. +Правила из этих файлов будут применяться только к каталогам, в которых они находятся. Например, репозиторий исходного кода ядра Linux содержит 206 файлов `.gitignore`. Детальное рассмотрение использования нескольких `.gitignore` файлов выходит за пределы этой книги; детали доступны в справке `man gitignore`. @@ -563,7 +563,7 @@ $ git rm log/\*.log Обратите внимание на обратный слеш (`\`) перед `*`. Он необходим из-за того, что Git использует свой собственный обработчик имён файлов вдобавок к обработчику вашего командного интерпретатора. -Эта команда удаляет все файлы имеющие расширение `.log` находящиеся в директории `log/`. +Эта команда удаляет все файлы, имеющие расширение `.log` и находящиеся в каталоге `log/`. Или же вы можете сделать вот так: [source,console] diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index c97acfff..603a9005 100644 --- a/book/02-git-basics/sections/viewing-history.asc +++ b/book/02-git-basics/sections/viewing-history.asc @@ -258,7 +258,7 @@ $ git log -S function_name ---- Последней полезной опцией, которую принимает команда `git log` как фильтр, является путь. -Если вы укажете директорию или имя файла, вы ограничите вывод только теми коммитами, в которых были изменения этих файлов. +Если вы укажете каталог или имя файла, вы ограничите вывод только теми коммитами, в которых были изменения этих файлов. Эта опция всегда указывается последней после двойного тире (`--`), чтобы отделить пути от опций: [source,console] From 5031c46ba4228bd46035a02d6dcc3a17d9a6dab4 Mon Sep 17 00:00:00 2001 From: Dexter Morganov Date: Sun, 31 Jan 2021 18:20:17 +0300 Subject: [PATCH 05/12] =?UTF-8?q?=D0=9E=D0=B1=D0=BD=D0=BE=D0=B2=D0=BB?= =?UTF-8?q?=D1=91=D0=BD=20=D1=80=D0=B0=D0=B7=D0=B4=D0=B5=D0=BB=204?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- book/04-git-server/sections/generating-ssh-key.asc | 4 ++-- book/04-git-server/sections/git-on-a-server.asc | 2 +- book/04-git-server/sections/protocols.asc | 2 +- book/04-git-server/sections/setting-up-server.asc | 4 ++-- book/04-git-server/sections/smart-http.asc | 2 +- 5 files changed, 7 insertions(+), 7 deletions(-) diff --git a/book/04-git-server/sections/generating-ssh-key.asc b/book/04-git-server/sections/generating-ssh-key.asc index 2e51544f..3d383fde 100644 --- a/book/04-git-server/sections/generating-ssh-key.asc +++ b/book/04-git-server/sections/generating-ssh-key.asc @@ -6,8 +6,8 @@ Для того чтобы предоставить открытый ключ, каждый пользователь в системе должен его сгенерировать, если только этого уже не было сделано ранее. Этот процесс аналогичен во всех операционных системах. Сначала вам стоит убедиться, что у вас ещё нет ключа. -По умолчанию пользовательские SSH ключи сохраняются в каталоге `~/.ssh` домашней директории пользователя. -Вы можете легко проверить наличие ключа зайдя в этот каталог и посмотрев его содержимое: +По умолчанию пользовательские SSH ключи сохраняются в каталоге `~/.ssh` домашнем каталоге пользователя. +Вы можете легко проверить наличие ключа перейдя в этот каталог и посмотрев его содержимое: [source,console] ---- diff --git a/book/04-git-server/sections/git-on-a-server.asc b/book/04-git-server/sections/git-on-a-server.asc index cdf249bb..956fe3b5 100644 --- a/book/04-git-server/sections/git-on-a-server.asc +++ b/book/04-git-server/sections/git-on-a-server.asc @@ -93,7 +93,7 @@ $ git init --bare --shared Первый -- создать учётные записи для каждого, это просто, но может быть весьма обременительно. Вероятно, вы не захотите для каждого пользователя выполнять `adduser` (или `useradd`) и задавать временные пароли. -Второй способ -- это создать на сервере пользователя 'git', попросить всех участников, кому требуется доступ на запись, прислать вам открытый ключ SSH и добавить эти ключи в файл `~/.ssh/authorized_keys` в домашней директории пользователя 'git'. +Второй способ -- это создать на сервере пользователя 'git', попросить всех участников, кому требуется доступ на запись, прислать вам открытый ключ SSH и добавить эти ключи в файл `~/.ssh/authorized_keys` в домашнем каталоге пользователя 'git'. Теперь все будут иметь доступ к этой машине используя пользователя 'git'. Это никак не повлияет на данные в коммите -- пользователь, под которым вы соединяетесь с сервером по SSH, не воздействует на созданные вами коммиты. diff --git a/book/04-git-server/sections/protocols.asc b/book/04-git-server/sections/protocols.asc index d042d6c0..c52abb73 100644 --- a/book/04-git-server/sections/protocols.asc +++ b/book/04-git-server/sections/protocols.asc @@ -61,7 +61,7 @@ $ git remote add local_proj /srv/git/project.git Репозиторий на NFS часто медленнее, чем репозиторий через SSH на том же сервере, позволяющий Git использовать на полную локальные диски на каждой системе. Наконец, этот протокол не защищает репозиторий от случайного повреждения. -Все пользователи имеют доступ к «удалённой» директории и ничего не мешает изменению или удалению внутренних файлов Git и, как следствие, повреждению репозитория. +Все пользователи имеют доступ к «удалённому» каталогу и ничего не мешает изменению или удалению внутренних файлов Git и, как следствие, повреждению репозитория. ==== Протоколы HTTP diff --git a/book/04-git-server/sections/setting-up-server.asc b/book/04-git-server/sections/setting-up-server.asc index 8a5466e7..59ab561f 100644 --- a/book/04-git-server/sections/setting-up-server.asc +++ b/book/04-git-server/sections/setting-up-server.asc @@ -36,7 +36,7 @@ O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq dAv8JggJICUvax2T9va5 gsg-keypair ---- -Вы просто добавляете их в файл `.ssh/authorized_keys` в домашней директории пользователя `git`: +Вы просто добавляете их в файл `.ssh/authorized_keys` в домашнем каталоге пользователя `git`: [source,console] ---- @@ -144,6 +144,6 @@ AAAAB3NzaC1yc2EAAAADAQABAAABAQDEwENNMomTboYI+LJieaAY16qiXiH3wuvENhBG... ---- Теперь сетевые команды Git будут работать, но пользователи не смогут заходить на сервер. -Вы также можете создать директорию в домашнем каталоге пользователя `git`, чтобы немного изменить поведение `git-shell`. +Вы также можете создать подкаталог в домашнем каталоге пользователя `git`, чтобы немного изменить поведение `git-shell`. Например, вы можете ограничить команды Git, которые сервер будет принимать или сообщение, которое увидят пользователи если попробуют зайти по SSH. Для получения дополнительной информации по настройке оболочки запустите команду `git help shell`.(((git commands, help))) diff --git a/book/04-git-server/sections/smart-http.asc b/book/04-git-server/sections/smart-http.asc index f7d46363..67410f0e 100644 --- a/book/04-git-server/sections/smart-http.asc +++ b/book/04-git-server/sections/smart-http.asc @@ -18,7 +18,7 @@ $ a2enmod cgi alias env Это также включит необходимые для корректной работы модули `mod_cgi`, `mod_alias` и `mod_env`. -Так же необходимо установить Unix пользователя и группу для директории `/srv/git` в значение `www-data`, чтобы позволить веб-серверу читать из и писать в репозитории, потому что процесс Apache, запускающий CGI скрипт, работает от имени этого пользователя: +Так же необходимо установить Unix пользователя и группу для каталога `/srv/git` в значение `www-data`, чтобы позволить веб-серверу читать из и писать в репозитории, потому что процесс Apache, запускающий CGI скрипт, работает от имени этого пользователя: [source,console] ---- From 17010ad3ed8a3e0c5a22cfe633fdb58007dd70cb Mon Sep 17 00:00:00 2001 From: Dexter Morganov Date: Sun, 31 Jan 2021 18:29:39 +0300 Subject: [PATCH 06/12] =?UTF-8?q?=D0=9E=D0=B1=D0=BD=D0=BE=D0=B2=D0=BB?= =?UTF-8?q?=D1=91=D0=BD=20=D1=80=D0=B0=D0=B7=D0=B4=D0=B5=D0=BB=205?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- book/05-distributed-git/sections/maintaining.asc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 660d329a..119091ab 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -46,10 +46,10 @@ $ git checkout -b sc/ruby_client master $ git apply /tmp/patch-ruby-client.patch ---- -Это действие модифицирует файлы в вашей рабочей директории. +Это действие модифицирует файлы в вашем рабочем каталоге. Выполнение команды практически эквивалентно выполнению команды `patch -p1`, однако, является более параноидальным и принимает меньше неточных совпадений, чем `patch`. При этом обрабатываются добавления, удаления и переименования файлов, указанные в формате `git diff`, тогда как `patch` этого не делает. -Наконец, `git apply` использует модель «применить всё или отменить всё», где изменения либо применяются полностью, либо не применяются вообще, тогда как `patch` может частично применить патч файлы, приведя вашу рабочую директорию в непонятное состояние. +Наконец, `git apply` использует модель «применить всё или отменить всё», где изменения либо применяются полностью, либо не применяются вообще, тогда как `patch` может частично применить патч файлы, приведя ваш рабочий каталог в непонятное состояние. В целом, `git apply` более консервативен, чем `patch`. После выполнения команды новый коммит не создаётся и его нужно делать вручную. @@ -516,7 +516,7 @@ $ ls *.tar.gz v1.6.2-rc1-20-g8c5b85c.tar.gz ---- -Распаковав архив, вы получите последнее состояние кода вашего проекта в директории «project». +Распаковав архив, вы получите последнее состояние кода вашего проекта в каталоге `project`. Точно таким же способом можно создать zip архив, просто добавив опцию `--format=zip` для команды `git archive`: [source,console] From e92d16e8b1700d0a2fb59945430866e6b2cdc0c9 Mon Sep 17 00:00:00 2001 From: Dexter Morganov Date: Sun, 31 Jan 2021 19:05:16 +0300 Subject: [PATCH 07/12] =?UTF-8?q?=D0=9E=D0=B1=D0=BD=D0=BE=D0=B2=D0=BB?= =?UTF-8?q?=D1=91=D0=BD=20=D1=80=D0=B0=D0=B7=D0=B4=D0=B5=D0=BB=207?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../sections/advanced-merging.asc | 22 +++--- book/07-git-tools/sections/credentials.asc | 4 +- .../sections/interactive-staging.asc | 4 +- .../sections/rewriting-history.asc | 10 +-- .../sections/stashing-cleaning.asc | 20 +++--- book/07-git-tools/sections/submodules.asc | 70 +++++++++---------- book/07-git-tools/sections/subtree-merges.asc | 16 ++--- 7 files changed, 73 insertions(+), 73 deletions(-) diff --git a/book/07-git-tools/sections/advanced-merging.asc b/book/07-git-tools/sections/advanced-merging.asc index e845bc4f..c05df2f1 100644 --- a/book/07-git-tools/sections/advanced-merging.asc +++ b/book/07-git-tools/sections/advanced-merging.asc @@ -16,10 +16,10 @@ Git упрощает повторные слияния с одной и той Мы рассказали некоторые основы разрешения конфликтов слияния в <>, для работы с более сложными конфликтами Git предоставляет несколько инструментов, которые помогут вам понять, что произошло и как лучше обойтись с конфликтом. -Во-первых, если есть возможность, перед слиянием, в котором может возникнуть конфликт, позаботьтесь о том, чтобы ваша рабочая директория была без локальных изменений. +Во-первых, если есть возможность, перед слиянием, в котором может возникнуть конфликт, позаботьтесь о том, чтобы ваша рабочая копия была без локальных изменений. Если у вас есть несохранённые наработки, либо припрячьте их, либо сохраните их во временной ветке. -Таким образом, вы сможете легко отменить *любые* изменения, которые сделаете в рабочей директории. -Если при выполнении слияния вы не сохраните сделанные в рабочей директории изменения, то некоторые из описанных ниже приёмов могут привести к утрате этих наработок. +Таким образом, вы сможете легко отменить *любые* изменения, которые сделаете в рабочем каталоге. +Если при выполнении слияния вы не сохраните сделанные изменения, то некоторые из описанных ниже приёмов могут привести к утрате этих наработок. Давайте рассмотрим очень простой пример. Допустим, у нас есть файл с исходниками на Ruby, выводящими на экран строку 'hello world'. @@ -127,10 +127,10 @@ $ git status -sb ---- Эта команда пытается откатить ваше состояние до того, что было до запуска слияния. -Завершиться неудачно она может только в случаях если перед запуском слияния у вас были не припрятанные, не зафиксированные изменения в рабочей директории, во всех остальных случаях всё будет хорошо. +Завершиться неудачно она может только в случаях, если перед запуском слияния у вас были не припрятанные или не зафиксированные изменения в рабочем каталоге, во всех остальных случаях всё будет хорошо. Если по каким-то причинам вы обнаружили себя в ужасном состоянии и хотите просто начать всё сначала, вы можете также выполнить `git reset --hard HEAD` (либо вместо `HEAD` указав то, куда вы хотите откатиться). -Но помните, что это откатит все изменения в рабочей директории, поэтому удостоверьтесь, что никакие из них вам не нужны. +Но помните, что это откатит все изменения в рабочем каталоге, поэтому удостоверьтесь, что никакие из них вам не нужны. ===== Игнорирование пробельных символов @@ -193,7 +193,7 @@ $ git ls-files -u Выражение `:1:hello.rb` является просто сокращением для поиска такого SHA-1 хеша. -Теперь, когда в нашей рабочей директории присутствует содержимое всех трёх состояний, мы можем вручную исправить их, чтобы устранить проблемы с пробельными символами и повторно выполнить слияние с помощью малоизвестной команды `git merge-file`, которая делает именно это. +Теперь, когда в нашем рабочем каталоге присутствует содержимое всех трёх состояний, мы можем вручную исправить их, чтобы устранить проблемы с пробельными символами и повторно выполнить слияние с помощью малоизвестной команды `git merge-file`, которая делает именно это. [source,console] ---- @@ -224,7 +224,7 @@ index 36c06c8,e85207e..0000000 На самом деле, данный способ лучше, чем использование опции `ignore-all-space`, так как в его рамках вместо игнорирования изменений пробельных символов перед слиянием выполняется корректное исправление таких изменений. При слиянии с `ignore-all-space` мы в результате получим несколько строк с окончаниями в стиле DOS, то есть в одном файле смешаются разные стили окончания строк. -Если перед коммитом изменений вы хотите посмотреть какие в действительности были различия между состояниями, то можете воспользоваться командой `git diff`, сравнивающей содержимое вашей рабочей директории, которое будет зафиксировано как результат слияния, с любым из трёх состояний. +Если перед коммитом изменений вы хотите посмотреть какие в действительности были различия между состояниями, то можете воспользоваться командой `git diff`, сравнивающей содержимое вашего рабочего каталога, которое будет зафиксировано как результат слияния, с любым из трёх состояний. Давайте посмотрим на все эти сравнения. Чтобы сравнить результат слияния с тем, что было в вашей ветке до слияния, или другими словами увидеть, что привнесло данное слияние, вы можете выполнить `git diff --ours` @@ -463,9 +463,9 @@ index 0399cd5,59727f0..0000000 ---- Такой формат называется «комбинированным» («Combined Diff»), для каждого различия в нем содержится два раздела с информацией. -В первом разделе отображены различия строки (добавлена она или удалена) между «вашей» веткой и содержимым вашей рабочей директории, а во втором разделе содержится тоже самое, но между «их» веткой и рабочей директорией. +В первом разделе отображены различия строки (добавлена она или удалена) между «вашей» веткой и содержимым вашего рабочего каталога, а во втором разделе содержится тоже самое, но между «их» веткой и рабочим каталогом. -Таким образом, в данном примере вы можете увидеть строки `<<<<<<<` и `>>>>>>>` в файле в вашей рабочей директории, хотя они отсутствовали в сливаемых ветках. +Таким образом, в данном примере вы можете увидеть строки `<<<<<<<` и `>>>>>>>` в файле в вашем рабочем каталоге, хотя они отсутствовали в сливаемых ветках. Это вполне оправдано, потому что, добавляя их, инструмент слияния предоставляет вам дополнительную информацию, но предполагается, что мы удалим их. Если мы разрешим конфликт и снова выполним команду `git diff`, то получим ту же информацию, но в немного более полезном представлении. @@ -490,7 +490,7 @@ index 0399cd5,59727f0..0000000 hello() ---- -В этом выводе указано, что строка «hola world» при слиянии присутствовала в «нашей» ветке, но отсутствовала в рабочей директории, строка «hello mundo» была в «их» ветке, но не в рабочей директории, и, наконец, «hola mundo» не была ни в одной из сливаемых веток, но сейчас присутствует в рабочей директории. +В этом выводе указано, что строка «hola world» при слиянии присутствовала в «нашей» ветке, но отсутствовала в рабочей копии, строка «hello mundo» была в «их» ветке, но не в рабочей копии, и, наконец, «hola mundo» не была ни в одной из сливаемых веток, но сейчас присутствует в рабочей копии. Это бывает полезно просмотреть перед коммитом разрешения конфликта. Такую же информацию вы можете получить и после выполнения слияния с помощью команды `git log`, узнав таким образом как был разрешён конфликт. @@ -553,7 +553,7 @@ image::images/undomerge-reset.png["История после `git reset --hard H . Перемещает ветку, на которую указывает HEAD. В данном случае мы хотим переместить `master` туда, где она была до коммита слияния (`C6`). . Приводит индекс к такому же виду что и HEAD. -. Приводит рабочую директорию к такому же виду, что и индекс. +. Приводит рабочий каталог к такому же виду, что и индекс. Недостаток этого подхода состоит в изменении истории, что может привести к проблемам в случае совместно используемого репозитория. Загляните в <>, чтобы узнать что именно может произойти; кратко говоря, если у других людей уже есть какие-то из изменяемых вами коммитов, вы должны отказаться от использования `reset`. diff --git a/book/07-git-tools/sections/credentials.asc b/book/07-git-tools/sections/credentials.asc index 677728c5..1a98ed83 100644 --- a/book/07-git-tools/sections/credentials.asc +++ b/book/07-git-tools/sections/credentials.asc @@ -152,7 +152,7 @@ https://bob:s3cre7@mygithost Поскольку `git-credential-store` и подобные ей утилиты являются отдельными от Git программами, не сложно сделать так, чтобы _любая_ программа могла быть помощником авторизации Git. Помощники, предоставляемые Git, покрывают наиболее распространённые варианты использования, но не все. Для примера допустим, что ваша команда имеет некоторые учётные данные, совместно используемые всей командой, например, для развёртывания. -Эти данные хранятся в общедоступной директории, но вы не хотите копировать их в ваше собственное хранилище учётных данных, так как они часто изменяются. +Эти данные хранятся в общедоступном каталоге, но вы не хотите копировать их в ваше собственное хранилище учётных данных, так как они часто изменяются. Ни один из существующих помощников не покрывает этот случай; давайте посмотрим, что будет стоить написать свой собственный. Есть несколько ключевых особенностей, которым должна удовлетворять эта программа: @@ -175,7 +175,7 @@ include::../git-credential-read-only[] <4> Этот цикл читает содержимое файла хранилища, выполняя поиск соответствия. Если протокол и сервер из `known` соответствуют текущей строке, программа выводит результат и завершает работу. -Мы сохраним нашего помощника как `git-credential-read-only`, расположим его в одной из директорий из `PATH` и сделаем его исполняемым. +Мы сохраним нашего помощника как `git-credential-read-only`, поместим его в один из каталогов, содержащихся в списке `PATH`, а так же сделаем его исполняемым. Ниже приведено на что будет похож сеанс взаимодействия: [source,console] diff --git a/book/07-git-tools/sections/interactive-staging.asc b/book/07-git-tools/sections/interactive-staging.asc index 66a20f0b..8be7514d 100644 --- a/book/07-git-tools/sections/interactive-staging.asc +++ b/book/07-git-tools/sections/interactive-staging.asc @@ -93,7 +93,7 @@ Revert>> [enter] reverted one path ---- -Посмотрев снова на состояние вашей рабочей директории Git, вы увидите, что файл TODO исключён из индекса: +Посмотрев снова на состояние вашего рабочего каталога Git, вы увидите, что файл `TODO` исключён из индекса: [source,console] ---- @@ -183,7 +183,7 @@ e - вручную отредактировать текущую часть ---- Обычно вы будете вводить `y` или `n`, если вы хотите индексировать каждую часть по отдельности, но индексация всех частей в некоторых файлах или откладывание решения по индексацию части также может быть полезным. -Если вы добавили в индекс одну часть файла, но не добавили другую, состояние вашей рабочей директории будет подобно приведённому далее: +Если вы добавили в индекс одну часть файла, но не добавили другую, состояние вашего рабочего каталога будет подобно приведённому далее: [source,console] ---- diff --git a/book/07-git-tools/sections/rewriting-history.asc b/book/07-git-tools/sections/rewriting-history.asc index 78c61158..ece74bbf 100644 --- a/book/07-git-tools/sections/rewriting-history.asc +++ b/book/07-git-tools/sections/rewriting-history.asc @@ -364,10 +364,10 @@ Ref 'refs/heads/master' was rewritten Как правило, хорошим подходом будет выполнение всех этих действий в тестовой ветке и, после проверки полученных результатов, установка на неё указателя основной ветки. Для выполнения `filter-branch` на всех ваших ветках, вы можете передать команде опцию `--all`. -===== Установка поддиректории корневой директорией проекта +===== Установка подкаталога как корневого каталога проекта -Предположим, вы выполнили импорт из другой системы управления исходным кодом и получили в результате поддиректории, которые не имеют никакого смысла (trunk, tags и так далее). -Если вы хотите сделать поддиректорию `trunk` корневой директорией для каждого коммита, команда `filter-branch` может помочь вам в этом: +Предположим, вы выполнили импорт из другой системы контроля версий и получили в результате подкаталоги, которые не имеют никакого смысла (trunk, tags и так далее). +Если вы хотите сделать подкаталог `trunk` корневым для каждого коммита, команда `filter-branch` может помочь вам в этом: [source,console] ---- @@ -376,8 +376,8 @@ Rewrite 856f0bf61e41a27326cdae8f09fe708d679f596f (12/12) Ref 'refs/heads/master' was rewritten ---- -Теперь вашей новой корневой директорией проекта будет являться поддиректория `trunk`. -Git также автоматически удалит коммиты, которые не затрагивали эту поддиректорию. +Теперь вашим новым корневым каталогом проекта будет являться подкаталог `trunk`. +Git также автоматически удалит коммиты, которые не затрагивали этот подкаталог. ===== Глобальное изменение адреса электронной почты diff --git a/book/07-git-tools/sections/stashing-cleaning.asc b/book/07-git-tools/sections/stashing-cleaning.asc index 7e65447a..aab9066e 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` @@ -49,7 +49,7 @@ HEAD is now at 049d078 Create index file (To restore them type "git stash apply") ---- -Теперь вы можете увидеть, что рабочая директория не содержит изменений: +Теперь вы можете увидеть, что рабочая копия не содержит изменений: [source,console] ---- @@ -89,9 +89,9 @@ no changes added to commit (use "git add" and/or "git commit -a") ---- Как видите, Git восстановил в файлах изменения, которые вы отменили ранее, когда прятали свои наработки. -В данном случае при применении отложенных наработок ваша рабочая директория была без изменений, а вы пытались применить их в той же ветке, в которой вы их и сохранили; но отсутствие изменений в рабочей директории и применение их в той же ветке не являются необходимыми условиями для успешного восстановления припрятанных наработок. +В данном случае при применении отложенных наработок ваш рабочий каталог был без изменений, а вы пытались применить их в той же ветке, в которой вы их и сохранили; но отсутствие изменений в рабочем каталоге и применение их в той же ветке не являются необходимыми условиями для успешного восстановления припрятанных наработок. Вы можете припрятать изменения, находясь в одной ветке, а затем переключиться на другую и попробовать восстановить эти изменения. -Также при восстановлении припрятанных наработок в вашей рабочей директории могут присутствовать изменённые и незафиксированные файлы -- Git выдаст конфликты слияния, если не сможет восстановить какие-то наработки. +Также при восстановлении припрятанных наработок в вашем рабочем каталоге могут присутствовать изменённые и незафиксированные файлы -- Git выдаст конфликты слияния, если не сможет восстановить какие-то наработки. Спрятанные изменения будут применены к вашим файлам, но файлы, которые вы ранее добавляли в индекс, не будут добавлены туда снова. Для того, чтобы это было сделано, вы должны запустить `git stash apply` с опцией `--index`, при которой команда попытается восстановить изменения в индексе. @@ -168,7 +168,7 @@ $ git status -s $ ---- -И наконец, если вы укажете флаг `--patch`, Git не будет ничего прятать, а вместо этого в интерактивном режиме спросит вас о том, какие из изменений вы хотите припрятать, а какие оставить в вашей рабочей директории. +И наконец, если вы укажете флаг `--patch`, Git не будет ничего прятать, а вместо этого в интерактивном режиме спросит вас о том, какие из изменений вы хотите припрятать, а какие оставить в вашем рабочем каталоге. [source,console] ---- @@ -223,19 +223,19 @@ Dropped refs/stash@{0} (29d385a81d163dfd45a452a2ce816487a6b8b014) Это удобное сокращение для того, чтобы легко восстановить припрятанные изменения и поработать над ними в новой ветке. [[r_git_clean]] -==== Очистка вашей рабочей директории +==== Очистка рабочего каталога -Наконец, у вас может возникнуть желание не прятать некоторые из изменений или файлов в вашей рабочей директории, а просто избавиться от них. +Наконец, у вас может возникнуть желание не прятать некоторые из изменений или файлов в вашем рабочем каталоге, а просто избавиться от них. Команда `git clean` сделает это для вас. Одной из распространённых причин для этого может быть удаление мусора, который был сгенерирован при слиянии или внешними утилитами, или удаление артефактов сборки в процессе её очистки. -Вам нужно быть очень аккуратными с этой командой, так как она предназначена для удаления неотслеживаемых файлов из вашей рабочей директории. +Вам нужно быть очень аккуратными с этой командой, так как она предназначена для удаления неотслеживаемых файлов из вашего рабочего каталога. Даже если вы передумаете, очень часто нельзя восстановить содержимое таких файлов. Более безопасным вариантом является использование команды `git stash --all` для удаления всего, но с сохранением этого в виде припрятанных изменений. -Предположим, вы хотите удалить мусор и очистить вашу рабочую директорию; вы можете сделать это с помощью `git clean`. -Для удаления всех неотслеживаемых файлов в вашей рабочей директории, вы можете выполнить команду `git clean -f -d`, которая удалит все файлы и также все директории, которые в результате станут пустыми. +Предположим, вы хотите удалить мусор и очистить ваш рабочий каталог; вы можете сделать это с помощью `git clean`. +Для удаления всех неотслеживаемых файлов в вашем рабочем каталоге, вы можете выполнить команду `git clean -f -d`, которая удалит все файлы и также все каталоги, которые в результате станут пустыми. Опция `-f` значит 'force' или другими словами «действительно выполнить это». Если вы хотите только посмотреть, что будет сделано, вы можете запустить команду с опцией `-n`, которая означает «имитируй работу команды и скажи мне, что ты _будешь_ удалять». diff --git a/book/07-git-tools/sections/submodules.asc b/book/07-git-tools/sections/submodules.asc index 9c8fa306..9806090e 100644 --- a/book/07-git-tools/sections/submodules.asc +++ b/book/07-git-tools/sections/submodules.asc @@ -13,7 +13,7 @@ При включении кода библиотеки в свой проект проблема будет заключаться в сложном объединении ваших собственных изменений с изменениями в вышестоящем репозитории. Git решает эту проблему, предоставляя функциональность подмодулей. -Подмодули позволяют вам сохранить один Git-репозиторий, как поддиректорию другого Git-репозитория. +Подмодули позволяют вам сохранить один Git-репозиторий, как подкаталог другого Git-репозитория. Это даёт вам возможность клонировать в ваш проект другой репозиторий, но коммиты при этом хранить отдельно. [[r_starting_submodules]] @@ -36,7 +36,7 @@ Unpacking objects: 100% (11/11), done. Checking connectivity... done. ---- -По умолчанию подмодули добавляют подпроекты в директории, называемые так же, как и соответствующие репозитории, в нашем примере -- «DbConnector». +По умолчанию подмодули добавляют подпроекты в каталоги, называемые так же, как и соответствующие репозитории, в нашем примере -- «DbConnector». Если в данный момент вы выполните `git status`, то заметите несколько моментов. @@ -54,7 +54,7 @@ Changes to be committed: ---- Во-первых, вы должны заметить новый файл `.gitmodules`. -Это конфигурационный файл, в котором хранится соответствие между URL проекта и локальной поддиректорией, в которую вы его выкачали: +Это конфигурационный файл, в котором хранится соответствие между URL проекта и локальным подкаталогом, в который вы его выкачали: [source,console] ---- @@ -76,7 +76,7 @@ $ cat .gitmodules Вы можете изменить это значение локально только для себя с помощью команды `git config submodule.DbConnector.url PRIVATE_URL`. ===== -Следующим элементом вывода `git status` является сама директория проекта. +Следующим элементом вывода `git status` является сам каталог проекта. Если вы выполните `git diff` для неё, то увидите кое-что интересное: [source,console] @@ -91,8 +91,8 @@ index 0000000..c3f01dc +Subproject commit c3f01dc8862123d317dd46284b05b6892c7b29bc ---- -Хотя `DbConnector` является поддиректорией вашей рабочей директории, Git распознает её как подмодуль и не отслеживает её содержимое, когда вы не находитесь в этой директории. -Вместо этого, Git видит её как некоторый отдельный коммит из этого репозитория. +Хотя `DbConnector` является подкаталогом вашего рабочего каталога, Git распознает его как подмодуль и не отслеживает его содержимое, когда вы не находитесь в этом каталоге. +Вместо этого, Git видит его как некоторый отдельный коммит из этого репозитория. Если вам нужен немного более понятный вывод, то можете передать команде `git diff` опцию `--submodule`. @@ -123,13 +123,13 @@ $ git commit -am 'added DbConnector module' ---- Обратите внимание на права доступа `160000` у `DbConnector`. -Это специальные права доступа в Git, которые, по сути, означают, что вы сохраняете коммит как элемент каталога, а не как поддиректорию или файл. +Это специальные права доступа в Git, которые, по сути, означают, что вы сохраняете коммит как элемент каталога, а не как подкаталог или файл. [[r_cloning_submodules]] ==== Клонирование проекта с подмодулями Далее мы рассмотрим клонирование проекта, содержащего подмодули. -Когда вы клонируете такой проект, по умолчанию вы получите директории, содержащие подмодули, но ни одного файла в них не будет: +Когда вы клонируете такой проект, по умолчанию вы получите каталоги, содержащие подмодули, но ни одного файла в них не будет: [source,console] ---- @@ -157,7 +157,7 @@ $ ls $ ---- -Директория `DbConnector` присутствует, но она пустая. +Каталог `DbConnector` присутствует, но он пустой. Вы должны выполнить две команды: `git submodule init` -- для инициализации локального конфигурационного файла, и `git submodule update` -- для извлечения всех данных этого проекта и переключения на соответствующий коммит, указанный в вашем основном проекте. [source,console] @@ -174,7 +174,7 @@ Checking connectivity... done. Submodule path 'DbConnector': checked out 'c3f01dc8862123d317dd46284b05b6892c7b29bc' ---- -Теперь ваша директория `DbConnector` находятся в точно таком же состоянии, как и ранее при выполнении коммита. +Теперь ваш каталог `DbConnector` находятся в точно таком же состоянии, как и ранее при выполнении коммита. Однако, существует другой немного более простой вариант сделать тоже самое. Если вы передадите опцию `--recursive` команде `git clone`, то она автоматически инициализирует и обновит каждый подмодуль в этом репозитории. @@ -208,7 +208,7 @@ Submodule path 'DbConnector': checked out 'c3f01dc8862123d317dd46284b05b6892c7b2 Простейший вариант использования подмодулей в проекте состоит в том, что вы просто получаете сам подпроект и хотите периодически получать обновления, но в своей копии проекта ничего не изменяете. Давайте рассмотрим этот простой пример. -Если вы хотите проверить наличие изменений в подмодуле, вы можете перейти в его директорию, выполнить `git fetch` и затем `git merge` для обновления локальной версии из вышестоящего репозитория. +Если вы хотите проверить наличие изменений в подмодуле, вы можете перейти в его каталог, выполнить `git fetch` и затем `git merge` для обновления локальной версии из вышестоящего репозитория. [source,console] ---- @@ -237,7 +237,7 @@ Submodule DbConnector c3f01dc..d0354fc: Если в данный момент вы создадите коммит, то таким образом сделаете доступным новый код в подмодуле для других людей. -Если вы не хотите вручную извлекать и сливать изменения в поддиректорию, то для вас существует более простой способ сделать тоже самое. +Если вы не хотите вручную извлекать и сливать изменения в подкаталог, то для вас существует более простой способ сделать тоже самое. Если вы выполните `git submodule update --remote`, то Git сам перейдёт в ваши подмодули, заберёт изменения и обновит их для вас. [source,console] @@ -372,7 +372,7 @@ Submodule DbConnector c3f01dc..c87d55d: Давайте теперь рассмотрим пример, в котором мы одновременно с изменениями в основном проекте внесём изменения в подмодуль, зафиксировав и опубликовав все эти изменения в одно и то же время. -До сих пор, когда мы выполняли команду `git submodule update` для извлечения изменений из репозитория подмодуля, Git получал изменения и обновлял файлы в поддиректории, но оставлял подрепозиторий в состоянии, называемом «отделённый HEAD» («detached HEAD»). +До сих пор, когда мы выполняли команду `git submodule update` для извлечения изменений из репозитория подмодуля, Git получал изменения и обновлял файлы в подкаталоге, но оставлял подрепозиторий в состоянии, называемом «отделённый HEAD» («detached HEAD»). Это значит, что локальная рабочая ветка (такая, например, как «master»), отслеживающая изменения, отсутствует. Таким образом, любые вносимые вами изменения не будут нормально отслеживаться. @@ -381,7 +381,7 @@ Submodule DbConnector c3f01dc..c87d55d: Затем вам необходимо сообщить Git, что ему делать если вы внесли изменения, а затем командой `git submodule update --remote` получаете новые изменения из репозитория. Возможны два варианта -- вы можете слить их в вашу локальную версию или попробовать перебазировать ваши локальные наработки поверх новых изменений. -Первым делом, давайте перейдём в директорию нашего подмодуля и переключимся на нужную ветку. +Первым делом, давайте перейдём в каталог нашего подмодуля и переключимся на нужную ветку. [source,console] ---- @@ -408,7 +408,7 @@ Fast-forward Submodule path 'DbConnector': merged in '92c7337b30ef9e0893e758dac2459d07362ab5ea' ---- -Если мы перейдём в директорию DbConnector, то увидим, что новые изменения уже слиты в нашу локальную ветку `stable`. +Если мы перейдём в каталог DbConnector, то увидим, что новые изменения уже слиты в нашу локальную ветку `stable`. Теперь давайте посмотрим, что случится, когда мы внесём свои собственные локальные изменения в библиотеку, а кто-то другой в это же время отправит другие изменения в вышестоящий репозиторий. [source,console] @@ -438,9 +438,9 @@ $ git submodule update --remote Submodule path 'DbConnector': checked out '5d60ef9bbebf5a0c1c1050f242ceeb54ad58da94' ---- -Не беспокойтесь, если такое случится, вы можете просто вернуться в директорию, переключиться обратно на вашу ветку (которая всё ещё будет содержать ваши наработки) и слить или перебазировать ветку `origin/stable` (или другую нужную вам удалённую ветку) вручную. +Не беспокойтесь, если такое случится, вы можете просто вернуться в каталог, переключиться обратно на вашу ветку (которая всё ещё будет содержать ваши наработки) и слить или перебазировать ветку `origin/stable` (или другую нужную вам удалённую ветку) вручную. -Если вы не зафиксировали ваши изменения в подмодуле и выполнили его обновление, то это приведёт к проблемам -- Git извлечёт изменения из вышестоящего репозитория, но не затрёт несохранённые наработки в директории вашего подмодуля. +Если вы не зафиксировали ваши изменения в подмодуле и выполнили его обновление, то это приведёт к проблемам -- Git извлечёт изменения из вышестоящего репозитория, но не затрёт несохранённые наработки в каталоге вашего подмодуля. [source,console] ---- @@ -470,12 +470,12 @@ Automatic merge failed; fix conflicts and then commit the result. Unable to merge 'c75e92a2b3855c9e5b66f915308390d9db204aca' in submodule path 'DbConnector' ---- -Вы можете перейти в директорию подмодуля и исправить конфликт обычным образом. +Вы можете перейти в каталог подмодуля и исправить конфликт обычным образом. [[r_publishing_submodules]] ===== Публикация изменений в подмодуле -Теперь у нас есть некоторые изменения в директории нашего подмодуля. +Теперь у нас есть некоторые изменения в каталоге нашего подмодуля. Некоторые из них мы получили при обновлении из вышестоящего репозитория, а другие были сделаны локально и пока никому не доступны, так как мы их ещё никуда не отправили. [source,console] @@ -539,7 +539,7 @@ To https://github.com/chaconinc/MainProject 3d6d338..9a377d1 master -> master ---- -Как видите, перед отправкой на сервер основного проекта Git перешел в директорию модуля DbConnector и отправил на сервер его. +Как видите, перед отправкой на сервер основного проекта Git перешел в каталог модуля DbConnector и отправил на сервер его. Если отправка подмодуля по каким-то причинам завершилась неудачей, то и отправка основного проекта также завершится неудачей. ===== Объединение изменений подмодуля @@ -587,14 +587,14 @@ index eb41d76,c771610..0000000 ---- Так, в данном примере `eb41d76` является *нашим* коммитом в подмодуле, а `c771610` -- коммитом из вышестоящего репозитория. -Если мы перейдём в директорию нашего подмодуля, то он должен быть на коммит `eb41d76`, так как операция слияния его не изменяла. +Если мы перейдём в каталог нашего подмодуля, то он должен быть на коммите `eb41d76`, так как операция слияния его не изменяла. Если по каким-то причинам это не так, то вы можете просто переключиться на ветку (создав её при необходимости), указывающую на этот коммит. Куда более важным является SHA-1 хеш коммита другой стороны, который мы должны будем слить. Вы можете либо просто выполнить слияние, указав непосредственно этот SHA-1 хеш, либо вы можете создать с ним отдельную ветку и затем уже сливать эту ветку. Мы предлагаем использовать последний вариант, хотя бы только из-за того, что сообщение коммита слияния получается более читаемым. -Итак, перейдите в директорию нашего подмодуля, создайте ветку на основе второго SHA-1 хеша из `git diff` и выполните слияние вручную. +Итак, перейдите в каталог нашего подмодуля, создайте ветку на основе второго SHA-1 хеша из `git diff` и выполните слияние вручную. [source,console] ---- @@ -638,7 +638,7 @@ $ git commit -m "Merge Tom's Changes" <5> ---- <1> Во-первых, мы разрешили конфликт -<2> Затем мы вернулись в директорию основного проекта +<2> Затем мы вернулись в каталог основного проекта <3> Мы снова проверили SHA-1 хеши <4> Разрешили сам конфликтовавший подмодуль <5> Зафиксировали наше слияние @@ -673,7 +673,7 @@ Automatic merge failed; fix conflicts and then commit the result. Здесь предполагается, что вы обновите индекс, выполнив команду `git add`, которая очищает список конфликтов и затем создаёт коммит. Хотя вы, наверное, не обязаны делать так. -Вы можете также легко перейти в директорию подмодуля, просмотреть изменения, выполнить перемотку вперёд до этого коммита, выполнить необходимые проверки, а затем создать коммит. +Вы можете также легко перейти в каталог подмодуля, просмотреть изменения, выполнить перемотку вперёд до этого коммита, выполнить необходимые проверки, а затем создать коммит. [source,console] ---- @@ -687,7 +687,7 @@ $ git add DbConnector $ git commit -am 'Fast forwarded to a common submodule child' ---- -В этом случае выполняются те же вещи, что и в предыдущем, но так по завершению перемотки вы хотя бы сможете проверить, что все работает и вы получили правильный код в директории подмодуля. +В этом случае выполняются те же вещи, что и в предыдущем, но так по завершению перемотки вы хотя бы сможете проверить, что все работает и вы получили правильный код в каталоге подмодуля. ==== Полезные советы для работы с подмодулями @@ -784,7 +784,7 @@ $ git config alias.supdate 'submodule update --remote --merge' Однако, использование подмодулей не обходится без небольших проблем. Например, переключение веток при использовании подмодулей может оказаться довольно запутанным. -Если вы создадите новую ветку, добавите в ней подмодуль, а затем переключитесь обратно на ветку без подмодуля, то у вас все же останется директория подмодуля, как неотслеживаемая директория: +Если вы создадите новую ветку, добавите в ней подмодуль, а затем переключитесь обратно на ветку без подмодуля, то у вас все же останется каталог подмодуля, как неотслеживаемый каталог: [source,console] ---- @@ -817,8 +817,8 @@ Untracked files: nothing added to commit but untracked files present (use "git add" to track) ---- -Удалить директорию не сложно, но может показаться странным, что она вообще оказалась там. -Если вы удалите директорию и переключитесь на ветку с подмодулем, то вам потребуется выполнить `submodule update --init` для повторного создания директории. +Удалить каталог не сложно, но может показаться странным, что она вообще оказалась там. +Если вы удалите каталог и переключитесь на ветку с подмодулем, то вам потребуется выполнить `submodule update --init` для повторного создания каталога. [source,console] ---- @@ -839,10 +839,10 @@ Makefile includes scripts src И снова это, на самом деле, не сильно сложно, но может немного сбивать с толку. -Другая большая проблема возникает, когда люди переходят от использования поддиректорий к использованию подмодулей. +Другая большая проблема возникает, когда люди переходят от использования подкаталогов к использованию подмодулей. Если у вас были отслеживаемые файлы в вашем проекте и вы хотите переместить их в подмодуль, то вы должны быть осторожны, иначе Git будет ругаться на вас. -Предположим, у вас есть файлы в какой-то директории вашего проекта, и вы хотите переместить их в подмодуль. -Если вы удалите поддиректорию, а затем выполните `submodule add`, то Git заругается на вас: +Предположим, у вас есть файлы в каком-то каталоге вашего проекта и вы хотите переместить их в подмодуль. +Если вы удалите подкаталог, а затем выполните `submodule add`, то Git ругнётся на вас: [source,console] ---- @@ -851,7 +851,7 @@ $ git submodule add https://github.com/chaconinc/CryptoLibrary 'CryptoLibrary' already exists in the index ---- -Сначала, вы должны удалить директорию `CryptoLibrary` из индекса. +Сначала, вы должны удалить каталог `CryptoLibrary` из индекса. Затем вы можете добавить подмодуль: [source,console] @@ -889,10 +889,10 @@ warning: unable to rmdir CryptoLibrary: Directory not empty Switched to branch 'master' ---- -Когда в дальнейшем вы переключитесь обратно, то по некоторой причине получите пустую директорию `CryptoLibrary` и команда `git submodule update` не сможет этого исправить. -Вам может потребоваться перейти в директорию подмодуля и выполнить `git checkout .`, чтобы вернуть все ваши файлы. +Когда в дальнейшем вы переключитесь обратно, то по некоторой причине получите пустой каталог `CryptoLibrary` и команда `git submodule update` не сможет этого исправить. +Вам может потребоваться перейти в каталог подмодуля и выполнить `git checkout .`, чтобы вернуть все ваши файлы. Для того, чтобы запустить эту команду для нескольких подмодулей, вы можете выполнять её, используя `submodule foreach`. -Важно отметить, что подмодули в данный момент сохраняют все служебные данные в директории `.git` основного проекта, поэтому в отличие от более старых версии Git, удаление директории подмодуля не приведёт к потере каких-либо коммитов или веток, которые у вас были. +Важно отметить, что подмодули в данный момент сохраняют все служебные данные в каталоге `.git` основного проекта, поэтому, в отличие от более старых версии Git, удаление каталога подмодуля не приведёт к потере каких-либо коммитов или веток, которые у вас были. Все эти инструменты делают подмодули довольно простым и эффективным методом работы одновременно над несколькими связанными, но пока разделёнными проектами. diff --git a/book/07-git-tools/sections/subtree-merges.asc b/book/07-git-tools/sections/subtree-merges.asc index 373fa224..b2739e13 100644 --- a/book/07-git-tools/sections/subtree-merges.asc +++ b/book/07-git-tools/sections/subtree-merges.asc @@ -1,10 +1,10 @@ [[r_subtree_merge]] ===== Слияние субдеревьев -Идея слияния субдеревьев состоит в том, что у вас есть два проекта и один из проектов отображается в субдиректорию другого. +Идея слияния субдеревьев состоит в том, что у вас есть два проекта и один из проектов отображается в подкаталог другого. Когда вы выполняете слияние субдеревьев, Git в большинстве случаев способен понять, что одно из них является субдеревом другого и выполнить слияние подходящим способом. -Далее мы рассмотрим пример добавления в существующий проект другого проекта и последующее слияние кода второго проекта в субдиректорию первого. +Далее мы рассмотрим пример добавления в существующий проект другого проекта и последующее слияние кода второго проекта в подкаталог первого. Первым делом мы добавим в наш проект приложение Rack. Мы добавим Rack в наш собственный проект, как удалённый репозиторий, а затем выгрузим его в отдельную ветку. @@ -46,17 +46,17 @@ README Может показаться странным, но, на самом деле, ветки в вашем репозитории не обязаны быть ветками одного проекта. Это мало распространено, так как редко бывает полезным, но иметь ветки, имеющие абсолютно разные истории, довольно легко. -В данном примере, мы хотим выгрузить проект Rack в субдиректорию нашего основного проекта. +В данном примере, мы хотим выгрузить проект Rack в подкаталог нашего основного проекта. В Git мы можем выполнить это с помощью команды `git read-tree`. Вы узнаете больше о команде `read-tree` и её друзьях в <>, сейчас же вам достаточно знать, что она считывает содержимое некоторой ветки в ваш текущий индекс и рабочий каталог. -Мы просто переключимся обратно на ветку `master` и выгрузим ветку `rack` в субдиректорию `rack` ветки `master` нашего основного проекта: +Мы просто переключимся обратно на ветку `master` и выгрузим ветку `rack` в подкаталог `rack` ветки `master` нашего основного проекта: [source,console] ---- $ git read-tree --prefix=rack/ -u rack_branch ---- -Когда мы будем выполнять коммит, он будет выглядеть так, как будто все файлы проекта Rack были добавлены в эту субдиректорию -- например, мы скопировали их из архива. +Когда мы будем выполнять коммит, он будет выглядеть так, как будто все файлы проекта Rack были добавлены в этот подкаталог -- например, мы скопировали их из архива. Важно отметить, что слить изменения одной из веток в другую довольно легко. Таким образом, если проект Rack обновился, мы можем получить изменения из его репозитория просто переключившись на соответствующую ветку и выполнив операцию `git pull`: @@ -80,14 +80,14 @@ Automatic merge went well; stopped before committing as requested ---- Все изменения из проекта Rack слиты и подготовлены для локального выполнения коммита. -Вы также можете поступить наоборот -- сделать изменения в субдиректории `rack` вашей основной ветки и затем слить их в вашу ветку `rack_branch`, чтобы позже передать их ответственным за проекты или отправить их в вышестоящий репозиторий проекта Rack. +Вы также можете поступить наоборот -- сделать изменения в подкаталоге `rack` вашей основной ветки и затем слить их в вашу ветку `rack_branch`, чтобы позже передать их ответственным за проекты или отправить их в вышестоящий репозиторий проекта Rack. Таким образом, слияние субдеревьев даёт нам возможность использовать рабочий процесс в некоторой степени похожий на рабочий процесс с субмодулями, но при этом без использования субмодулей (которые мы рассмотрим в <>). Мы можем держать ветки с другими связанными проектами в нашем репозитории и периодически сливать их как субдеревья в наш проект. С одной стороны это удобно, например, тем, что весь код хранится в одном месте. Однако, при этом есть и некоторые недостатки -- субдеревья немного сложнее, проще допустить ошибки при повторной интеграции изменений или случайно отправить ветку не в тот репозиторий. -Другая небольшая странность состоит в том, что для получения различий между содержимым вашей субдиректории `rack` и содержимого ветки `rack_branch` -- для того, чтобы увидеть необходимо ли выполнять слияния между ними -- вы не можете использовать обычную команду `diff`. +Другая небольшая странность состоит в том, что для получения различий между содержимым вашего подкаталога `rack` и содержимого ветки `rack_branch` -- для того, чтобы увидеть, необходимо ли выполнять слияния между ними -- вы не можете использовать обычную команду `diff`. Вместо этого вы должны выполнить команду `git diff-tree`, указав ветку, с которой вы хотите выполнить сравнение: [source,console] @@ -95,7 +95,7 @@ Automatic merge went well; stopped before committing as requested $ git diff-tree -p rack_branch ---- -Для сравнения содержимого вашей субдиректории `rack` с тем, что находилось в ветке `master` сервера, когда вы последний раз извлекали из него изменения, вы можете выполнить: +Для сравнения содержимого вашего подкаталога `rack` с тем, что находилось в ветке `master` сервера, когда вы последний раз извлекали из него изменения, вы можете выполнить: [source,console] ---- From 2521ef638f9a5b7a37d5c3e49a3e05e84fd4f0f7 Mon Sep 17 00:00:00 2001 From: Dexter Morganov Date: Sun, 31 Jan 2021 19:12:53 +0300 Subject: [PATCH 08/12] =?UTF-8?q?=D0=9E=D0=B1=D0=BD=D0=BE=D0=B2=D0=BB?= =?UTF-8?q?=D1=91=D0=BD=20=D1=80=D0=B0=D0=B7=D0=B4=D0=B5=D0=BB=208?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../08-customizing-git/sections/attributes.asc | 16 ++++++++-------- book/08-customizing-git/sections/config.asc | 2 +- book/08-customizing-git/sections/hooks.asc | 12 ++++++------ book/08-customizing-git/sections/policy.asc | 18 +++++++++--------- 4 files changed, 24 insertions(+), 24 deletions(-) diff --git a/book/08-customizing-git/sections/attributes.asc b/book/08-customizing-git/sections/attributes.asc index fe71cb00..6f5694e0 100644 --- a/book/08-customizing-git/sections/attributes.asc +++ b/book/08-customizing-git/sections/attributes.asc @@ -1,10 +1,10 @@ === Атрибуты Git (((attributes))) -Некоторые из настроек могут быть применены к директории, поэтому Git применяет их только к поддиректориям или набору файлов. -Настройки, зависящие от пути, называются атрибутами и могут быть установлены либо в файле `.gitattributes` в любой из директорий проекта (обычно, в корневой директории), либо в файле `.git/info/attributes`, если вы не хотите хранить их в репозитории вместе с вашим проектом. +Некоторые из настроек могут быть применены к каталогу, поэтому Git применяет их только к подкаталогам или набору файлов. +Настройки, зависящие от пути, называются атрибутами и могут быть установлены либо в файле `.gitattributes` в любом из каталогов проекта (обычно, в корневом каталоге), либо в файле `.git/info/attributes`, если вы не хотите хранить их в репозитории вместе с вашим проектом. -Используя атрибуты, вы можете настраивать различные стратегии слияния для отдельных файлов или директорий вашего проекта, указать Git как сравнивать бинарные файлы, настраивать фильтры добавления или извлечения данных из репозитория. +Используя атрибуты, вы можете настраивать различные стратегии слияния для отдельных файлов или каталогов вашего проекта, указать Git как сравнивать бинарные файлы, настраивать фильтры добавления или извлечения данных из репозитория. В этом разделе вы узнаете о некоторых атрибутах, которые можно установить для заданных путей в вашем проекте и рассмотрите несколько практических примеров. ==== Бинарные файлы @@ -237,7 +237,7 @@ puts data.gsub('$Date$', '$Date: ' + last_date.to_s + '$') ---- Всё, что делает скрипт -- это получает дату последнего коммита с помощью команды `git log`, заменяет результатом все подстроки `$Date$` и возвращает итоговый результат; вы можете написать аналогичный скрипт на любом языке. -Назовите файл со скриптом, например, `expand_date` и сохраните в директории с программами. +Назовите файл со скриптом, например, `expand_date` и сохраните в каталоге с программами. Теперь, нужно настроить Git фильтр (назовите его `dater`) и укажите ему использовать ваш скрипт `expand_date` при извлечении файлов. Вместе с этим, мы будем использовать регулярное выражение Perl для очистки перед коммитом: @@ -283,10 +283,10 @@ $ cat date_test.txt ===== `export-ignore` -Вы можете указать Git игнорировать определённые файлы и директории при создании архива. -Если в вашем проекте есть файл или директория, которые вам нужны, но вы не хотите включать их в архив при экспорте, то можно присвоить им атрибут `export-ignore`. +Вы можете указать Git игнорировать определённые файлы и каталоги при создании архива. +Если в вашем проекте есть файл или каталог, которые вам нужны, но вы не хотите включать их в архив при экспорте, то можно присвоить им атрибут `export-ignore`. -Например, у вас есть несколько файлов в директории `test/` и совершенно нет смысла включать их в архив вашего проекта. +Например, у вас есть несколько файлов в каталоге `test/` и совершенно нет смысла включать их в архив вашего проекта. В этом случае достаточно добавить следующую строку в файл `.gitattributes`: [source,ini] @@ -294,7 +294,7 @@ $ cat date_test.txt test/ export-ignore ---- -Теперь, при создании архива проекта командой `git archive`, директория `test/` не будет включена в архив. +Теперь, при создании архива проекта командой `git archive`, каталог `test/` не будет включен в архив. ===== `export-subst` diff --git a/book/08-customizing-git/sections/config.asc b/book/08-customizing-git/sections/config.asc index 48764ca3..8591e82b 100644 --- a/book/08-customizing-git/sections/config.asc +++ b/book/08-customizing-git/sections/config.asc @@ -20,7 +20,7 @@ $ git config --global user.email johndoe@example.com Следующее место, куда смотрит Git -- это файл `~/.gitconfig` (или `~/.config/git/config`), который хранит настройки конкретного пользователя. Вы можете указать Git читать и писать в него, используя опцию `--global`. -Наконец, Git ищет параметры конфигурации в файле настроек в директории Git (`.git/config`) используемого в данный момент репозитория. +Наконец, Git ищет параметры конфигурации в файле настроек в каталоге Git (`.git/config`) текущего репозитория. Эти значения относятся только к текущему репозиторию и доступны при передаче параметра `--local` команде `git config`. (Если уровень настроек не указан явно, то подразумевается локальный.) diff --git a/book/08-customizing-git/sections/hooks.asc b/book/08-customizing-git/sections/hooks.asc index 81e89147..572dd0f1 100644 --- a/book/08-customizing-git/sections/hooks.asc +++ b/book/08-customizing-git/sections/hooks.asc @@ -9,13 +9,13 @@ ==== Установка хука -Хуки хранятся в поддиректории `hooks` относительно основной директории Git. +Хуки хранятся в подкаталоге `hooks` относительно основного каталога Git. Для большинства проектов это `.git/hooks`. -Когда вы инициализируете новый репозиторий командой `git init`, Git наполняет директорию `hooks` примерами скриптов, большинство из которых готовы к использованию, при этом каждый из них содержит документацию по используемым входным данным. +Когда вы инициализируете новый репозиторий командой `git init`, Git наполняет каталог `hooks` примерами скриптов, большинство из которых готовы к использованию, при этом каждый из них содержит документацию по используемым входным данным. Все примеры представлены в виде шелл скриптов, содержащими код на Perl, но вы можете использовать любой язык для написания скриптов -- главное правильно именовать исполняемые файлы. Если вы решите использовать какой-либо из предустановленных скриптов, то достаточно его просто переименовать, убрав суффикс `.sample`. -Для подключения собственного скрипта достаточно задать ему соответствующее имя, поместить в поддиректорию `hooks` основной директории Git и сделать его исполняемым. +Для подключения собственного скрипта достаточно задать ему соответствующее имя, поместить в подкаталог `hooks` основного каталога Git и сделать его исполняемым. Далее, мы рассмотрим наиболее часто используемые хуки. ==== Клиентские Хуки @@ -85,11 +85,11 @@ Git устанавливается с примером такого скрипт Его единственный аргумент -- команда, которая инициировала перезапись, а список перезаписанных изменений передаётся через `stdin`. Его применение практически аналогично хукам `post-checkout` и `post-merge`. -После успешного выполнения `git checkout` запускается хук `post-checkout`; его можно использовать для настройки рабочей директории в соответствии с требованиями проекта. -Например, перемещение в рабочую директорию больших бинарных файлов, которые не должны отслеживаться, автогенерация документации и тому подобное. +После успешного выполнения `git checkout` запускается хук `post-checkout`; его можно использовать для настройки рабочего каталога в соответствии с требованиями проекта. +Например, перемещение в рабочий каталог больших бинарных файлов, которые не должны отслеживаться, автогенерация документации и тому подобное. Хук `post-merge` запускается после успешного выполнения команды `merge`. -Его можно использовать для восстановления данных в рабочей директории, которые Git не может отслеживать, такие как права доступа. +Его можно использовать для восстановления данных в рабочем каталоге, которые Git не может отслеживать, такие как права доступа. Так же этот хук может проверять наличие внешних по отношению к Git файлов, которые вы захотите скопировать при внесении изменений. Хук `pre-push` выполняется во время работы команды `git push`: после обновления удалённых ссылок, но до непосредственной отправки данных. diff --git a/book/08-customizing-git/sections/policy.asc b/book/08-customizing-git/sections/policy.asc index dbc901e0..ac1382ad 100644 --- a/book/08-customizing-git/sections/policy.asc +++ b/book/08-customizing-git/sections/policy.asc @@ -2,7 +2,7 @@ === Пример принудительной политики Git (((policy example))) -В этом разделе вы сможете применить полученные знания для создания рабочего процесса Git, при котором будет проверяться формат сообщения коммита и определенным пользователям будет разрешено изменять содержимое заданных директорий проекта. +В этом разделе вы сможете применить полученные знания для создания рабочего процесса Git, при котором будет проверяться формат сообщения коммита и определенным пользователям будет разрешено изменять содержимое заданных каталогов проекта. Вы создадите клиентские скрипты, которые помогут разработчикам понять, когда их изменения будут отклонены, а также серверные скрипты, которые обеспечат выполнение заданных политик. Скрипты, которые будут приведены ниже, написаны на Ruby; отчасти по причине нашей интеллектуальной инерции, но также и потому, что Ruby легко читать, даже если вы не пишите на нём. @@ -10,7 +10,7 @@ ==== Серверный Хук -На стороне сервера вся работа производится в файле `update` из директории `hooks`. +На стороне сервера вся работа производится в файле `update` из каталога `hooks`. Хук `update` запускается однократно для каждой отправляемой ветки и принимает три параметра: * Ссылка на ветку, в которую производится отправка @@ -111,15 +111,15 @@ check_message_format ===== Контроль доступа по списку имён пользователей Предположим, вы хотите применить механизм контроля доступа на основе списков контроля доступа, позволяющий определенным пользователям вносить изменения в определенные части вашего проекта. -К примеру, некоторые пользователи имеют полный доступ, а другие могут изменять только определённые директории проекта или отдельные файлы. +К примеру, некоторые пользователи имеют полный доступ, а другие могут изменять только определённые каталоги проекта или отдельные файлы. Для реализации этого, следует записать эти правила в файл `acl`, находящийся в репозитории на сервере. Затем обновить хук `update`, чтобы он использовал эти правила при просмотре списка файлов в отправляемых коммитах для определения наличия прав доступа ко всем этим файлам у отправляющего пользователя. Первое, что надо сделать -- это создать список контроля доступа. -Здесь следует использовать формат, который очень похож на CVS и представляет собой список строк, в каждой из которых первое поле имеет значение `avail` или `unavail`, второе поле содержит список пользователей, разделённых запятой, а третье поле -- это путь к файлу или директории, для которого применяется это правило (пустое значение подразумевает отсутствие ограничения). +Здесь следует использовать формат, который очень похож на CVS и представляет собой список строк, в каждой из которых первое поле имеет значение `avail` или `unavail`, второе поле содержит список пользователей, разделённых запятой, а третье поле -- это путь к файлу или каталогу, для которого применяется это правило (пустое значение подразумевает отсутствие ограничения). В качестве разделителя для этих полей применяется вертикальная черта (`|`). -В случае, когда у вас есть группа администраторов, несколько технических писателей с доступом к директории `doc` и один разработчик, у которого есть доступ только к директориям `lib` и `tests`, файл со списком контроля доступа будет выглядеть так: +В случае, когда у вас есть группа администраторов, несколько технических писателей с доступом к каталогу `doc` и один разработчик, у которого есть доступ только к каталогам `lib` и `tests`, файл со списком контроля доступа будет выглядеть так: [source] ---- @@ -270,7 +270,7 @@ error: failed to push some refs to 'git@gitserver:project.git' Здесь можно увидеть сообщение об отказе для каждой из веток, которые отклонил ваш хук, при этом будет явно указано, что именно он является причиной отказа. Более того, если кто-то отредактирует файл, на изменение которого у него нет прав, и попытается отправить содержащий это изменение коммит, то получит аналогичное сообщение. -Например, если технический писатель попытается отправить коммит, содержащий изменения в директории `lib`, то он увидит следующее: +Например, если технический писатель попытается отправить коммит, содержащий изменения в каталоге `lib`, то он увидит следующее: [source] ---- @@ -286,7 +286,7 @@ error: failed to push some refs to 'git@gitserver:project.git' Решением в данной ситуации является предоставление клиентских хуков, которые пользователи могут использовать для получения уведомлений, когда они делают то, что сервер скорее всего отклонит. Таким образом они могут исправить любые проблемы до создания коммита и до того, как исправление проблемы станет гораздо сложнее. -Так как хуки не копируются при клонировании репозитория, вам следует распространять их каким-то другим способом, а ваши пользователи должны будут их скопировать в директорию `.git/hooks` и сделать исполняемыми. +Так как хуки не копируются при клонировании репозитория, вам следует распространять их каким-то другим способом, а ваши пользователи должны будут их скопировать в каталог `.git/hooks` и сделать исполняемыми. Вы можете хранить эти хуки внутри проекта или в отдельном проекте -- в любом случае Git не установит их автоматически. Для начала, необходимо проверять сообщение коммита непосредственно перед его созданием, так вы будете уверены, что сервер не отклонит ваши изменения из-за плохо оформленных сообщений. @@ -326,7 +326,7 @@ $ git commit -am 'Test [ref: 132]' ---- Далее, следует убедиться, что внесенные изменения соответствуют вашим правам доступа. -Если в директории `.git` содержится файл списка контроля доступа, который использовался ранее, то следующий `pre-commit` скрипт поможет вам реализовать такую проверку: +Если в каталоге `.git` содержится файл списка контроля доступа, который использовался ранее, то следующий `pre-commit` скрипт поможет вам реализовать такую проверку: [source,ruby] ---- @@ -359,7 +359,7 @@ check_directory_perms ---- Этот скрипт практически такой же как и серверный, за исключением двух важных отличий. -Во первых, файл списка контроля доступа находится в другом месте, так как скрипт запускается из рабочей директории, а не из директории `.git`. +Во первых, файл списка контроля доступа находится в другом месте, так как скрипт запускается из рабочего каталога, а не из каталога `.git`. Поэтому необходимо изменить путь к файлу с: [source,ruby] From 84355dc363096d4b931b0355f87ab6669dcc96a0 Mon Sep 17 00:00:00 2001 From: Dexter Morganov Date: Sun, 31 Jan 2021 19:29:16 +0300 Subject: [PATCH 09/12] =?UTF-8?q?=D0=9E=D0=B1=D0=BD=D0=BE=D0=B2=D0=BB?= =?UTF-8?q?=D1=91=D0=BD=20=D1=80=D0=B0=D0=B7=D0=B4=D0=B5=D0=BB=209?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../sections/client-bzr.asc | 2 +- .../sections/client-hg.asc | 6 ++-- .../sections/client-p4.asc | 10 +++--- .../sections/client-svn.asc | 8 ++--- .../sections/import-bzr.asc | 8 ++--- .../sections/import-custom.asc | 32 +++++++++---------- .../sections/import-p4.asc | 4 +-- .../sections/import-svn.asc | 2 +- 8 files changed, 36 insertions(+), 36 deletions(-) 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 1936fad3..bf97da3e 100644 --- a/book/09-git-and-other-scms/sections/client-bzr.asc +++ b/book/09-git-and-other-scms/sections/client-bzr.asc @@ -9,7 +9,7 @@ Bazaar -- это бесплатная система с открытым исх Существует много проектов, которые позволяют использовать Git как клиент Bazaar. Далее, мы будем использовать проект Филипа Контрераса, который можно найти здесь https://github.com/felipec/git-remote-bzr[]. -Для установки достаточно просто скачать файл git-remote-bzr и поместить его в одну из директорий в вашем `$PATH`: +Для установки достаточно просто скачать файл git-remote-bzr и поместить его в один из каталогов вашего `$PATH`: [source,console] ---- 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 993346e4..50d89823 100644 --- a/book/09-git-and-other-scms/sections/client-hg.asc +++ b/book/09-git-and-other-scms/sections/client-hg.asc @@ -67,7 +67,7 @@ $ git log --oneline --graph --decorate `git log` показывает два коммита, на последний из которых указывает довольно много ссылок. На самом деле, не все из них реально существуют. -Давайте-ка посмотрим, что хранится внутри директории `.git`: +Давайте-ка посмотрим, что хранится внутри каталога `.git`: [source,console] ---- @@ -92,9 +92,9 @@ $ tree .git/refs ---- `git-remote-hg` пытается нивелировать различия между Git и Mercurial, преобразовывая форматы за кулисами. -Ссылки на объекты в удалённом репозитории хранятся в директории `refs/hg`. +Ссылки на объекты в удалённом репозитории хранятся в каталоге `refs/hg`. Например, `refs/hg/origin/branches/default` -- это Git-ссылка, содержащая SHA-1 `ac7955c` -- коммит на который ссылается ветка `master`. -Таким образом, директория `refs/hg` -- это что-то типа `refs/remotes/origin`, с той разницей что здесь же отдельно хранятся Mercurial-закладки и ветки. +Таким образом, каталог `refs/hg` -- это что-то типа `refs/remotes/origin`, с той разницей, что здесь же отдельно хранятся закладки и ветки Mercurial. Файл `notes/hg` -- отправная точка для выяснения соответствия между хешами коммитов в Git и идентификаторами ревизий в Mercurial. Давайте посмотрим что там: 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 6843a410..2f51ee95 100644 --- a/book/09-git-and-other-scms/sections/client-p4.asc +++ b/book/09-git-and-other-scms/sections/client-p4.asc @@ -75,7 +75,7 @@ Checking connectivity... done. ====== Настройка Fusion После установки Git Fusion вы, возможно, захотите настроить его. -Это относительно несложно сделать, используя ваш любимый Perforce клиент; просто отобразите директорию `//.git-fusion` на Perforce сервере в ваше рабочее пространство. +Это относительно несложно сделать, используя ваш любимый Perforce клиент; просто отобразите каталог `//.git-fusion` на Perforce сервере в ваше рабочее пространство. Структура файлов приведена ниже: [source,console] @@ -98,7 +98,7 @@ $ tree 498 directories, 287 files ---- -Директория `objects` используется Git Fusion для отображения объектов Perforce в Git и наоборот, вам не следует ничего здесь трогать. +Каталог `objects` используется Git Fusion для отображения объектов Perforce в Git и наоборот, вам не следует ничего здесь трогать. Внутри расположен глобальный конфигурационный файл `p4gf_config`, а также по одному такому же файлу для каждого репозитория -- эти файлы и определяют поведение Git Fusion. Заглянем в тот, что в корне: @@ -158,7 +158,7 @@ view = //depot/project1/main/... project1/... //depot/project2/mainline/... project2/... ---- -Таким образом, если ваше отображение включает изменения в структуре директорий, вы можете реплицировать эти изменения здесь. +Таким образом, если ваше отображение включает изменения в структуре каталогов, вы можете реплицировать эти изменения здесь. Последний файл, который мы обсудим, это `users/p4gf_usermap`; в нём задаётся отображение пользователей Perforce на пользователей Git. Возможно, вам не пригодится этот файл. @@ -296,12 +296,12 @@ To https://10.0.1.254/Jam image::images/git-fusion-perforce-graph.png["Граф ревизий Perforce после отправки данных из Git"] Если вы ни разу не работали с Perforce это окно может показаться вам запутанным, но его концепция аналогичная `gitk`. -Мы просматриваем историю файла `README`, так что дерево с директориями слева вверху показывает этот файл в разных ветках. +Мы просматриваем историю файла `README`, так что дерево каталогов слева вверху показывает этот файл в разных ветках. Справа вверху мы видим граф зависимости разных ревизий файла, справа внизу этот же граф показан целиком для быстрого ориентирования. Оставшаяся часть окна отображает детали выбранной ревизии (в нашем случае это ревизия `2`). Граф выглядит в точности как в Git. -У Perforce не было именованной ветки для сохранения коммитов `1` и `2`, так что он создал «анонимную» ветку в директории `.git-fusion`. +У Perforce не было именованной ветки для сохранения коммитов `1` и `2`, так что он создал «анонимную» ветку в каталоге `.git-fusion`. Git Fusion поступит так же для именованных Git веток не соответствующих веткам в Perforce, но вы можете задать соответствие в конфигурационном файле. Большинство происходящей магии скрыто от посторонних глаз, а в результате кто-то в команде может использовать Git, кто-то -- Perforce и никто не будет подозревать о выборе других. 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 0219c1ab..b3402b9f 100644 --- a/book/09-git-and-other-scms/sections/client-svn.asc +++ b/book/09-git-and-other-scms/sections/client-svn.asc @@ -108,9 +108,9 @@ Checked out HEAD: Тестовый проект невелик -- всего 75 коммитов -- но Git вынужден последовательно скачивать SVN ревизии и превращать их в Git коммиты по одной за раз. Для проекта с сотней или тысячей ревизий это может занять часы или даже дни! -Параметры `-T trunk -b branches -t tags` говорят Git о том, что клонируемый репозиторий следует стандартному, принятому в Subversion, расположению директорий с транком, ветками и метками. -Если же директории названы по-другому, можно указать их явно, используя эти параметры. -Большинство Subversion репозиториев следуют этому соглашению, поэтому для этой комбинации параметров существует сокращение `-s`, что означает «стандартное расположение директорий» +Параметры `-T trunk -b branches -t tags` говорят Git о том, что клонируемый репозиторий следует стандартному, принятому в Subversion, расположению каталогов с транком, ветками и метками. +Если же каталоги названы по-другому, можно указать их явно, используя эти параметры. +Большинство Subversion репозиториев следуют этому соглашению, поэтому для этой комбинации параметров существует сокращение `-s`, что означает «стандартное расположение каталогов» Следующая команда эквивалентна приведённой выше: [source,console] @@ -304,7 +304,7 @@ Fast-forwarded master to refs/remotes/origin/trunk. ---- Выполнение `git svn rebase` актуализирует состояние локального репозитория. -Для выполнения этой команды ваша рабочая директория не должна содержать незафиксированных изменений. +Для выполнения этой команды ваш рабочий каталог не должен содержать незафиксированных изменений. Если это не так, вам следует либо «припрятать» (stash) свои наработки, либо на время зафиксировать: иначе `git svn rebase` прекратит выполнение в случае конфликта. ===== Проблемы с Git-ветвлением 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 9475d269..0c706ef1 100644 --- a/book/09-git-and-other-scms/sections/import-bzr.asc +++ b/book/09-git-and-other-scms/sections/import-bzr.asc @@ -34,7 +34,7 @@ $ sudo dnf install bzr-fastimport [source,console] ---- -$ mkdir --parents ~/.bazaar/plugins # создаст необходимые директории для плагинов +$ mkdir --parents ~/.bazaar/plugins # создаст необходимые каталоги для плагинов $ cd ~/.bazaar/plugins $ bzr branch lp:bzr-fastimport fastimport # импортирует плагин fastimport $ cd fastimport @@ -62,7 +62,7 @@ $ pip install fastimport ===== Проект с одной веткой -Войдите в директорию, содержащую ваш Bazaar репозиторий и проинициализируйте Git репозиторий: +Войдите в каталог, содержащий ваш Bazaar репозиторий и проинициализируйте Git репозиторий: [source,console] ---- @@ -90,7 +90,7 @@ $ ls myProject.trunk myProject.work ---- -Проинициализируйте Git репозиторий и войдите в его директорию: +Проинициализируйте Git репозиторий и перейдите в его каталог: [source,console] ---- @@ -119,7 +119,7 @@ git fast-import --import-marks=../marks.git --export-marks=../marks.git ===== Синхронизация индекса -Вне зависимости от количества веток и выбранного метода импорта, индекс не синхронизируется с `HEAD`, а при импорте нескольких веток -- так же не синхронизируется рабочая директория. +Вне зависимости от количества веток и выбранного метода импорта, индекс не синхронизируется с `HEAD`, а при импорте нескольких веток -- так же не синхронизируется рабочий каталог. Эту ситуацию можно легко исправить следующей командой: [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 bc607310..50f616c4 100644 --- a/book/09-git-and-other-scms/sections/import-custom.asc +++ b/book/09-git-and-other-scms/sections/import-custom.asc @@ -3,7 +3,7 @@ (((git commands, fast-import))) (((Importing, from others))) -Если вы пользуетесь какой-либо другой системой контроля версий, не перечисленной выше, вам следует поискать инструмент для импорта в Сети -- качественные решения доступны для CVS, Clear Case, Visual Source Safe и даже директорий с архивами. +Если вы пользуетесь какой-либо другой системой контроля версий, не перечисленной выше, вам следует поискать инструмент для импорта в Сети -- качественные решения доступны для CVS, Clear Case, Visual Source Safe и даже каталогов с архивами. Если всё же существующие решения вам не подошли, вы пользуетесь менее известной СКВ или вам нужно больше контроля над процессом импорта -- используйте `git fast-import`. Эта команда читает простые инструкции из потока ввода и записывает данные в Git. Создать Git-объекты таким путём намного проще, чем через низкоуровневые Git-команды или пытаясь воссоздать их вручную (обратитесь к <> за деталями). @@ -11,8 +11,8 @@ Затем вы можете запустить эту программу и передать её вывод прямиком в `git fast-import`. Для демонстрации, мы с вами напишем простой скрипт для импорта. -Предположим, вы работаете в директории `current` и периодически создаёте резервные копии в директориях вида `back_YYYY_MM_DD`, и хотите перенести данные в Git. -Структура директорий выглядит подобным образом: +Предположим, вы работаете в каталоге `current` и периодически создаёте резервные копии в каталогах вида `back_YYYY_MM_DD`, и хотите перенести данные в Git. +Структура каталогов выглядит следующим образом: [source,console] ---- @@ -34,7 +34,7 @@ current Если вы работаете на Windows, будьте особо осторожными с переводами строк: `fast-import` ожидает лишь символы перевода строки (`LF`), но не возврат каретки + перевод строки (`CRLF`), как принято в Windows. -Для начала зайдём в исходную директорию и определим поддиректории, содержащие состояния проекта в разные моменты времени, которые будут использованы для построения соответствующих коммитов. +Для начала перейдём в исходный каталог и определим подкаталоги, содержащие состояния проекта в разные моменты времени, которые будут использованы для построения соответствующих коммитов. Вы поочерёдно посетите каждую из них и выполните команды, необходимые для экспорта. Примерно так: @@ -55,17 +55,17 @@ Dir.chdir(ARGV[0]) do end ---- -Вы выполняете функцию `print_export` внутри каждой директории. -Она принимает на вход текущую директорию и результат предыдущего вызова и помечает текущую директорию, возвращая данные для последующих вызовов; таким образом связывая коммиты. -Пометки используются для связи коммитов вместе. -Итак, первым делом нужно сгенерировать метку по директории: +Вы выполняете функцию `print_export` внутри каждого каталога. +Она принимает на вход текущий каталог и результат предыдущего вызова и помечает текущий каталог, возвращая данные для последующих вызовов, таким образом связывая коммиты. +Метки используются для связи коммитов вместе. +Итак, первым делом нужно сгенерировать метку по каталогу: [source,ruby] ---- mark = convert_dir_to_mark(dir) ---- -Создадим массив директорий и используем индекс директории в нём как метку; это удобно, ведь метка должна быть целым числом. +Создадим массив каталогов и используем индекс каталога в нём как метку; это удобно, ведь метка должна быть целым числом. Мы написали такой код: [source,ruby] @@ -80,7 +80,7 @@ end ---- Теперь, когда у нас есть целочисленная метка для коммита, нужна дата. -У нас она хранится в имени директории, придётся достать её оттуда. +У нас она хранится в имени каталога, придётся достать её оттуда. Следующая строка в `print_export`: [source,ruby] @@ -103,7 +103,7 @@ def convert_dir_to_date(dir) end ---- -Этот код вернёт целочисленное представление даты для каждой директории. +Этот код вернёт целочисленное представление даты для каждого каталога. И последний кусочек мозаики: автор изменений. Это значение жёстко задано в глобальной переменной: @@ -146,7 +146,7 @@ end ---- Осталось лишь задать содержимое каждого коммита. -Это довольно просто, потому что все данные хранятся в отдельных директориях -- достаточно напечатать команду `deleteall` и содержимое всех файлов в директории. +Это довольно просто, потому что все данные хранятся в отдельных каталогах -- достаточно напечатать команду `deleteall`, а следом за ней содержимое всех файлов каталога. После этого Git запишет слепки: [source,ruby] @@ -309,8 +309,8 @@ M 644 inline README.md (...) ---- -Чтобы импортировать репозиторий перенаправьте этот вывод в команду `git fast-import`, запущенную в директории с целевым Git-репозиторием. -Вы можете создать новую директорию, выполнить в ней `git init`, а затем запустить свой скрипт: +Чтобы импортировать репозиторий перенаправьте этот вывод в команду `git fast-import`, запущенную в каталоге с целевым Git-репозиторием. +Вы можете создать новый каталог, выполнить в нём `git init`, а затем запустить свой скрипт: [source,console] ---- @@ -363,7 +363,7 @@ Date: Mon Feb 3 01:00:00 2014 -0700 ---- Вот он: ваш новый классный Git репозиторий! -Обратите внимание, ваша рабочая директория пуста, активная ветка не выбрана. +Обратите внимание, ваш рабочий каталог пуст, активная ветка не выбрана. Переключимся на ветку `master`: [source,console] @@ -376,4 +376,4 @@ README.md main.rb ---- Функциональность `fast-import` гораздо шире описанного: он поддерживает права доступа к файлам, двоичные файлы, множественные ветки и их слияния, метки, индикатор прогресса и ещё кучу вещей. -Несколько примеров более сложных сценариев использования `fast-import` можно найти в директории `contrib/fast-import` исходного кода Git. +Несколько примеров более сложных сценариев использования `fast-import` можно найти в каталоге `contrib/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 c7a029f7..ce6fa974 100644 --- a/book/09-git-and-other-scms/sections/import-p4.asc +++ b/book/09-git-and-other-scms/sections/import-p4.asc @@ -32,7 +32,7 @@ $ export P4PORT=public.perforce.com:1666 ==== (((git commands, p4))) -Запустите команду `git p4 clone` чтобы импортировать проект «Jam» с Perforce сервера, передав ей путь к проекту в депо и директорию, в которую хотите импортировать репозиторий: +Запустите команду `git p4 clone` чтобы импортировать проект «Jam» с Perforce сервера, передав ей путь к проекту в депо и каталог, в который хотите импортировать репозиторий: [source,console] ---- @@ -47,7 +47,7 @@ Importing revision 9957 (100%) Перечитайте раздел <> для подробностей. На данном этапе репозиторий почти готов. -Если вы зайдёте в директорию `p4import` и выполните `git log`, вы увидите результат: +Если вы перейдёте в каталог `p4import` и выполните `git log`, вы увидите результат: [source,console] ---- diff --git a/book/09-git-and-other-scms/sections/import-svn.asc b/book/09-git-and-other-scms/sections/import-svn.asc index c475a7ee..e6ea2a6a 100644 --- a/book/09-git-and-other-scms/sections/import-svn.asc +++ b/book/09-git-and-other-scms/sections/import-svn.asc @@ -56,7 +56,7 @@ $ git svn clone http://my-project.googlecode.com/svn/ \ $ cd my_project ---- -Теперь у вас будет красивая копия Subversion репозитория в директории `my_project`. +Теперь у вас будет красивая копия репозитория Subversion в каталоге `my_project`. Вместо коммитов типа [source] From 24d95e97271ed089a8d1d608991992a0c7d77191 Mon Sep 17 00:00:00 2001 From: Dexter Morganov Date: Sun, 31 Jan 2021 19:37:14 +0300 Subject: [PATCH 10/12] =?UTF-8?q?=D0=9E=D0=B1=D0=BD=D0=BE=D0=B2=D0=BB?= =?UTF-8?q?=D0=B5=D0=BD=D0=BE=20=D0=BF=D1=80=D0=B8=D0=BB=D0=BE=D0=B6=D0=B5?= =?UTF-8?q?=D0=BD=D0=B8=D0=B5=20=D0=90?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- book/A-git-in-other-environments/sections/bash.asc | 12 ++++++------ book/A-git-in-other-environments/sections/guis.asc | 8 ++++---- .../sections/powershell.asc | 2 +- .../sections/sublimetext.asc | 4 ++-- .../sections/visualstudio.asc | 2 +- 5 files changed, 14 insertions(+), 14 deletions(-) diff --git a/book/A-git-in-other-environments/sections/bash.asc b/book/A-git-in-other-environments/sections/bash.asc index cf180b24..468a945d 100644 --- a/book/A-git-in-other-environments/sections/bash.asc +++ b/book/A-git-in-other-environments/sections/bash.asc @@ -5,14 +5,14 @@ К слову, Git поставляется с плагинами для нескольких командных оболочек, но они выключены по умолчанию. Для начала, скачайте файл `contrib/completion/git-completion.bash` из репозитория с исходным кодом Git. -Поместите его в укромное место -- например, в вашу домашнюю директорию -- и добавьте следующие строки в `.bashrc`: +Поместите его в укромное место -- например, в ваш домашний каталог -- и добавьте следующие строки в `.bashrc`: [source,console] ----- . ~/git-completion.bash ----- -Как только закончите с этим, перейдите в директорию с Git репозиторием и наберите: +Как только закончите с этим, перейдите в каталог с Git репозиторием и наберите: [source,console] ---- @@ -22,8 +22,8 @@ $ git chec …и Bash дополнит строку до `git checkout`. Эта магия работает для всех Git команд, их параметров, удалённых репозиториев и имён ссылок там, где это возможно. -Возможно, вам также пригодится отображение информации о репозитории, расположенном в текущей директории. -Вы можете выводить сколь угодно сложную информацию, но обычно достаточно названия текущей ветки и статуса рабочей директории. +Возможно, вам также пригодится отображение информации о репозитории, расположенном в текущем каталоге. +Вы можете выводить сколь угодно сложную информацию, но обычно достаточно названия текущей ветки и статуса рабочего каталога. Чтобы снабдить строку приветствия этой информацией, скачайте файл `contrib/completion/git-prompt.sh` из репозитория с исходным кодом Git и добавьте примерно такие строки в `.bashrc`: [source,console] @@ -33,8 +33,8 @@ export GIT_PS1_SHOWDIRTYSTATE=1 export PS1='\w$(__git_ps1 " (%s)")\$ ' ----- -Часть `\w` означает текущую рабочую директорию, `\$` -- индикатор суперпользователя (обычно `$` или `#`), а `__git_ps1 " (%s)"` вызывает функцию, объявленную в `git-prompt.sh`, с аргументом ` (%s)` -- строкой форматирования. -Теперь ваша строка приветствия будет похожа на эту, когда вы зайдёте в директорию с Git репозиторием: +Часть `\w` означает текущий рабочий каталог, `\$` -- индикатор суперпользователя (обычно `$` или `#`), а `__git_ps1 " (%s)"` вызывает функцию, объявленную в `git-prompt.sh`, с аргументом ` (%s)` -- строкой форматирования. +Теперь ваша строка приветствия будет похожа на эту, когда вы перейдёте в каталог с Git репозиторием: .Кастомизированная строка приветствия `bash` image::images/git-bash.png["Кастомизированная строка приветствия `bash`"] diff --git a/book/A-git-in-other-environments/sections/guis.asc b/book/A-git-in-other-environments/sections/guis.asc index f33c02d9..bf6af2b0 100644 --- a/book/A-git-in-other-environments/sections/guis.asc +++ b/book/A-git-in-other-environments/sections/guis.asc @@ -20,7 +20,7 @@ Это тот инструмент, который вы будете использовать для поиска событий или визуализации истории. Проще всего вызвать Gitk из командной строки: -Просто перейдите в директорию с репозиторием и наберите: +Просто перейдите в каталог с репозиторием и наберите: [source,console] ---- @@ -52,7 +52,7 @@ $ git gui .`git gui` -- инструмент редактирования коммитов image::images/git-gui.png["`git gui` -- инструмент редактирования коммитов"] -Слева находится область редактирования Git индекса: изменения в рабочей директории наверху, добавленные в индекс изменения -- снизу. +Слева находится область редактирования Git индекса: изменения в рабочем каталоге наверху, добавленные в индекс изменения -- снизу. Вы можете перемещать файлы целиком между двумя состояниями, кликая на иконки, или же вы можете просмотреть изменения в конкретном файле, кликнув по нему. Справа вверху расположена область просмотра изменений выделенного файла. @@ -85,7 +85,7 @@ image::images/github_win.png["GitHub для Windows"] * Слева расположен список отслеживаемых репозиториев; можно добавить репозиторий (клонировав его, либо указав путь к существующей копии) нажатием кнопки `+` над списком. * В центре экрана расположена область редактирования коммита: тут можно ввести сообщение коммита и выбрать файлы для включение в него. (На Windows, история коммитов расположена под этой областью, на Mac это отдельная вкладка.) -* Справа -- просмотр изменений: что изменилось в рабочей директории, какие изменения войдут в коммит. +* Справа -- просмотр изменений: что изменилось в рабочем каталоге, какие изменения войдут в коммит. * И стоит обратить внимание на кнопку «Sync» справа вверху, которая используется для синхронизации по сети. [NOTE] @@ -125,7 +125,7 @@ image::images/branch_widget_mac.png["Кнопка создания ветки н image::images/branch_widget_win.png["Создание ветки в Windows"] После создания ветки добавление коммитов в неё довольно тривиально. -Измените что-нибудь в рабочей директории и, переключившись в окно клиента GitHub, вы увидите свои изменения. +Измените что-нибудь в рабочем каталоге и, переключившись в окно клиента GitHub, вы увидите свои изменения. Введите сообщение коммита, выберете файлы для включения в коммит и нажмите кнопку «Commit» (ctrl-enter или ⌘-enter). Взаимодействие с удалёнными репозиториями происходит в первую очередь посредством кнопки «Sync». diff --git a/book/A-git-in-other-environments/sections/powershell.asc b/book/A-git-in-other-environments/sections/powershell.asc index 8853bd16..142c075f 100644 --- a/book/A-git-in-other-environments/sections/powershell.asc +++ b/book/A-git-in-other-environments/sections/powershell.asc @@ -72,7 +72,7 @@ image::images/posh-git.png["Powershell с Posh-git"] [source,powershell] ---- -> Import-Module <путь-к-распакованной-директории>\src\posh-git.psd1 +> Import-Module <путь-к-распакованному-каталогу>\src\posh-git.psd1 > Add-PoshGitToProfile -AllHosts ---- diff --git a/book/A-git-in-other-environments/sections/sublimetext.asc b/book/A-git-in-other-environments/sections/sublimetext.asc index 056297bc..123e0a93 100644 --- a/book/A-git-in-other-environments/sections/sublimetext.asc +++ b/book/A-git-in-other-environments/sections/sublimetext.asc @@ -4,8 +4,8 @@ Основные особенности: -* На боковой панели git статус файлов и директорий помечается бэйджем/иконкой. -* Файлы и директории, указанные в .gitignore не отображаются на боковой панели. +* На боковой панели git статус файлов и каталогов помечается бэйджем/иконкой. +* Файлы и каталоги, указанные в .gitignore не отображаются на боковой панели. * В строке состояния отображается текущая ветка и количество внесенных изменений. * Измененные строки помечаются маркерами в канавке с нумерацией. * Можно использовать некоторые функции git клиента Sublime Merge непосредственно из Sublime Text. diff --git a/book/A-git-in-other-environments/sections/visualstudio.asc b/book/A-git-in-other-environments/sections/visualstudio.asc index cf45a361..698980f5 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» («Добавить») и укажите путь к рабочей директории. +Если в списке нет проекта, который вам нужен, нажмите кнопку «Add» («Добавить») и укажите путь к рабочему каталогу. Двойной клик по одному из локальных Git-репозиториев откроет главную страницу репозитория, которая выглядит примерно так <>. Это центр управления Git; когда вы _пишете_ код, вы, вероятно, проводите большую часть своего времени на странице «Changes» («Изменения»), но когда приходит время получать изменения, сделанные вашими коллегами по работе, вам необходимо использовать страницы «Unsynced Commits» («Несинхронизированные коммиты») и «Branches» («Ветки»). From c4ad344fb647ceb121e4d1903b4fc9856ca96df3 Mon Sep 17 00:00:00 2001 From: Dexter Morganov Date: Sun, 31 Jan 2021 19:39:11 +0300 Subject: [PATCH 11/12] =?UTF-8?q?=D0=9E=D0=B1=D0=BD=D0=BE=D0=B2=D0=BB?= =?UTF-8?q?=D0=B5=D0=BD=D0=BE=20=D0=BF=D1=80=D0=B8=D0=BB=D0=BE=D0=B6=D0=B5?= =?UTF-8?q?=D0=BD=D0=B8=D0=B5=20B?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- book/B-embedding-git/sections/jgit.asc | 4 ++-- book/B-embedding-git/sections/libgit2.asc | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/book/B-embedding-git/sections/jgit.asc b/book/B-embedding-git/sections/jgit.asc index b2f5c5ab..f3709bf1 100644 --- a/book/B-embedding-git/sections/jgit.asc +++ b/book/B-embedding-git/sections/jgit.asc @@ -41,7 +41,7 @@ java -cp .:org.eclipse.jgit-3.5.0.201409260305-r.jar App [source,java] ---- -// Создание нового репозитория; директория должна существовать +// Создание нового репозитория; каталог должен существовать Repository newlyCreatedRepo = FileRepositoryBuilder.create( new File("/tmp/new_repo/.git")); newlyCreatedRepo.create(); @@ -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 c901f7fd..1ef6cea6 100644 --- a/book/B-embedding-git/sections/libgit2.asc +++ b/book/B-embedding-git/sections/libgit2.asc @@ -32,7 +32,7 @@ git_repository_free(repo); Первая пара строк открывают Git репозиторий. Тип `git_repository` представляет собой ссылку на репозиторий с кешем в памяти. -Это самый простой метод, его можно использовать если вы знаете точный путь к рабочей директории репозитория или к `.git` директории. +Это самый простой метод, его можно использовать если вы знаете точный путь к рабочему каталогу репозитория или к каталогу `.git`. Кроме этого, существуют методы `git_repository_open_ext`, который принимает набор параметров для поиска репозитория, `git_clone` и сопуствующие -- для создания локальной копии удалённого репозитория и `git_repository_init` -- для создания нового репозитория с нуля. Следующий блок кода использует `rev-parse` синтаксис (см. <>), чтобы получить коммит, на который указывает HEAD. From 4fcfe12491ee2e41b8ab53921bcbcac34d6912c7 Mon Sep 17 00:00:00 2001 From: Dexter Morganov Date: Sat, 13 Feb 2021 12:56:47 +0300 Subject: [PATCH 12/12] =?UTF-8?q?=D0=9E=D0=B1=D0=BD=D0=BE=D0=B2=D0=BB?= =?UTF-8?q?=D1=91=D0=BD=20=D1=80=D0=B0=D0=B7=D0=B4=D0=B5=D0=BB=2010?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../10-git-internals/sections/environment.asc | 16 ++++----- .../10-git-internals/sections/maintenance.asc | 8 ++--- book/10-git-internals/sections/objects.asc | 34 +++++++++---------- book/10-git-internals/sections/packfiles.asc | 2 +- .../sections/plumbing-porcelain.asc | 14 ++++---- book/10-git-internals/sections/refs.asc | 10 +++--- book/10-git-internals/sections/refspec.asc | 2 +- .../sections/transfer-protocols.asc | 2 +- 8 files changed, 44 insertions(+), 44 deletions(-) diff --git a/book/10-git-internals/sections/environment.asc b/book/10-git-internals/sections/environment.asc index 019331d4..677287f5 100644 --- a/book/10-git-internals/sections/environment.asc +++ b/book/10-git-internals/sections/environment.asc @@ -32,20 +32,20 @@ Git всегда запускается в оболочке `bash` и испол Git использует некоторые переменные окружения, чтобы определить как взаимодействовать с текущим репозиторием. -*`GIT_DIR`* -- это месторасположение директории `.git`. -Если эта переменная не задана, Git будет переходить вверх по дереву директорий, пока не достигнет `~` (домашней директории пользователя) или `/` (корневой директории), проверяя на каждом шагу наличие директории `.git`. +*`GIT_DIR`* -- это месторасположение каталога `.git`. +Если эта переменная не задана, Git будет переходить вверх по дереву каталогов, пока не достигнет `~` (домашнего каталога пользователя) или `/` (корневого каталога), проверяя на каждом шагу наличие каталога `.git`. -*`GIT_CEILING_DIRECTORIES`* управляет процессом поиска директории `.git`. +*`GIT_CEILING_DIRECTORIES`* управляет процессом поиска каталога `.git`. Если вы работаете с медленной файловой системой (типа ленточного накопителя или сетевой папки), вы можете запретить Git доступ к `.git` без надобности, например, для построения строки приветствия. -*`GIT_WORK_TREE`* -- это путь к корневой рабочей директории для не-серверного репозитория (с непустой рабочей директорией). -Если задана `GIT_DIR` или указан параметр `--git-dir`, но ничего из `--work-tree`, `GIT_WORK_TREE` или `core.worktree` не задано, то текущая директория будет считаться корневой. +*`GIT_WORK_TREE`* -- это путь к корневому рабочему каталогу для не-серверного репозитория (с непустым рабочим каталогом). +Если задана `GIT_DIR` или указан параметр `--git-dir`, но ничего из `--work-tree`, `GIT_WORK_TREE` или `core.worktree` не задано, то текущий каталог будет считаться корневым. -*`GIT_INDEX_FILE`* -- это путь к файлу индекса (только для репозиториев с непустой рабочей директорией). +*`GIT_INDEX_FILE`* -- это путь к файлу индекса (только для репозиториев с непустым рабочим каталогом). -*`GIT_OBJECT_DIRECTORY`* может быть использована для указания директории с объектами вместо `.git/objects`. +*`GIT_OBJECT_DIRECTORY`* может быть использована для указания каталога с объектами вместо `.git/objects`. -*`GIT_ALTERNATE_OBJECT_DIRECTORIES`* -- это список разделённых двоеточием директорий (типа `/dir/one:/dir/two:…`), в которых Git будет пытаться найти объекты, которых нет в `GIT_OBJECT_DIRECTORY`. +*`GIT_ALTERNATE_OBJECT_DIRECTORIES`* -- это список разделённых двоеточием каталогов (типа `/dir/one:/dir/two:…`), в которых Git будет пытаться найти объекты, которых нет в `GIT_OBJECT_DIRECTORY`. Это может быть полезно, если у вас много проектов с большими файлами с абсолютно одинаковым содержимым, что позволит не хранить много дубликатов. diff --git a/book/10-git-internals/sections/maintenance.asc b/book/10-git-internals/sections/maintenance.asc index 20f30591..35f1b431 100644 --- a/book/10-git-internals/sections/maintenance.asc +++ b/book/10-git-internals/sections/maintenance.asc @@ -34,7 +34,7 @@ $ find .git/refs -type f .git/refs/tags/v1.1 ---- -Если выполнить `git gc`, эти файлы будут удалены из директории `refs`. +Если выполнить `git gc`, эти файлы будут удалены из каталога `refs`. Git перенесёт их в файл `.git/packed-refs` в угоду эффективности: [source,console] @@ -49,8 +49,8 @@ cac0cab538b970a37ea1e769cbbde608743bc96d refs/tags/v1.0 ---- При обновлении ссылки Git не будет редактировать этот файл, а добавит новый файл в `refs/heads`. -Для получения хеша, соответствующего нужной ссылке, Git сначала проверит наличие файла ссылки в директории `refs`, а к файлу `packed-refs` обратится только в случае отсутствия оного. -Так что, если вы не можете найти ссылку в директории `refs`, скорее всего она упакована в файле `packed-refs`. +Для получения хеша, соответствующего нужной ссылке, Git сначала проверит наличие файла ссылки в каталоге `refs`, а к файлу `packed-refs` обратится только в случае отсутствия оного. +Так что, если вы не можете найти ссылку в каталоге `refs`, скорее всего она упакована в файле `packed-refs`. Обратите внимание, последняя строка файла начинается с `^`. Это означает, что предыдущая строка является аннотированным тегом, а текущая строка -- это коммит, на который указывает аннотированный тег. @@ -152,7 +152,7 @@ $ rm -Rf .git/logs/ ---- В этом случае два первых коммита недоступны ниоткуда. -Так как данные reflog хранятся в директории `.git/logs/`, которую мы только что удалили, то теперь у нас нет reflog. +Так как данные reflog хранятся в каталоге `.git/logs/`, которую мы только что удалили, то теперь у нас нет reflog. Как теперь восстановить коммиты? Один из вариантов -- использование утилиты `git fsck`, проверяющую внутреннюю базу данных на целостность. Если выполнить её с ключом `--full`, будут показаны все объекты, недостижимые из других объектов: diff --git a/book/10-git-internals/sections/objects.asc b/book/10-git-internals/sections/objects.asc index dc09fe43..4ad31baa 100644 --- a/book/10-git-internals/sections/objects.asc +++ b/book/10-git-internals/sections/objects.asc @@ -7,9 +7,9 @@ Git -- контентно-адресуемая файловая система. А означает это, по сути, что Git -- простое хранилище ключ-значение. Можно добавить туда любые данные, в ответ будет выдан ключ по которому их можно извлечь обратно. -В качестве примера, воспользуемся служебной командой `git hash-object`, которая берёт некоторые данные, сохраняет их в виде объекта в директории `.git/objects` (_база данных объектов_) и возвращает уникальный ключ, который является ссылкой на созданный объект. +В качестве примера, воспользуемся служебной командой `git hash-object`, которая берёт некоторые данные, сохраняет их в виде объекта в каталоге `.git/objects` (_база данных объектов_) и возвращает уникальный ключ, который является ссылкой на созданный объект. -Для начала создадим новый Git-репозиторий и убедимся, что директория `objects` пуста: +Для начала создадим новый Git-репозиторий и убедимся, что каталог `objects` пуст: [source,console] ---- @@ -23,7 +23,7 @@ $ find .git/objects $ find .git/objects -type f ---- -Git проинициализировал директорию `objects` и создал в ней пустые поддиректории `pack` и `info`. +Git проинициализировал каталог `objects` и создал в нём пустые подкаталоги `pack` и `info`. Теперь с помощью `git hash-object` создадим объект и вручную добавим его в базу Git: [source,console] @@ -46,9 +46,9 @@ $ find .git/objects -type f .git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 ---- -Мы видим новый файл в директории `objects`. +Мы видим новый файл в каталоге `objects`. Это и есть начальное внутреннее представление данных в Git -- один файл на единицу хранения с именем, являющимся контрольной суммой содержимого и заголовка. -Первые два символа SHA-1 определяют поддиректорию файла внутри `objects`, остальные 38 -- его имя. +Первые два символа SHA-1 определяют подкаталог файла внутри `objects`, остальные 38 -- его имя. Извлечь содержимое объекта можно при помощи команды `cat-file`. Она подобна швейцарскому ножу для анализа объектов Git. @@ -124,7 +124,7 @@ blob Следующий тип объектов, который мы рассмотрим, -- деревья -- решают проблему хранения имён файлов, а также позволяют хранить группы файлов вместе. Git хранит данные сходным с файловыми системами UNIX способом, но в немного упрощённом виде. -Содержимое хранится в деревьях и блобах, где дерево соответствует директории на файловой системе, а блоб более или менее соответствует inode или содержимому файла. +Содержимое хранится в деревьях и блобах, где дерево соответствует каталогу на файловой системе, а блоб более или менее соответствует inode или содержимому файла. Дерево может содержать одну или более записей, содержащих SHA-1 хеш, соответствующий блобу или поддереву, права доступа к файлу, тип и имя файла. Например, дерево последнего коммита в проекте может выглядеть следующим образом: @@ -137,7 +137,7 @@ $ git cat-file -p master^{tree} ---- Запись `master^{tree}` указывает на дерево, соответствующее последнему коммиту ветки `master`. -Обратите внимание, что поддиректория `lib` -- не блоб, а указатель на другое дерево: +Обратите внимание, что подкаталог `lib` -- не блоб, а указатель на другое дерево: [source,console] ---- @@ -165,7 +165,7 @@ image::images/data-model-1.png["Упрощённая модель данных G Поэтому для создания дерева необходимо проиндексировать какие-нибудь файлы. Для создания индекса из одной записи -- первой версии файла test.txt -- воспользуемся низкоуровневой командой `git update-index`. Данная команда может искусственно добавить более раннюю версию test.txt в новый индекс. -Необходимо передать опции `--add`, так как файл ещё не существует в индексе (да и самого индекса ещё нет), и `--cacheinfo`, так как добавляемого файла нет в рабочей директории, но он есть в базе данных. +Необходимо передать опции `--add`, так как файл ещё не существует в индексе (да и самого индекса ещё нет), и `--cacheinfo`, так как добавляемого файла нет в рабочем каталоге, но он есть в базе данных. Также необходимо передать права доступа, хеш и имя файла: [source,console] @@ -176,7 +176,7 @@ $ git update-index --add --cacheinfo 100644 \ В данном случае права доступа `100644` -- означают обычный файл. Другие возможные варианты: `100755` -- исполняемый файл, `120000` -- символическая ссылка. -Права доступа в Git сделаны по аналогии с правами доступа в UNIX, но они гораздо менее гибки: указанные три режима -- единственные доступные для файлов (блобов) в Git (хотя существуют и другие режимы, используемые для директорий и подмодулей). +Права доступа в Git сделаны по аналогии с правами доступа в UNIX, но они гораздо менее гибки: указанные три режима -- единственные доступные для файлов (блобов) в Git (хотя существуют и другие режимы, используемые для каталогов и подмодулей). Теперь можно воспользоваться командой `git write-tree` для сохранения индекса в объект дерева. Здесь опция `-w` не требуется -- команда автоматически создаст дерево из индекса, если такого дерева ещё не существует: @@ -220,7 +220,7 @@ $ git cat-file -p 0155eb4229851634a0f03eb265b69f5a2d56f341 ---- Обратите внимание, что в данном дереве находятся записи для обоих файлов, а также, что хеш файла `test.txt` это хеш «второй версии» этого файла (`1f7a7a`). -Для интереса, добавим первое дерево как поддиректорию текущего. +Для интереса, добавим первое дерево как подкаталог текущего. Добавлять деревья в область подготовленных файлов можно с помощью команды `git read-tree`. В нашем случае, чтобы включить уже существующее дерево в индекс и сделать его поддеревом, необходимо использовать опцию `--prefix`: @@ -235,7 +235,7 @@ $ git cat-file -p 3c4e9cd789d88d8d89c1073707c3585e41b0e614 100644 blob 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a test.txt ---- -Если бы вы сейчас добавили только что сохранённое дерево в рабочую директорию, вы бы увидели два файла в корне рабочей директории и поддиректорию `bak` с первой версией файла `test.txt`. +Если бы вы сейчас добавили только что сохранённое дерево в рабочий каталог, вы бы увидели два файла в его корне и подкаталог `bak` с первой версией файла `test.txt`. В таком случае хранимые структуры данных можно представить следующим образом: .Структура данных Git для текущего состояния @@ -321,8 +321,8 @@ Date: Fri May 22 18:09:34 2009 -0700 Здорово, правда? Мы только что выполнили несколько низкоуровневых операций и получили Git репозиторий с историей без единой высокоуровневой команды. Именно так и работает Git, когда выполняются команды `git add` и `git commit` -- сохраняет блобы для изменённых файлов, обновляет индекс, создаёт деревья и фиксирует изменения в объекте коммита, ссылающемся на дерево верхнего уровня и предшествующие коммиты. -Эти три основных вида объектов Git -- блоб, дерево и коммит -- сохраняются в виде отдельных файлов в директории `.git/objects`. -Вот как сейчас выглядит список объектов в этой директории, в комментарии указано чему соответствует каждый из них: +Эти три основных вида объектов Git -- блоб, дерево и коммит -- сохраняются в виде отдельных файлов в каталоге `.git/objects`. +Вот как сейчас выглядит список объектов в этом каталоге, в комментарии указано чему соответствует каждый из них: [source,console] ---- @@ -341,8 +341,8 @@ $ find .git/objects -type f Если пройти по всем внутренним ссылкам, получится граф объектов, представленный на рисунке: -.Все объекты в директории Git -image::images/data-model-3.png["Все объекты в директории Git"] +.Все объекты в каталоге Git +image::images/data-model-3.png["Все объекты в каталоге Git"] ==== Хранение объектов @@ -402,8 +402,8 @@ Git сжимает новые данные при помощи zlib, в Ruby э ---- После этого сохраним сжатую строку в объект на диске. -Определим путь к файлу, который будет записан (первые два символа хеша используются в качестве названия директории, оставшиеся 38 -- в качестве имени файла в ней). -В Ruby для безопасного создания нескольких вложенных директорий можно использовать функцию `FileUtils.mkdir_p()`. +Определим путь к файлу, который будет записан (первые два символа хеша используются в качестве названия каталога, оставшиеся 38 -- в качестве имени файла в ней). +В Ruby для безопасного создания нескольких вложенных каталогов можно использовать функцию `FileUtils.mkdir_p()`. Далее, откроем файл вызовом `File.open()` и запишем сжатые данные вызовом `write()` для полученного файлового дескриптора: [source,console] diff --git a/book/10-git-internals/sections/packfiles.asc b/book/10-git-internals/sections/packfiles.asc index 2d31a1f4..e9fc2a20 100644 --- a/book/10-git-internals/sections/packfiles.asc +++ b/book/10-git-internals/sections/packfiles.asc @@ -100,7 +100,7 @@ Writing objects: 100% (18/18), done. Total 18 (delta 3), reused 0 (delta 0) ---- -Если заглянуть в директорию с объектами, то можно обнаружить, что большинство объектов исчезло, зато появились два новых файла: +Если заглянуть в каталог с объектами, то можно обнаружить, что большинство объектов исчезло, зато появились два новых файла: [source,console] ---- diff --git a/book/10-git-internals/sections/plumbing-porcelain.asc b/book/10-git-internals/sections/plumbing-porcelain.asc index 1071a78b..27f8f7cd 100644 --- a/book/10-git-internals/sections/plumbing-porcelain.asc +++ b/book/10-git-internals/sections/plumbing-porcelain.asc @@ -9,10 +9,10 @@ В данной главе рассматриваются именно низкоуровневые служебные команды, дающие контроль над внутренними процессами Git и показывающие, как он работает и почему он работает так, а не иначе. Предполагается, что данные команды не будут использоваться напрямую из командной строки, а будут служить в качестве строительных блоков для новых команд и пользовательских скриптов. -Когда вы выполняете `git init` в новой или существовавшей ранее директории, Git создаёт подкаталог `.git`, в котором располагается почти всё, чем он манипулирует. +Когда вы выполняете `git init` в новом или существовавшем ранее каталоге, Git создаёт подкаталог `.git`, в котором располагается почти всё, чем он манипулирует. Если требуется выполнить резервное копирование или клонирование репозитория, достаточно скопировать лишь этот каталог, чтобы получить почти всё необходимое. Данная глава почти полностью посвящена его содержимому. -Вот так выглядит только что созданная директория `.git`: +Вот так выглядит только что созданный каталог `.git`: [source,console] ---- @@ -26,12 +26,12 @@ objects/ refs/ ---- -В зависимости от используемой версии Git, здесь могут присутствовать и другие файлы, но по умолчанию команда `git init` создаёт именно такое содержимое в директории `.git`. +В зависимости от используемой версии Git, здесь могут присутствовать и другие файлы, но по умолчанию команда `git init` создаёт именно такое содержимое в каталоге `.git`. Файл `description` используется только программой GitWeb, не обращайте на него внимание. -Файл `config` содержит специфичные для этого репозитория конфигурационные параметры, а в директории `info` расположен файл с глобальными настройкам игнорирования файлов (((excludes))) -- он позволяет исключить файлы, которые вы не хотите помещать в .gitignore. -В директории `hooks` располагаются клиентские и серверные хуки, подробно рассмотренные в главе <>. +Файл `config` содержит специфичные для этого репозитория конфигурационные параметры, а в каталоге `info` расположен файл с глобальными настройкам игнорирования файлов (((excludes))) -- он позволяет исключить файлы, которые вы не хотите помещать в .gitignore. +В каталоге `hooks` располагаются клиентские и серверные хуки, подробно рассмотренные в главе <>. -Итак, осталось четыре важных элемента: файлы `HEAD` и `index` (ещё не созданный) и директории `objects` и `refs`. +Итак, осталось четыре важных элемента: файлы `HEAD` и `index` (ещё не созданный) и каталоги `objects` и `refs`. Это ключевые элементы Git. -В директории `objects` находится база данных объектов Git; в `refs` -- ссылки на объекты коммитов в этой базе (ветки, теги и другие); файл `HEAD` указывает на текущую ветку, a в файле `index` хранится содержимое индекса. +В каталоге `objects` находится база данных объектов Git; в `refs` -- ссылки на объекты коммитов в этой базе (ветки, теги и другие); файл `HEAD` указывает на текущую ветку, a в файле `index` хранится содержимое индекса. Далее мы детально рассмотрим эти элементы, чтобы понять как работает Git. diff --git a/book/10-git-internals/sections/refs.asc b/book/10-git-internals/sections/refs.asc index e5500af3..c61dca94 100644 --- a/book/10-git-internals/sections/refs.asc +++ b/book/10-git-internals/sections/refs.asc @@ -4,8 +4,8 @@ Если вас интересует история репозитория начиная с определенного коммита, например `1a410e`, то для её отображения вы можете воспользоваться командой `git log 1a410e`, однако при этом вам всё ещё необходимо помнить хеш коммита `1a410e`, который является начальной точкой истории. Было бы неплохо, если бы существовал файл, в который можно было бы сохранить значение SHA-1 под простым именем, а затем использовать это имя вместо хеша SHA-1. -В Git такие файлы называются ссылками («references» или, сокращённо, «refs») и расположены в директории `.git/refs`. -В нашем проекте эта директория пока пуста, но в ней уже прослеживается некая структура: +В Git такие файлы называются ссылками («references» или, сокращённо, «refs») и расположены в каталоге `.git/refs`. +В нашем проекте этот каталог пока пуст, но в ней уже прослеживается некая структура: [source,console] ---- @@ -59,8 +59,8 @@ fdf4fc3344e67ab068f836878b6c4951e3b15f3d First commit Теперь база данных Git схематично выглядит так, как показано на рисунке: -.Объекты в директории .git, а также указатели на вершины веток -image::images/data-model-4.png["Объекты в директории .git, а также указатели на вершины веток"] +.Объекты в каталоге .git, а также указатели на вершины веток +image::images/data-model-4.png["Объекты в каталоге .git, а также указатели на вершины веток"] При выполнении команды `git branch `, в действительности Git запускает команду `update-ref`, которая добавляет SHA-1 хеш последнего коммита текущей ветки в файл с именем указанной ветки. @@ -181,7 +181,7 @@ $ git cat-file blob junio-gpg-pub ==== Ссылки на удалённые ветки Третий тип ссылок, который мы рассмотрим -- ссылки на удалённые ветки. -Если вы добавили удалённый репозиторий и отправили в него какие-нибудь изменения, Git сохранит последнее отправленное значение SHA-1 в директории `refs/remotes` для каждой отправленной ветки. +Если вы добавили удалённый репозиторий и отправили в него какие-нибудь изменения, Git сохранит последнее отправленное значение SHA-1 в каталоге `refs/remotes` для каждой отправленной ветки. Например, можно добавить удалённый репозиторий `origin` и отправить туда ветку `master`: [source,console] diff --git a/book/10-git-internals/sections/refspec.asc b/book/10-git-internals/sections/refspec.asc index 7f29d480..307d1ed3 100644 --- a/book/10-git-internals/sections/refspec.asc +++ b/book/10-git-internals/sections/refspec.asc @@ -82,7 +82,7 @@ From git@github.com:schacon/simplegit fetch = +refs/heads/qa*:refs/remotes/origin/qa* ---- -Для достижения аналогичного результата можно так же использовать пространства имён (или директории). +Для достижения аналогичного результата можно так же использовать пространства имён (или каталоги). Если ваша QA команда использует несколько веток для своей работы и вы хотите получать только ветку `master` и все ветки команды QA, то можно добавить в конфигурацию следующее: [source,ini] diff --git a/book/10-git-internals/sections/transfer-protocols.asc b/book/10-git-internals/sections/transfer-protocols.asc index 171f3ab9..3eea67c5 100644 --- a/book/10-git-internals/sections/transfer-protocols.asc +++ b/book/10-git-internals/sections/transfer-protocols.asc @@ -6,7 +6,7 @@ Git умеет передавать данные между репозитори ==== Глупый протокол Если вы разрешили доступ на чтение к вашему репозиторию через HTTP, то скорее всего будет использован «глупый» протокол. -Протокол назвали «глупым», потому что для его работы не требуется выполнение специфичных для Git операций на стороне сервера: весь процесс получения данных представляет собой серию HTTP `GET` запросов, при этом клиент ожидает наличия на сервере структуры директорий аналогичной Git репозиторию. +Протокол назвали «глупым», потому что для его работы не требуется выполнение специфичных для Git операций на стороне сервера: весь процесс получения данных представляет собой серию HTTP `GET` запросов, при этом клиент ожидает наличия на сервере структуры каталогов аналогичной Git репозиторию. [NOTE] ====