українська мова ▾ Topics ▾ Latest version ▾ git-clone last updated in 2.54.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 для спільного використання обʼєктів з вихідним репозиторієм. Отриманий репозиторій спочатку працюватиме без жодного власного обʼєкта.

Note
 це потенційно небезпечна операція; не використовуйте її, якщо не розумієте, що вона робить. Якщо ви клонували репозиторій з цією опцією і потім видалили гілки (або використали будь-яку іншу команду 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=<repository>
--reference-if-able=<repository>

Якщо посилання <репозиторій> знаходиться на локальному компʼютері, автоматично налаштовує .git/objects/info/alternates так, щоб отримувати обʼєкти з посилання <репозиторій>. Використання вже наявного репозиторію як альтернативного вимагатиме менше обʼєктів для копіювання з репозиторію, що клонується, зменшуючи мережеві та локальні витрати на зберігання. При використанні --reference-if-able, відсутня тека пропускається з попередженням замість того, щоб переривати клонування.

Note
 див. ПРИМІТКУ щодо опції --shared, а також опції --dissociate.
--dissociate

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

-q
--quiet

Працює тихо. Прогрес не зʼявляється у стандартному потоці помилок.

-v
--verbose

Виконується з детальним виводом. Не впливає на звіт про статус прогресу в стандартний потік помилок.

--progress

Зазвичай повідомляє про хід виконання у стандартному потоці помилок при підключенні до терміналу, якщо не вказано параметр --quiet. Цей параметр примусово вмикає показ інформації про хід виконання, навіть якщо стандартний потік помилок не спрямований на термінал.

--server-option=<опція>

Передавати вказаний рядок на сервер під час зв’язку за допомогою протоколу версії 2. Вказаний рядок не повинен містити символів NUL або LF. Обробка сервером опцій, включаючи невідомі, залежить від конкретного сервера. Якщо вказано декілька --server-option=<option>, вони всі надсилаються на інший бік у порядку, вказаному в командному рядку. Якщо в командному рядку не вказано --server-option=<option>, замість цього використовуються значення змінної конфігурації remote.<name>.serverOption.

-n
--no-checkout

Не перемикатись на HEAD після завершення клонування.

--no-reject-shallow
--reject-shallow

Завершиться з помилкою, якщо вихідний репозиторій є поверхневим репозиторієм. Змінну конфігурації clone.rejectShallow можна використовувати для визначення типово значення.

--bare

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

--sparse

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

--filter=<filter-spec>

Використовувати функцію часткового клонування та запитувати сервер надіслати підмножину доступних обʼєктів відповідно до заданого фільтра обʼєктів. При використанні параметра --filter для фільтра часткового клонування застосовується вказаний <filter-spec>.

Якщо використовується параметр --filter=auto, специфікація фільтра визначається автоматично за допомогою протоколу promisor-remote (див. gitprotocol-v2[5]) шляхом об’єднання специфікацій фільтрів, оголошених сервером для віддалених репозиторіїв-обіцянок, які клієнт приймає (див. параметр конфігурації promisor.acceptFromServer у git-config[1]). Це дозволяє серверу запропонувати оптимальний фільтр для доступних віддалених серверів-обіцяльників.

Як і в разі інших параметрів фільтра, значення «auto» зберігається в конфігурації. Це гарантує, що під час наступних запитів система й надалі буде враховувати поточні рекомендації сервера.

Детальнішу інформацію про всі інші доступні специфікації фільтрів див. в описі параметра --filter=<filter-spec> у документації git-rev-list[1].

Наприклад, параметр --filter=blob:none відфільтрує всі блоби (вміст файлів), доки вони не знадобляться Git. Крім того, параметр --filter=blob:limit=<size> відфільтрує всі блоби розміром не менше <size>.

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