українська мова ▾ Topics ▾ Latest version ▾ git-clone last updated in 2.52.0

НАЗВА

git-clone — Клонування репозиторію в нову теку

СИНОПСИС

git clone [--template=<каталог-шаблонів>]
	  [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
	  [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>]
	  [--dissociate] [--separate-git-dir <git-dir>]
	  [--depth <depth>] [--[no-]single-branch] [--[no-]tags]
	  [--recurse-submodules[=<pathspec>]] [--[no-]shallow-submodules]
	  [--[no-]remote-submodules] [--jobs <n>] [--sparse] [--[no-]reject-shallow]
	  [--filter=<filter-spec> [--also-filter-submodules]] [--] <repository>
	  [<directory>]

ОПИС

Клонує репозиторій у новостворену теку, створює гілки віддаленого відстеження для кожної гілки в клонованому репозиторії (можна перевірити за допомогою git branch --remotes), а також створює та отримує початкову гілку, яка є відгалуженням від поточної активної гілки клонованого репозиторію.

Після клонування, команда git fetch без аргументів оновить усі гілки віддаленого відстеження, а команда git pull без аргументів додатково обʼєднає віддалену гілку master з поточною гілкою master, якщо така є (це не стосується випадку, коли вказано --single-branch; див. нижче).

Ця стандартна конфігурація досягається шляхом створення посилань на вершини віддалених гілок у refs/remotes/origin та ініціалізації змінних конфігурації remote.origin.url та remote.origin.fetch.

ОПЦІЇ

-l
--local

Коли репозиторій для клонування знаходиться на локальному компʼютері, цей прапорець оминає звичайний механізм транспортування "Git aware" та клонує репозиторій, створюючи копію HEAD та всього, що знаходиться в теках objects та refs. Файли в теці .git/objects/ є жорсткими посиланнями (hard link) для економії місця, коли це можливо.

Якщо репозиторій вказано як локальний шлях (наприклад, /шлях/до/репозиторію), що є типовим, то --local по суті не має жодного ефекту. Якщо репозиторій вказано як URL-адресу, то цей прапорець ігнорується (і ми ніколи не використовуємо локальні оптимізації). Вказівка --no-local замінить стандартні значення, коли вказано /шлях/до/репозиторію, замість нього використовуватиметься звичайний транспорт Git.

Якщо тека $GIT_DIR/objects репозиторію містить символічні посилання або є символічним посиланням, клонування не вдасться. Це захід безпеки для запобігання ненавмисному копіюванню файлів шляхом розбору символічних посилань.

Ця опція не працює з репозиторіями, що належать іншим користувачам, з міркувань безпеки, і для успішного клонування необхідно вказати --no-local.

ПРИМІТКА: ця операція може змагатися з модифікацією оригінального репозиторію, подібно до виконання cp -r <src> <dst> під час модифікації <src>.

--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, скопіює обʼєкти з вихідного репозиторію в пакунок в клонованому репозиторії, що знищить економію дискового простору від clone --shared. Однак безпечно запускати git gc, який стандартно використовує опцію --local.

Якщо ви хочете розірвати залежність репозиторію, клонованого за допомогою --shared, від його вихідного репозиторію, ви можете просто виконати git repack -a, щоб скопіювати всі обʼєкти з вихідного репозиторію в пакунок у клонованому репозиторії.

--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

Створює «голий» Git-репозиторій. Тобто, замість створення <теки> та розміщення адміністративних файлів у <тека>/.git, зробіть саму <теку> як $GIT_DIR. Це, очевидно, передбачає --no-checkout, оскільки немає ніде переходу до робочого дерева. Також вершини гілок на віддаленому сервері копіюються безпосередньо до відповідних локальних вершин гілок, без зіставлення їх з refs/remotes/origin/. Коли використовується ця опція, не створюються ні гілки віддаленого відстеження, ні повʼязані змінні конфігурації.

--sparse

Використовувати розріджену перевірку, при якій спочатку присутні лише файли в кореневій теці. Команда git-sparse-checkout[1] може бути використана для розширення робочої теки за потреби.

--filter=<filter-spec>

Використовувати функцію часткового клонування та запитувати, щоб сервер надсилав підмножину доступних обʼєктів відповідно до заданого фільтра обʼєктів. Під час використання --filter, наданий <spec-filter> використовується як фільтр для часткового клонування. Наприклад, --filter=blob:none відфільтровуватиме всі блоби (вміст файлу), доки вони не знадобляться Git. Також --filter=blob:limit=<розмір> відфільтровуватиме всі блоби розміром щонайменше <розмір>. Для отримання додаткової інформації про специфікації фільтрів дивіться опцію --filter у git-rev-list[1].

--also-filter-submodules

Також застосовувати фільтр часткового клонування до будь-яких субмодулів у репозиторії. Потрібні --filter та --recurse-submodules. Це можна зробити стандартно увімкненим, встановленням параметра конфігурації clone.filterSubmodules.

--mirror

Встановлює дзеркало вихідного репозиторію. Має на увазі, що використовується --bare. Порівняно з --bare, --mirror не лише зіставляє локальні гілки вихідного коду з локальними гілками цільового репозиторію, але й зіставляє всі посилання (включаючи гілки віддаленого відстеження, нотатки тощо) та встановлює конфігурацію refspec таким чином, що всі ці посилання перезаписуються git remote update у цільовому репозиторії.

-o <імʼя>
--origin <імʼя>

Замість використання віддаленого імені origin для відстеження репозиторію основної платформи, використовується <імʼя>. Замінює clone.defaultRemoteName з конфігурації.

-b <імʼя>
--branch <імʼя>

Замість того щоб встановлювати щойно створений HEAD на гілку, на яку вказує HEAD клонованого репозиторію, вказувати на гілку <імʼя>. У не-голому репозиторії це гілка, яка буде отримана. --branch також може приймати теги та відʼєднувати HEAD у цьому коміті в результуючому репозиторії.

--revision=<ревізія>

Створює новий репозиторій та отримує історію, що веде до вказаної <ревізії> (і нічого більше), без створення жодної гілки для віддаленого відстеження та без створення жодної локальної гілки, та від’єднує HEAD від <ревізії>. Аргументом може бути ім’я посилання (наприклад, refs/heads/main або refs/tags/v1.0), яке зводиться до коміту, або шістнадцяткове імʼя обʼєкта. Цей параметр несумісний з --branch та --mirror.

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

Якщо вказано, і доступ до репозиторію для клонування здійснюється через ssh, це вказує на шлях, відмінний від стандартного, для команди, що виконується на іншому кінці.

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

Вкажіть теку, з якого будуть використовуватися шаблони; (Див. розділ "ТЕКА ШАБЛОНІВ" у git-init[1].)

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

Встановлює змінну конфігурації у щойно створеному репозиторії; вона набуде чинності одразу після ініціалізації репозиторію, але до отримання історії віддаленого репозиторію або отримання будь-яких файлів. <ключ> має той самий формат, що й очікується git-config[1] (наприклад, core.eol=true). Якщо для одного ключа задано кілька значень, кожне значення буде записано у файл конфігурації. Це робить безпечним, наприклад, додавання додаткових специфікацій fetch refspecs до вихідного віддаленого репозиторію.

Через обмеження поточної реалізації деякі змінні конфігурації не набувають чинності до початкового отримання (fetch) та перевірки стану (checkout). Змінні конфігурації remote.<name>.mirror та remote.<name>.tagOpt не набувають чинності. Натомість використовуйте відповідні опції --mirror та --no-tags.

--depth <глибина>

Створює поверхневий клон з історією, скороченою до вказаної кількості комітів. Має на увазі --single-branch, якщо не вказано --no-single-branch для отримання історій поблизу вершин усіх гілок. Якщо ви хочете поверхнево клонувати субмодулі, також передайте --shallow-submodules.

--shallow-since=<дата>

Створює поверхневий клон з історією після зазначеного часу.

--shallow-exclude=<посилання>

Створює поверхневий клон з історією, виключаючи коміти, доступні з вказаної віддаленої гілки або тегу. Цей параметр можна вказати кілька разів.

--single-branch
--no-single-branch

Клонувати лише історію, що веде до вершини однієї гілки, або зазначеної опцією --branch, або віддаленою гілкою, на яку вказує HEAD первинної гілки. Подальші вибірки до результуючого репозиторію оновлюватимуть лише гілку віддаленого відстеження для тієї гілки, для якої ця опція використовувалася для початкового клонування. Якщо HEAD на віддаленій гілці не вказував на жодну гілку під час створення клону --single-branch, гілка віддаленого відстеження не створюється.

--tags
--no-tags

Визначає, чи будуть клоновані теги. Якщо задано параметр --no-tags, цей параметр стане постійним шляхом встановлення конфігурації remote.<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)

