git-clone.txt

git-clone(1)
============

НАЗВАНИЕ
--------
git-clone - Клонирование репозитория в новый каталог


ОБЗОР
-----
[synopsis]
'git clone' [--template=<каталог-шаблонов>]
	  [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
	  [-o <имя>] [-b <ветка>] [-u <путь-загрузки>] [--reference <репозиторий>]
	  [--dissociate] [--separate-git-dir <каталог-git>]
	  [--depth <глубина>] [--[no-]single-branch] [--no-tags]
	  [--recurse-submodules[=<спецификатор-пути>]] [--[no-]shallow-submodules]
	  [--[no-]remote-submodules] [--jobs <n>] [--sparse] [--[no-]reject-shallow]
	  [--filter=<спецификатор-фильтра>] [--also-filter-submodules]]
	  [--] <репозиторий> [<каталог>]

ОПИСАНИЕ
--------

Клонирует репозиторий во вновь созданный каталог, создаёт отслеживаемые внешние ветки для каждой ветки в клонируемом репозитории (список можно посмотреть с помощью `git branch --remotes`), а также создаёт начальную ветвь на основе текущей активной ветки клонируемого репозитория и переключается на неё.

После клонирования, команда `git fetch` без аргументов будет обновлять все отслеживаемые внешние ветки, а команда `git pull` (также без аргументов), будет сливать удалённую ветвь в текущую мастер-ветку, если таковая имеется (её может не быть при использовании `--single-branch`; см. ниже).

Для достижения конфигурации по умолчанию, команда создаёт ссылки на головы внешних веток в каталоге `refs/remotes/origin` и инициализирует переменные конфигурации `remote.origin.url` и `remote.origin.fetch`.


ПАРАМЕТРЫ
---------
`-l`::
`--local`::
	Когда репозиторий с которого производится клонирование находится на локальной машине, этот флаг позволяет обойти обычный «осведомлённый о Git» транспортный механизм и клонирует репозиторий напрямую: просто копируя `HEAD` и всё, что находится в каталогах `objects` и `refs`. По возможности, для файлов в каталоге `.git/objects/` будут использоваться жёсткие ссылки, дабы сохранить дисковое пространство.
+
Если в качестве репозитория задан локальный путь (например, `/путь/к/репо`), то это является поведением по умолчанию, и `--local`, по сути, ничего не делает. Если в качестве репозитория задан URL, то этот флаг игнорируется (и мы никогда не используем локальные оптимизации в таких случаях). Параметр `--no-local` позволяет переопределить поведение по умолчанию: и при передаче локальных путей (вроде `/путь/к/репо`), будет использоваться обычный транспорт Git.
+
Если в `$GIT_DIR/objects` в репозитории есть символические ссылки или сам является символической ссылкой, то клонирование завершится ошибкой. Это сделано ради безопасности, чтобы предотвратить непреднамеренное копирование файлов при разыменовании этих ссылок.
+
Данный параметр не работает с репозиториями, принадлежащими другим пользователям по соображениям безопасности, так что, чтобы клонирование завершилось успешно, нужно будет указать `--no-local`.
+
*ПРИМЕЧАНИЕ*: при выполнении данной операции может возникнуть состояние гонки с параллельными модификациями в исходном репозитории, аналогично тому, как это может происходить при выполнении `cp -r <источник> <назначение>` одновременно с изменениями в _<источнике>_.

`--no-hardlinks`::
	При клонировании из репозитория на локальной файловой системе, принудительно использовать копирование для файлов в каталоге `.git/objects`, а не жёсткие ссылки. Это может быть желательно, если вы пытаетесь сделать резервную копию вашего репозитория.

`-s`::
`--shared`::
	Когда клонируемый репозиторий находится на локальной машине, вместо использования жёстких ссылок, автоматически настроить `.git/objects/info/alternates` для совместного использования объектов с исходным репозиторием. Изначально в полученном репозитории не будет ни каких собственных объектов.
+
*ПРИМЕЧАНИЕ*: это может быть опасной операцией; *не* используйте её, если вы не понимаете, что она делает. Если вы клонируете свой репозиторий, используя этот параметр, а затем удаляете ветки (или используете любые другие команды Git, которые могут привести к удалению всех ссылок на какие-либо существующие коммиты) в исходном репозитории, то некоторые объекты могут стать изолированными (или болтающимися). Эти объекты могут быть удалены в результате обычных операций Git (таких как `git commit`), которые автоматически вызывают `git maintenance run --auto` (см. linkgit:git-maintenance[1]). Если эти объекты будут удалены и на них останутся ссылки в клонированном репозиторий, то клонированный репозиторий будет испорчен.
+
Обратите внимание, что при запуске `git repack` без параметра `--local` в репозитории, клонированном с `--shared`, разделяемые объекты из исходного репозитория будут скопированы в pack-файлы клонированного репозитория, из-за чего экономия дискового пространства от `clone --shared` будет потеряна. Однако, запускать `git gc`, который использует параметр `--local` по умолчанию, — безопасно.
+
Если вы хотите избавиться от зависимостей репозитория, клонированного с `--shared`, от его исходного репозитория, вы можете просто запустить `git repack -a`, который скопирует все объекты из исходного репозитория в pack-файлы клонированного.

