українська мова ▾ 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 <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/ жорстко пов’язані для економії місця, коли це можливо.

Якщо репозиторій вказано як локальний шлях (наприклад, /шлях/до/репозиторію), це значення за замовчуванням, а --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] <репозиторій>

Якщо посилання <repository> знаходиться на локальному комп’ютері, автоматично налаштувати .git/objects/info/alternates для отримання об’єктів з посилання <repository>. Використання вже існуючого репозиторію як альтернативного вимагатиме копіювання меншої кількості об’єктів з клонованого репозиторію, що зменшить витрати на мережеве та локальне сховище. Під час використання --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

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

--filter=<filter-spec>

Використовуйте функцію часткового клонування та запитуйте, щоб сервер надсилав підмножину доступних об’єктів відповідно до заданого фільтра об’єктів. Під час використання --filter, наданий <spec-filter> використовується для фільтра часткового клонування. Наприклад, --filter=blob:none відфільтровуватиме всі блоби (вміст файлу), доки вони не знадобляться Git. Також --filter=blob:limit=<size> відфільтровуватиме всі блоби розміром щонайменше <size>. Для отримання додаткової інформації про специфікації фільтрів дивіться опцію --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=<оборот>

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

-u <upload-pack>
--upload-pack <завантажувальний пакет>

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

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

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

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

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

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

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

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

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

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

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

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

--[no-]single-branch

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

--[no-]tags

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

За замовчуванням теги клонуються, і передача --tags зазвичай є забороненою, якщо тільки вона не скасовує попередню передачу --no-tags.

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

--recurse-submodules[=<специфікація шляху>]

Після створення клону, ініціалізуйте та клонуйте підмодулі всередині нього на основі наданої специфікації шляху (<pathspec>). Якщо не вказано параметр =<pathspec>, усі підмодулі ініціалізуються та клонуються. Цей параметр можна використовувати кілька разів для специфікацій шляху, що складаються з кількох записів. У результуючому клоні submodule.active встановлено на надану специфікацію шляху або "." (тобто всі підмодулі), якщо специфікація шляху не вказана.

Підмодулі ініціалізуються та клонуються з використанням їхніх налаштувань за замовчуванням. Це еквівалентно запуску git submodule update --init --recursive <pathspec> одразу після завершення клонування. Цей параметр ігнорується, якщо клонований репозиторій не має робочого дерева/видачі (тобто, якщо вказано будь-який з параметрів --no-checkout/-n, --bare або --mirror)

--[no-]shallow-submodules

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

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

Warning

Missing uk/config/init.adoc

See original version for this content.
Warning

Missing uk/config/clone.adoc

See original version for this content.

GIT

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