--shallow-submodules
--no-shallow-submodules

Усі клоновані субмодулі будуть поверхневими з глибиною 1.

--remote-submodules
--no-remote-submodules

Усі клоновані субмодулі використовуватимуть статус гілки віддаленого відстеження субмодуля для оновлення, а не записаний SHA-1 суперпроєкту. Еквівалентно використанню --remote з git submodule update.

--separate-git-dir=<git-dir>

Замість того щоб розміщувати клонований репозиторій там, де він має бути, розмістить його у вказаній теці, а потім створіть символічне посилання Git, незалежно від файлової системи. В результаті репозиторій Git можна відокремити від робочого дерева.

--ref-format=<формат-посилання>

Задає формат зберігання посилань для репозиторію. Допустимі значення:

  • files для окремих файлів з упакованими посиланнями. Це стандартне значення.

  • reftable для формату reftable. Цей формат є експериментальним, і його внутрішня структура може бути змінена.

-j <n>
--jobs <n>

Кількість субмодулів, що можна отримувати одночасно. Стандартне значення визначається опцією submodule.fetchJobs.

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

(Можливо, віддалений) <репозиторій>, з якого потрібно клонувати. Див. розділ GIT URLs нижче для отримання додаткової інформації про визначення репозиторіїв.

<тека>