`--reference[-if-able] <репозиторий>`::
	Если _<репозиторий>_ (заданный как аргумент параметра) находится на локальной машине, автоматически настроить `.git/objects/info/alternates` для получения объектов из этого _<репозитория>_. Использование уже существующего репозиторий как дополнительного потребует копирования меньшего количества объектов из клонируемого репозитория, что уменьшит сетевой трафик и локальные затраты на хранение. С `--reference-if-able`, если каталог _<репозитория>_ не существует, то это вызовет предупреждением, а не ошибку, и клонирование не будет из-за этого прервано.
+
*ПРИМЕЧАНИЕ*: см. ПРИМЕЧАНИЕ для параметра `--shared`, а также описание параметра `--dissociate`.

`--dissociate`::
	Заимствовать объекты из дополнительных репозиториев, заданных в параметрах `--reference` для того, чтобы уменьшить использование сетевого трафика, и прекратить совместное использование объектов после того, как клонирование будет закончено, скопировав все необходимые объекты в клонированный репозиторий. Этот параметр также может использован при клонировании из локального репозитория, у которого уже есть свой дополнительный репозиторий. В таком случае в новый репозиторий будут скопированы объекты из дополнительного, так что этот параметр можно использовать для создания копии репозитория, которая более не зависит от дополнительных репозиториев.

`-q`::
`--quiet`::
	Тихий режим. Не выводить информацию о ходе выполнения в стандартный поток ошибок.

`-v`::
`--verbose`::
	Включение подробного режима. Не влияет на вывод информацию о ходе выполнения в стандартный поток ошибок.

`--progress`::
	По умолчанию информация о ходе выполнения выводится в стандартный поток ошибок, когда он привязан к терминалу, если только не задан параметр `--quiet`. Данный флаг принудительно включает вывод этой информации даже если стандартный поток ошибок направлен не в терминал.

`--server-option=<параметры>`::
	Передать данную строку на сервер при обмене данными по протоколу версии 2. Данная строка не должна содержать символы NUL или LF. То как сервер будет обрабатывать эти параметры, в том числе неизвестные, зависит только от сервера. Если параметр `--server-option=<параметры>` указан несколько раз, то все эти строки будут отправлены другой стороне в том порядке, в котором они указанном в командной строке. Если в командной строке параметр ++--server-option=++__<параметры>__ не задан ни разу, то вместо этого будет использовано значения переменной конфигурации `remote.<имя>.serverOption`.

`-n`::
`--no-checkout`::
	После завершения клонирования, переход на какую-либо ветку не производится и указатель `HEAD` не устанавливается.

`--`[`no-`]`reject-shallow`::
	Завершиться с ошибкой, если репозиторий, из которого происходит клонирование, является частичным. Для указания значения по умолчанию можно использовать переменную конфигурации `clone.rejectShallow`.

`--bare`::
	Создать голый («bare») репозиторий Git. То есть вместо создания _<каталога>_ и размещения административных файлов в `<каталог>/.git`, использовать сам _<каталог>_ в качестве `$GIT_DIR`. Это, очевидно, подразумевает `--no-checkout`, потому что нет подходящего места для размещения рабочей копии. Кроме того, головы веток внешнего репозитория копируются непосредственно в соответствующие им локальные головы веток, без отображений в `refs/remotes/origin/`. При использовании этого параметра не создаются ни отслеживаемые внешние ветви, ни связанные с ними переменные конфигурации.

`--sparse`::
	Задействовать режим разреженного состояния, изначально извлекая файлы только в каталоге верхнего уровня. Для расширения рабочего каталога по мере необходимости, можно использовать команду linkgit:git-sparse-checkout[1].

`--filter=<спецификатор-фильтра>`::
	Использовать функцию неполного клонирования и попросить сервер отправлять только подмножество достижимых объектов, удовлетворяющих заданной _<спецификатору-фильтра>_. При использовании `--filter` указанный _<спецификатор-фильтра>_ используется в качестве фильтра неполного клонирования. Например, `--filter=blob:none` отфильтрует все blob-объекты (содержимое файлов), пока они не понадобятся Git. А, например, `--filter=blob:limit=<размер>` отфильтрует все blob-объекты объёмом не меньше _<размера>_. Дополнительные сведения о спецификаторах фильтра см. в описании параметра `--filter` команды linkgit:git-rev-list[1].

