Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.49.1 → 2.51.0 no changes
-
2.49.0
2025-03-14
- 2.48.1 → 2.48.2 no changes
-
2.48.0
2025-01-10
- 2.47.1 → 2.47.3 no changes
-
2.47.0
2024-10-06
- 2.46.1 → 2.46.4 no changes
-
2.46.0
2024-07-29
- 2.45.1 → 2.45.4 no changes
-
2.45.0
2024-04-29
- 2.44.1 → 2.44.4 no changes
-
2.44.0
2024-02-23
- 2.43.1 → 2.43.7 no changes
-
2.43.0
2023-11-20
- 2.41.1 → 2.42.4 no changes
-
2.41.0
2023-06-01
- 2.38.1 → 2.40.4 no changes
-
2.38.0
2022-10-02
- 2.36.1 → 2.37.7 no changes
-
2.36.0
2022-04-18
- 2.35.1 → 2.35.8 no changes
-
2.35.0
2022-01-24
- 2.32.1 → 2.34.8 no changes
-
2.32.0
2021-06-06
- 2.30.2 → 2.31.8 no changes
-
2.30.1
2021-02-08
-
2.30.0
2020-12-27
- 2.29.1 → 2.29.3 no changes
-
2.29.0
2020-10-19
- 2.28.1 no changes
-
2.28.0
2020-07-27
- 2.27.1 no changes
-
2.27.0
2020-06-01
- 2.25.1 → 2.26.3 no changes
-
2.25.0
2020-01-13
- 2.23.1 → 2.24.4 no changes
-
2.23.0
2019-08-16
- 2.22.2 → 2.22.5 no changes
-
2.22.1
2019-08-11
-
2.22.0
2019-06-07
- 2.21.1 → 2.21.4 no changes
-
2.21.0
2019-02-24
- 2.18.1 → 2.20.5 no changes
-
2.18.0
2018-06-21
- 2.17.0 → 2.17.6 no changes
-
2.16.6
2019-12-06
- 2.15.4 no changes
-
2.14.6
2019-12-06
-
2.13.7
2018-05-22
- 2.12.5 no changes
-
2.11.4
2017-09-22
- 2.10.5 no changes
-
2.9.5
2017-07-30
-
2.8.6
2017-07-30
-
2.7.6
2017-07-30
- 2.4.12 → 2.6.7 no changes
-
2.3.10
2015-09-28
- 2.1.4 → 2.2.3 no changes
-
2.0.5
2014-12-17
СИНОПСИС
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
-
Коли репозиторій для клонування знаходиться на локальному комп’ютері, замість використання жорстких посилань, автоматично налаштуйте
.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 See original version for this content. |
Warning
|
Missing See original version for this content. |
GIT
Частина набору git[1]