Назва нової теки для клонування. Частина "humanish" вихідного репозиторію використовується, якщо явно не вказано <теку> (repo для /шлях/до/repo.git та foo для host.xz:foo/.git). Клонування в наявну теку дозволено, лише якщо тека порожня.

--bundle-uri=<uri>

Перед отриманням даних з віддаленого репозиторію, отримує пакунок з вказаного <uri> та розпаковує дані в локальному репозиторії. Посилання в пакунку будуть зберігатися в прихованому просторі імен refs/bundle/*. Цей параметр несумісний з --depth, --shallow-since та --shallow-exclude.

GIT URLS

Загалом, URL-адреси містять інформацію про транспортний протокол, адресу віддаленого сервера та шлях до репозиторію. Залежно від транспортного протоколу, деяка інформація може бути відсутня.

Git підтримує протоколи ssh, git, http та https (крім того, для отримання даних можна використовувати ftp та ftps, але це неефективно та застаріло; не використовуйте їх).

Власний транспорт (тобто URL-адреса git://) не виконує автентифікацію та має використовуватися з обережністю в незахищених мережах.

З ними можна використовувати такі синтаксичні схеми:

  • ssh://[<user>@]<host>[:<port>]/<path-to-git-repo>

  • git://<host>[:<port>]/<path-to-git-repo>

  • http[s]://<host>[:<port>]/<path-to-git-repo>

  • ftp[s]://<host>[:<port>]/<path-to-git-repo>

Альтернативний синтаксис, подібний до scp, також може використовуватися з протоколом ssh:

  • [<user>@]<host>:/<path-to-git-repo>

Цей синтаксис розпізнається лише за відсутності скісних рисок перед першою двокрапкою. Це допомагає розрізнити локальний шлях, який містить двокрапку. Наприклад, локальний шлях foo:bar можна вказати як абсолютний шлях або ./foo:bar, щоб уникнути неправильної інтерпретації як URL-адреси ssh.

Протоколи ssh та git додатково підтримують розширення ~<імʼя користувача>:

  • ssh://[<user>@]<host>[:<port>]/~<user>/<path-to-git-repo>

  • git://<host>[:<port>]/~<user>/<path-to-git-repo>

  • [<user>@]<host>:~<user>/<path-to-git-repo>

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

  • /path/to/repo.git/

  • file:///path/to/repo.git/

Ці два синтаксичні варіанти здебільшого еквівалентні, за винятком того, що перший передбачає опцію --local.

Команди git clone, git fetch та git pull, але не git push, також прийматимуть відповідний файл пакунка. Див. git-bundle[1].

Коли Git не знає, як обробляти певний транспортний протокол, він намагається використати віддалений помічник remote-<transport>, якщо такий існує. Щоб явно звернутись до віддаленого помічника, можна використовувати наступний синтаксис:

  • <transport>::<address>

де <адреса> може бути шляхом, сервером та шляхом або довільним рядком, подібним до URL-адреси, який розпізнає конкретний викликаний віддалений помічник. Див. gitremote-helpers[7] для отримання детальної інформації.

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

	[url "<actual-url-base>"]
		insteadOf = <other-url-base>

Наприклад, з цим:

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

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

Якщо ви хочете переписати URL-адреси лише для push, ви можете створити розділ конфігурації:

	[url "<actual-url-base>"]
		pushInsteadOf = <other-url-base>

Наприклад, з цим:

	[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]. Вміст такий самий, як і там:

init.templateDir

Вкажіть теку, з якої будуть скопійовані шаблони. (See the "TEMPLATE DIRECTORY" section of git-init[1].)

init.defaultBranch

Дозволяє перевизначити назву стандартної гілки, наприклад, під час ініціалізації нового репозиторію.

init.defaultObjectFormat

Дозволяє перевизначати стандартний формат обʼєктів для нових репозиторіїв. Див. --object-format= у git-init[1]. Як параметр командного рядка, так і змінна середовища GIT_DEFAULT_HASH мають пріоритет над цією конфігурацією.

init.defaultRefFormat

Дозволяє перевизначити стандартний формат зберігання посилань для нових репозиторіїв. Див. --ref-format= у git-init[1]. Як параметр командного рядка, так і змінна середовища GIT_DEFAULT_REF_FORMAT мають пріоритет над цією конфігурацією.

clone.defaultRemoteName

Імʼя віддаленого сервера, який потрібно створити під час клонування репозиторію. Стандартно — origin. Його можна перевизначити, передавши опцію --origin у командному рядку

clone.rejectShallow

Відхиляє клонування репозиторію, якщо він поверхневий; це можна змінити, передавши опцію --reject-shallow у командному рядку.

clone.filterSubmodules

Якщо надано фільтр часткового клонування (див. --filter у git-rev-list[1]) та використовується --recurse-submodules, також застосовує фільтр до субмодулів.

GIT

Частина набору git[1]