`--also-filter-submodules`::
	Также применять фильтр неполного клонирования ко всем подмодулям в репозитории. Требует указания `--filter` и `--recurse-submodules`. Данный параметр может быть включён по умолчанию с помощью переменной конфигурации `clone.filterSubmodules`.

`--mirror`::
	Создать зеркало исходного репозитория. Это подразумевает `--bare`. В сравнении с `--bare`, `--mirror` не только переносит локальные ветки источника на локальные ветки цели, но он также переносит и все другие ссылки (включая отслеживаемые внешние ветки, заметки и т.д.) и устанавливает спецификаторы ссылок таким образом, чтобы все эти ссылки были перезаписаны `git remote update` в целевом репозитории.

`-o` _<имя>_::
`--origin` _<имя>_::
	Вместо имени `origin` для вышестоящего репозитория, использовать _<имя>_ в качестве имени удалённого источника. Это переопределяет значение заданное в переменной конфигурации `clone.defaultRemoteName`.

`-b` _<имя>_::
`--branch` _<имя>_::
	Вместо того, чтобы вновь созданный `HEAD` указывал, на ту же ветку, на которую указывает `HEAD` клонировуемого репозитория, направить его на ветку с указанным _<именем>_. Репозиторий (не являющийся голым) будет также переключен на эту ветку. Параметр `--branch` также принимает _<имена>_ меток; в таком случае после клонирования полученный репозиторий будет находится в состоянии с отсоединённым указателем `HEAD`.

`-u` _<upload-pack>_::
`--upload-pack` _<upload-pack>_::
	При доступе к клонируемому репозиторию по ssh, этот параметр задаёт путь (отличный от пути по умолчанию) к команде `git-upload-pack`, которая будет запускаться на удалённом конце.

`--template=<каталог-шаблонов>`::
	Задаёт каталог с шаблонами. (См. раздел «КАТАЛОГ ШАБЛОНОВ» в linkgit:git-init[1])

`-c` `<ключ>=<значение>`::
`--config` `<ключ>=<значение>`::
	Устанавливает переменную конфигурации во вновь созданном репозитории; эта переменная устанавливается сразу после инициализации репозитория, но до того, как будет получена внешняя история или будут извлечены какие-либо файлы. _<ключ>_ должен быть в том же формате, что и для linkgit:git-config[1] (например, `core.eol=true`). Если для одного и того же _<ключа>_ даны несколько _<значений>_, каждое значение будет записано в файл конфигурации. Так что это позволяет, например, добавить дополнительные спецификаторы ссылок, которые должны быть извлечены из внешнего источнику origin.
+
Из-за ограничений текущей реализации, некоторые переменные конфигурации не вступают в силу до тех пор, пока не будут произведены первоначальные загрузка и извлечение состояния. В частности это относится к таким переменным конфигурации, как `remote.<имя>.mirror' и `remote.<имя>.tagOpt`. Вместо них следует использовать соответственно параметры `--mirror` и `--no-tags`.

`--depth <глубина>`::
	Создаёт «частичный» (shallow) клон с историей, усечённой до указанного количество коммитов. Ясли явно не передано `--no-single-branch` (что приведёт к загрузке последней истории всех ветвей), то данный параметр подразумевает `--single-branch`. Если вы хотите, чтобы подмодули тоже клонировались частично, то передайте также `--shallow-submodules`.

`--shallow-since=<дата>`::
	Создать частичный клон с историей начиная с указанной _<даты>_.

`--shallow-exclude=<ссылка>`::
	Создать частичный клон с историей, в которую не будут включены коммиты, достижимые из указанной внешней ветки или метки. Этот параметр может быть задан несколько раз.

`--[no-]single-branch`::
	Клонировать только историю, ведущую к верхушке одной конкретной ветки (либо заданной параметром `--branch`, либо той, на которую указывает `HEAD` внешнего репозитория). Дальнейшие вызовы `fetch` в полученном репозитории будут обновлять отслеживаемую внешнюю ветку только для этой самой ветки, которая была создана при изначальном клонировании репозитория с данным параметром. Если во время клонирования с `--single-branch` `HEAD` во внешнем репозитории не указывает ни на одну ветку, то ни одной отслеживаемой внешней ветки создано не будет.

`--no-tags`::
	Не клонировать ни какие удалённые метки и установить переменную конфигурации `remote.<имя>.tagOpt=--no-tags`, что гарантирует, что будущие операции `git pull` и `git fetch` не будут отслеживать какие-либо метки. Однако в дальнейшем, будет возможна явная загрузка меток (см. linkgit:git-fetch[1]).
+
Может использоваться совместно с `--single-branch` для клонирования и дальнейшей работы только с одной веткой, без каких-либо других ссылок. Это полезно, например, если есть потребность держать рядом минимальную копию ветки по умолчанию из некоторого репозитория для её индексации и поиска в ней.

`--recurse-submodules[=<спецификатор-пути>]`::
	После того, как клон будет создан, инициализировать и клонировать его подмодули, соответствующие указанному _<спецификатору-пути>_. Если `=<спецификатор-пути>` не задан, то инициализируются и клонируются все подмодули. Этот параметр может быть указан несколько раз, чтобы задать спецификатор, состоящий из нескольких записей. В полученном клоне устанавливается переменная конфигурации 'submodule.active`, в качестве значения которой используется итоговый спецификатор пути или "`.`", если ни один не задан, что означает «все подмодули».
