Русский ▾ Topics ▾ Latest version ▾ git-clone last updated in 2.51.1

НАЗВАНИЕ

git-clone - Клонирование репозитория в новый каталог

ОБЗОР

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 (см. 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

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

--filter=<спецификатор-фильтра>

Использовать функцию неполного клонирования и попросить сервер отправлять только подмножество достижимых объектов, удовлетворяющих заданной <спецификатору-фильтра>. При использовании --filter указанный <спецификатор-фильтра> используется в качестве фильтра неполного клонирования. Например, --filter=blob:none отфильтрует все blob-объекты (содержимое файлов), пока они не понадобятся Git. А, например, --filter=blob:limit=<размер> отфильтрует все blob-объекты объёмом не меньше <размера>. Дополнительные сведения о спецификаторах фильтра см. в описании параметра --filter команды 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.

--revision=<редакция>

Создать новый репозиторий и извлечь (fetch) историю, ведущую к указанной <редакции> (и ничего кроме этого), не создавая отслеживаемую внешнюю ветку и не создавая локальную ветку, и перевести репозиторий в состояние отсоединённого HEAD, указывающего на <редакцию>. Аргумент может быть именем ссылки (например, refs/heads/main или refs/tags/v1.0), которая рекурсивно разыменовывается до коммита, или шестнадцатеричного имени объекта. Этот параметр несовместим с --branch и --mirror.

-u <upload-pack>
--upload-pack <upload-pack>

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

--template=<каталог-шаблонов>

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

-c <ключ>=<значение>
--config <ключ>=<значение>

Устанавливает переменную конфигурации во вновь созданном репозитории; эта переменная устанавливается сразу после инициализации репозитория, но до того, как будет получена внешняя история или будут извлечены какие-либо файлы. <ключ> должен быть в том же формате, что и для 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

Определяет, будут ли клонироваться теги. При использовании --no-tags, это поведение будет сохранено с помощью установки переменной конфигурации remote.<имя>.tagOpt=--no-tags, что гарантирует, что будущие операции git pull и git fetch не будут отслеживать какие-либо метки. Однако в дальнейшем, будет возможна явная загрузка меток (см. git-fetch[1]).

Теги клонируются по умолчанию, так что передача --tags обычно не делает ничего, кроме как переопределяет ранее указанный параметр --no-tags.

Может использоваться совместно с --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=<формат-ссылок>

Задаёт формат хранения ссылок репозитория. Допустимые значения:

  • files: ссылки хранятся в виде несвязанного набора файлов и файла packed-refs. Это формат по умолчанию.

  • reftable: reftable-формат. Этот формат является экспериментальным, и его внутреннее устройство может измениться.

-j <n>
--jobs <n>

Количество подмодулей, которые будут загружаться одновременно. По умолчанию равно значению переменной конфигурации submodule.fetchJobs.

<репозиторий>

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

<каталог>

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

--bundle-uri=<uri>

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

URL-АДРЕСА GIT

В целом, URL-адреса содержат информацию о транспортном протоколе, адресе удалённого сервера и пути к репозиторию. В зависимости от транспортного протокола, некоторые из этих элементов могут отсутствовать.

Git поддерживает следующие протоколы: ssh, git, http и https (кроме того, ftp и ftps могут быть использованы для извлечения из репозиториев, но это неэффективно и является устаревшей (deprecated) возможностью; не используйте эти протоколы).

Родной транспорт (т.е. адреса вида git://) не имеет аутентификации и должен использоваться с осторожностью в незащищённых сетях.

Для этих протоколов может использоваться следующий синтаксис:

  • ssh://[<пользователь>@]<хост>[:<порт>]/<путь-к-репозиторию-git>

  • git://<хост>[:<порт>]/<путь-к-репозиторию-git>

  • http[s]://<хост>[:<порт>]/<путь-к-репозиторию-git>

  • ftp[s]://<хост>[:<порт>]/<путь-к-репозиторию-git>

В качестве альтернативы для протокола ssh можно также использовать scp-подобный синтаксис:

  • [<пользователь>@]<хост>:/<путь-к-репозиторию-git>

Этот синтаксис распознаётся только в том случае, если перед первым двоеточием нет слэшей. Это позволяет отличить его от локального пути, который содержит двоеточие. Например, локальный путь foo:bar можно записан как ./foo:bar или как абсолютный путь, дабы он не был бы ошибочно интерпретирован как ssh-адреса.

Кроме того протоколы ssh и git поддерживают расширение ~<имени-пользователя>:

  • ssh://[<пользователь>@]<хост>[:<порт>]/~<имя-пользователя>/<путь-к-репозиторию-git>

  • git://<хост>[:<порт>]/~<имя-пользователя>/<путь-к-репозиторию-git>

  • [<пользователь>@]<хост>:/~<имя-пользователя>/<путь-к-репозиторию-git>

Для локальных репозиториев, для которых поддержка у Git также родная, могут использоваться следующие варианты синтаксиса:

  • /путь/к/репозиторию.git/

  • file:///путь/к/репозиторию.git/

Эти два синтаксиса по большей части эквивалентны, кроме того что первый подразумевает параметр --local.

git clone, git fetch и git pull, но не git push, также примут сформированный соответствующим образом pack-файл. См. git-bundle[1].

Когда Git не знает, как работать с определённым транспортным протоколом, он пытается использовать вспомогательную программу remote-<транспорт>, помощник работы со внешним репозиторием, если таковая существует. Для явного запроса такого помощника можно использовать следующий синтаксис:

  • <транспорт>::<адрес>

где <адрес> может быть путём, сервером и путём, или произвольной URL-подобной строкой, которая распознаётся конкретным помощником работы с удалённым репозиторием. См. подробности в gitremote-helpers[7].

Если у вас много внешних репозиториев с похожими друг на друга именами, и вы хотите использовать для них свой собственный формат (так, что бы использовать свои собственные удобные вам URL-адреса, которые будут автоматически преобразовываться в те, которые работают), вы можете добавить раздел конфигурации следующего вида:

	[url "<настоящая-база-url>"]
		insteadOf = <другая-база-url>

Например, при такой конфигурации:

	[url "git://git.host.xz/"]
		insteadOf = host.xz:/path/to/
		insteadOf = work:

URL-адрес вида "work:repo.git" или "host.xz:/path/to/repo.git", будет преобразовываться в любом контексте, в котором ожидается URL-адрес, в "git.host.xz/repo.git".

Если вы хотите, чтобы URL-адреса преобразовывались только при отправки изменений во внешний репозиторий, вы можете добавить раздел конфигурации следующего вида:

	[url "<настоящая-база-url>"]
		pushInsteadOf = <другая-база-url>

Например, при такой конфигурации:

	[url "ssh://example.org/"]
		pushInsteadOf = git://example.org/

URL-адрес вида "git://example.org/path/to/repo.git", будет преобразован в "ssh://example.org/path/to/repo.git" для отправки изменений, но при получении изменений будет по-прежнему использоваться оригинальный URL-адрес.

ПРИМЕРЫ

  • Клонирование из вышестоящего репозитория:

    $ 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

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

Дальнейшее содержание этого раздела, повторяет то, что может быть найдено в git-config[1]:

Warning

Missing ru/config/init.adoc

See original version for this content.
Warning

Missing ru/config/clone.adoc

See original version for this content.

GIT

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