+
При инициализации и клонировании подмодулей используются их параметры по умолчанию. Данный параметр эквивалентен запуску `git submodule update --init --recursive <спецификатор-пути>` сразу после завершения клонирования. Если у клонированного репозитория нет рабочей копии или если переключение на текущую ветку после извлечения отключено (т.е. если задан один из параметров: `--no-checkout`/`-n`, `--bare` или `--mirror`), то этот параметр игнорируется.

`--[no-]shallow-submodules`::
	Клонировать все (выбранные) подмодули как частичные с глубиной 1.

`--[no-]remote-submodules`::
	Все клонируемые подмодули, будут использовать статус из отслеживаемой внешней ветки своих репозиториев, а не SHA-1, сохранённый в надпроекте. Это эквивалентно передаче параметра `--remote` в `git submodule update`.

`--separate-git-dir=<каталог-git>`::
	Вместо того, чтобы размещать клонированный репозиторий там, где он должен быть, поместить его в указанный каталог, а затем сделать на него независящую от файловой системы символическую ссылку Git. В результате репозиторий Git может находится отдельно от рабочей копии.

`--ref-format=<формат-ссылок>`::

Задаёт формат хранения ссылок репозитория. Допустимые значения:
+
include::ref-storage-format.txt[]

`-j` _<n>_::
`--jobs` _<n>_::
	Количество подмодулей, которые будут загружаться одновременно. По умолчанию равно значению переменной конфигурации `submodule.fetchJobs`.

_<репозиторий>_::
	(Возможно удалённый) _<репозиторий>_, который должен быть склонирован. См. подробности о том как задавать адрес репозитория в разделе <<URLS,URL-АДРЕСА GIT>> ниже.

_<каталог>_::
	Название нового каталога в который репозиторий должен быть склонирован. Если _<каталог>_ не задан, то используется «человеская» часть ссылки на исходный репозиторий (например, `репо` for `/путь/к/репо.git` и `foo` для `host.xz:foo/.git`). Клонирование в существующий каталог разрешается только, если этот каталог пуст.

`--bundle-uri=<uri>`::
	Прежде чем извлекать данные из внешнего репозитория, сначала скачать пакет (bundle) из указанного _<uri>_ и распаковать его в локальный репозиторий. Ссылки из пакета будут храниться в скрытым пространстве имён `refs/bundle/*`. Этот параметр несовместим с `--depth`, `--shallow-since` и `--shallow-exclude`.

:git-clone: 1
include::urls.txt[]

ПРИМЕРЫ
-------

* Клонирование из вышестоящего репозитория:
+
------------
$ git clone git://git.kernel.org/pub/scm/.../linux.git my-linux
$ cd my-linux
$ make
------------


* Создать локальный клон, который «заимствует» объекты из репозитория в текущем каталоге и не извлекает рабочую копию:
+
------------
$ git clone -l -s -n . ../copy
$ cd ../copy
$ git show-branch
------------


* Клонировать из вышестоящего репозитория, «заимствуя» объекты для совместного использования из существующего локального каталога:
+
------------
$ git clone --reference /git/linux.git \
	git://git.kernel.org/pub/scm/.../linux.git \
	my-linux
$ cd my-linux
------------


* Создать голый репозиторий, чтобы опубликовать ваши изменения для общественности:
+
------------
$ git clone --bare -l /home/proj/.git /pub/scm/proj.git
------------

* Клонировать локальный репозиторий у другого пользователя:
+
------------
$ git clone --no-local /home/otheruser/proj.git /pub/scm/proj.git
------------

КОНФИГУРАЦИЯ
------------

include::includes/cmd-config-section-all.txt[]

include::config/init.txt[]

include::config/clone.txt[]


GIT
---
Является частью пакета linkgit:git[1]