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.51.0
2025-08-18
- 2.50.1 no changes
-
2.50.0
2025-06-16
- 2.49.1 no changes
-
2.49.0
2025-03-14
- 2.48.1 → 2.48.2 no changes
-
2.48.0
2025-01-10
- 2.47.2 → 2.47.3 no changes
-
2.47.1
2024-11-25
- 2.46.3 → 2.47.0 no changes
-
2.46.2
2024-09-23
- 2.45.1 → 2.46.1 no changes
-
2.45.0
2024-04-29
- 2.44.1 → 2.44.4 no changes
-
2.44.0
2024-02-23
- 2.43.2 → 2.43.7 no changes
-
2.43.1
2024-02-09
-
2.43.0
2023-11-20
- 2.42.1 → 2.42.4 no changes
-
2.42.0
2023-08-21
- 2.41.1 → 2.41.3 no changes
-
2.41.0
2023-06-01
- 2.40.1 → 2.40.4 no changes
-
2.40.0
2023-03-12
- 2.36.1 → 2.39.5 no changes
-
2.36.0
2022-04-18
- 2.35.1 → 2.35.8 no changes
-
2.35.0
2022-01-24
- 2.34.1 → 2.34.8 no changes
-
2.34.0
2021-11-15
- 2.33.2 → 2.33.8 no changes
-
2.33.1
2021-10-12
-
2.33.0
2021-08-16
- 2.32.1 → 2.32.7 no changes
-
2.32.0
2021-06-06
- 2.31.1 → 2.31.8 no changes
-
2.31.0
2021-03-15
- 2.30.1 → 2.30.9 no changes
-
2.30.0
2020-12-27
- 2.29.1 → 2.29.3 no changes
-
2.29.0
2020-10-19
- 2.27.1 → 2.28.1 no changes
-
2.27.0
2020-06-01
- 2.25.2 → 2.26.3 no changes
-
2.25.1
2020-02-17
-
2.25.0
2020-01-13
- 2.24.1 → 2.24.4 no changes
-
2.24.0
2019-11-04
- 2.23.1 → 2.23.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.20.1 → 2.21.4 no changes
-
2.20.0
2018-12-09
- 2.19.1 → 2.19.6 no changes
-
2.19.0
2018-09-10
- 2.18.1 → 2.18.5 no changes
-
2.18.0
2018-06-21
- 2.17.1 → 2.17.6 no changes
-
2.17.0
2018-04-02
-
2.16.6
2019-12-06
-
2.15.4
2019-12-06
-
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.6.7
2017-05-05
- 2.5.6 no changes
-
2.4.12
2017-05-05
-
2.3.10
2015-09-28
- 2.2.3 no changes
-
2.1.4
2014-12-17
-
2.0.5
2014-12-17
ОПИС
Включає зміни з віддаленого репозиторію до поточної гілки. Якщо поточна гілка знаходиться за віддаленою, то за замовчуванням буде перемотувано поточну гілку вперед, щоб вона відповідала віддаленій. Якщо поточна гілка та віддалена розійшлися, користувачеві потрібно вказати, як узгодити розбіжні гілки за допомогою --rebase
або --no-rebase
(або відповідного параметра конфігурації в pull.rebase
).
Точніше, git
pull
запускає git
fetch
із заданими параметрами, а потім, залежно від опцій конфігурації або прапорців командного рядка, викликає git
rebase
або git
merge
для узгодження розбіжних гілок.
<repository> має бути назвою віддаленого репозиторію, як передається до git-fetch[1]. <refspec> може називати довільне віддалене посилання (наприклад, назву тегу) або навіть колекцію посилань з відповідними гілками віддаленого відстеження (наприклад, refs/heads/*:refs/remotes/origin/*), але зазвичай це назва гілки у віддаленому репозиторії.
Значення за замовчуванням для <repository> та <branch> зчитуються з конфігурації "remote" та "merge" для поточної гілки, як встановлено параметром git-branch[1] --track
.
Припустимо, що існує наступна історія, а поточна гілка є "master
":
A---B---C майстер походження / D---E---F---G master ^ origin/master у вашому репозиторії
Потім "git
pull
" отримає та відтворить зміни з віддаленої гілки master
з моменту її відхилення від локальної master
(тобто E
) до її поточного коміту (C
) поверх master
та запише результат у новий коміт разом з іменами двох батьківських комітів та повідомленням журналу від користувача, що описує зміни.
A---B---C origin/master / \ D---E---F---G---H master
Див. git-merge[1] для отримання детальної інформації, зокрема про те, як представлені та оброблені конфлікти.
У Git 1.7.0 або пізнішої версії, щоб скасувати конфліктуюче злиття, використовуйте git
reset
--merge
. Попередження: У старіших версіях Git не рекомендується запускати git pull з незакоміченими змінами: хоча це можливо, це залишає вас у стані, з якого може бути важко вийти у разі конфлікту.
Якщо будь-які віддалені зміни перетинаються з локальними незафіксованими змінами, злиття буде автоматично скасовано, а дерево робіт залишиться недоторканим. Зазвичай найкраще привести будь-які локальні зміни до робочого стану, перш ніж витягувати або зберігати їх за допомогою git-stash[1].
ОПЦІЇ
- -q
- --quiet
-
Це передається як базовому git-fetch для приглушення звітів під час передачі, так і базовому git-merge для приглушення виводу під час злиття.
- -v
- --verbose
-
Передати --verbose до git-fetch та git-merge.
- --[no-]recurse-submodules[=(yes|on-demand|no)]
-
Цей параметр контролює, чи слід отримувати нові коміти заповнених підмодулів, а також чи слід оновлювати робочі дерева активних підмодулів (див. git-fetch[1], git-config[1] та gitmodules[5]).
Якщо отримання виконується через перебазування, локальні коміти підмодулів також перебазуються.
Якщо оновлення виконується через злиття, конфлікти підмодулів вирішуються та перевіряються.
Варіанти, пов’язані з об’єднанням
-
--commit
-
--no-commit
-
Виконайте об’єднання та зафіксуйте результат. Цей параметр можна використовувати для перевизначення
--no-commit
. Корисно лише під час об’єднання.За допомогою параметра
--no-commit
виконайте злиття та зупиніть його безпосередньо перед створенням коміту злиття, щоб дати користувачеві можливість перевірити та додатково налаштувати результат злиття перед комітом.Зверніть увагу, що оновлення вперед не створюють коміту злиття, і тому немає способу зупинити ці злиття за допомогою
--no-commit
. Таким чином, якщо ви хочете переконатися, що ваша гілка не буде змінена або оновлена командою merge, використовуйте--no-ff
з--no-commit
. -
--edit
-
-e
-
--no-edit
-
Перед успішним механічним злиттям викличте редактор для подальшого редагування автоматично згенерованого повідомлення про злиття, щоб користувач міг пояснити та обґрунтувати злиття. Для прийняття автоматично згенерованого повідомлення можна використовувати параметр
--no-edit
(зазвичай це не рекомендується).Старіші скрипти можуть залежати від історичної поведінки, яка забороняла користувачеві редагувати повідомлення журналу злиття. Вони побачать відкритий редактор під час запуску
git
merge
. Щоб полегшити налаштування таких скриптів відповідно до оновленої поведінки, змінну середовищаGIT_MERGE_AUTOEDIT
можна встановити наno
на початку їх. -
--cleanup=
<режим> -
Цей параметр визначає, як повідомлення злиття буде очищено перед комітом. Див. git-commit[1] для отримання додаткової інформації. Крім того, якщо <mode> має значення
scissors
, scissors буде додано доMERGE_MSG
перед передачею до механізму коміту у разі конфлікту злиття. -
--ff-only
-
Оновлювати до нової історії лише за відсутності розбіжної локальної історії. Це значення за замовчуванням, коли не передбачено методу узгодження розбіжних історій (через прапорці --rebase=*).
-
--ff
-
--no-ff
-
Під час злиття, а не перебазування, вказує, як обробляється злиття, коли об’єднана історія вже є нащадком поточної історії. Якщо запитується злиття,
--ff
є значенням за замовчуванням, якщо не об’єднується анотований (і, можливо, підписаний) тег, який не зберігається на своєму природному місці в ієрархіїrefs/tags/
, у цьому випадку передбачається--no-ff
.За допомогою параметра
--ff
, коли можливо, виконувати злиття як перемотування вперед (оновлювати лише вказівник гілки, щоб він відповідав об’єднаній гілці; не створювати коміт злиття). Якщо неможливо (коли історія об’єднання не є нащадком поточної історії), створювати коміт злиття.З опцією
--no-ff
створюється коміт злиття у всіх випадках, навіть якщо злиття можна було б виконати як перемотування вперед. -
-S
[<key-id>] -
--gpg-sign
[=
<key-id>] -
--no-gpg-sign
-
Підписує результуючий коміт злиття GPG. Аргумент <key-id> є необов’язковим і за замовчуванням використовує ідентифікатор комітера; якщо його вказано, він має бути прив’язаний до опції без пробілу.
--no-gpg-sign
корисний для скасування як змінної конфігураціїcommit.gpgSign
, так і попередньої змінної--gpg-sign
. -
--log
[=
<n>] -
--no-log
-
Окрім назв гілок, заповніть повідомлення журналу однорядковими описами максимум з <n> фактичних комітів, що об’єднуються. Див. також git-fmt-merge-msg[1]. Корисно лише під час об’єднання.
З опцією
--no-log
не виводьте однорядкові описи з фактичних комітів, що об’єднуються. -
--signoff
-
--no-signoff
-
Додайте трейлер «Підписано» коміттером в кінці повідомлення журналу комітів. Значення підпису залежить від проекту, в який ви робите коміт. Наприклад, він може засвідчувати, що коміттер має права надсилати роботу за ліцензією проекту або погоджується на певні заяви учасників, такі як Сертифікат походження розробника. (Див. https://developercertificate.org для отримання інформації про той, що використовується проектами ядра Linux та Git.) Зверніться до документації або керівництва проекту, в який ви робите внесок, щоб зрозуміти, як підписи використовуються в цьому проекті.
Опцію
--no-signoff
можна використовувати для скасування попередньої опції--signoff
у командному рядку.
-
--stat
-
-n
-
--no-stat
-
Показати diffstat в кінці злиття. diffstat також контролюється параметром конфігурації merge.stat.
З опціями
-n
або--no-stat
не відображати статистику змін (diffstat) в кінці злиття. -
--compact-summary
-
Показати компактний зведений опис в кінці злиття.
-
--squash
-
--no-squash
-
Створіть робоче дерево та стан індексу так, ніби відбулося справжнє злиття (за винятком інформації про злиття), але фактично не створюйте коміт, не переміщуйте
HEAD
та не записуйте$GIT_DIR/MERGE_HEAD
(щоб наступна командаgit
commit
створила коміт злиття). Це дозволяє створити один коміт поверх поточної гілки, ефект якого такий самий, як і злиття іншої гілки (або кількох у випадку octopus).За допомогою
--no-squash
виконати злиття та зафіксувати результат. Цей параметр можна використовувати для перевизначення--squash
.З
--squash
,--commit
не дозволено і призведе до невдачі.Корисно лише під час об’єднання.
-
--
[no-
]verify
-
За замовчуванням виконуються перехоплювачі pre-merge та commit-msg. Коли задано
--no-verify
, вони ігноруються. Див. також githooks[5]. Корисно лише під час об’єднання. -
-s
<стратегія> -
--strategy=
<стратегія> -
Використовуйте задану стратегію злиття; можна вказати більше одного разу, щоб вказати їх у порядку, в якому їх слід спробувати. Якщо немає опції
-s
, замість неї використовується вбудований список стратегій (ort
під час злиття однієї голови,octopus
в іншому випадку). -
-X
<option> -
--strategy-option=
<option> -
Передати специфічний для стратегії злиття параметр до стратегії злиття.
-
--verify-signatures
-
--no-verify-signatures
-
Перевірте, чи коміт tip бічної гілки, що об’єднується, підписаний дійсним ключем, тобто ключем з дійсним UID: у моделі довіри за замовчуванням це означає, що ключ підпису був підписаний довіреним ключем. Якщо коміт tip бічної гілки не підписаний дійсним ключем, злиття переривається.
Корисно лише під час об’єднання.
-
--summary
-
--no-summary
-
Синоніми до
--stat
та--no-stat
; вони застарілі та будуть видалені в майбутньому. -
--autostash
-
--no-autostash
-
Автоматично створіть тимчасовий запис stash перед початком операції, запишіть його в посилання
MERGE_AUTOSTASH
та застосуйте його після завершення операції. Це означає, що ви можете виконати операцію на непрацюючому робочому дереві. Однак використовуйте обережно: остаточне застосування stash після успішного злиття може призвести до нетривіальних конфліктів. -
За замовчуванням команда
git
merge
відмовляється об’єднувати історії, які не мають спільного предка. Цей параметр можна використовувати для ігнорування цього захисту під час об’єднання історій двох проектів, які розпочали своє життя незалежно. Оскільки це трапляється дуже рідко, змінної конфігурації, яка б увімкнула це за замовчуванням, не існує та не буде додано.Корисно лише під час об’єднання.
- -r
- --rebase[=(false|true|merges|interactive)]
-
Якщо значення true, перебазувати поточну гілку поверх гілки вище за течією після отримання даних. Якщо існує гілка віддаленого відстеження, що відповідає гілці вище за течією, і гілка вище за течією була перебазована з моменту останньої отримання даних, перебазування використовує цю інформацію, щоб уникнути перебазування нелокальних змін.
Якщо встановлено значення
merges
, перебазуйте за допомогоюgit
rebase
--rebase-merges
, щоб локальні коміти злиття були включені до перебазування (див. git-rebase[1] для отримання детальнішої інформації).Якщо значення false, об’єднати гілку вище за течією з поточною гілкою.
Коли встановлено значення
interactive
, увімкнути інтерактивний режим перебазування.Дивіться
pull.rebase
,branch.
<name>.rebase
таbranch.autoSetupRebase
у git-config[1], якщо ви хочете, щобgit
pull
завжди використовував--rebase
замість злиття.NoteЦе потенційно небезпечний режим роботи. Він переписує історію, що не віщує нічого доброго, враховуючи, що ви вже опублікували цю історію. Не використовуйте цю опцію, якщо ви уважно не прочитали git-rebase[1]. - --no-rebase
-
Це скорочення від --rebase=false.
Параметри, пов’язані з вилученням
- --[no-]all
-
Отримати всі віддалені пристрої, крім тих, для яких встановлено змінну конфігурації
remote.
<назва>.skipFetchAll
. Це замінює змінну конфігурації fetch.all`. - -a
- --append
-
Додати назви посилань та назви об’єктів отриманих посилань до існуючого вмісту
.git/FETCH_HEAD
. Без цієї опції старі дані в.git/FETCH_HEAD
будуть перезаписані. - --atomic
-
Використовуйте атомарну транзакцію для оновлення локальних посилань. Або всі посилання оновлюються, або у разі помилки жодні посилання не оновлюються.
- --depth=<depth>
-
Обмежити вибірку до вказаної кількості комітів з кінчика історії кожної віддаленої гілки. Якщо вибірка здійснюється до «неглибокого» репозиторію, створеного за допомогою
git
clone
з опцією--depth=
<глибина> (див. git-clone[1]), поглибити або скоротити історію до вказаної кількості комітів. Теги для поглиблених комітів не витягуються. - --deepen=<depth>
-
Подібно до --depth, але вказує кількість комітів з поточної неглибокої межі, а не з кінця історії кожної віддаленої гілки.
- --shallow-since=<дата>
-
Поглибити або скоротити історію поверхневого репозиторію, щоб включити всі доступні коміти після <дата>.
- --shallow-exclude=<посилання>
-
Поглибити або скоротити історію поверхневого репозиторію, щоб виключити коміти, доступні з вказаної віддаленої гілки або тегу. Цей параметр можна вказати кілька разів.
- --unshallow
-
Якщо вихідний репозиторій завершений, конвертуйте поверхневий репозиторій у повноцінний, усунувши всі обмеження, що накладаються поверхневими репозиторіями.
Якщо вихідний репозиторій неглибокий, витягніть якомога більше даних, щоб поточний репозиторій мав таку ж історію, як і вихідний репозиторій.
- --update-shallow
-
За замовчуванням, під час отримання даних з поверхневого репозиторію,
git
fetch
відхиляє посилання, які потребують оновлення .git/shallow. Ця опція оновлює .git/shallow та приймає такі посилання. - --negotiation-tip=<commit|glob>
-
За замовчуванням Git повідомлятиме серверу про коміти, доступні з усіх локальних посилань, щоб знайти спільні коміти та спробувати зменшити розмір отриманого пакет-файлу. Якщо вказано, Git повідомлятиме лише про коміти, доступні з заданих посилань. Це корисно для пришвидшення завантаження, коли користувач знає, яке локальне посилання, ймовірно, має спільні коміти з посиланням, що вибирається.
Цей параметр можна вказати більше одного разу; якщо так, Git повідомить про коміти, доступні з будь-якого з заданих комітів.
Аргументом цієї опції може бути глобус на іменах посилань, посилання або (можливо, скорочено) SHA-1 коміта. Вказівка глобуса еквівалентна багаторазовому вказуванню цієї опції, по одному для кожного відповідного імені посилання.
Дивіться також змінні конфігурації
fetch.negotiationAlgorithm
таpush.negotiate
, задокументовані в git-config[1], та опцію--negotiate-only
нижче. - --negotiate-only
-
Не отримувати нічого з сервера, а натомість виводити предків наданих аргументів
--negotiation-tip=*
, які є спільними з сервером.Це несумісно з
--recurse-submodules=
[yes
|on-demand
]. Внутрішньо це використовується для реалізації опціїpush.negotiate
, див. git-config[1]. - --dry-run
-
Покажіть, що буде зроблено без внесення жодних змін.
- --porcelain
-
Вивести вивід на стандартний вивід у зручному для розбору форматі для скриптів. Див. розділ ВИВІД у git-fetch[1] для отримання детальної інформації.
Це несумісно з
--recurse-submodules=
[yes
|on-demand
] та має пріоритет над параметром конфігураціїfetch.output
. - -f
- --force
-
Коли git fetch використовується з <src>
:
<dst> refspec, він може відмовитися оновлювати локальну гілку, як обговорювалося in the <refspec> part of the git-fetch[1] документація. Цей параметр замінює цю перевірку. - -k
- --keep
-
Збережіть завантажений пакет.
- --prefetch
-
Змініть налаштовану специфікацію посилань, щоб розмістити всі посилання в просторі імен
refs/prefetch/
. Див. завданняprefetch
у git-maintenance[1]. - -p
- --prune
-
Перед отриманням видаліть усі посилання на віддалене відстеження, яких більше немає на віддаленому сервері. Теги не підлягають обрізанню, якщо вони отримані лише через автоматичне слідування за тегами за замовчуванням або через опцію --tags. Однак, якщо теги отримані через явну специфікацію посилань (або в командному рядку, або в конфігурації віддаленого сервера, наприклад, якщо віддалений сервер було клоновано з опцією --mirror), то вони також підлягають обрізанню. Надання
--prune-tags
– це скорочення для надання специфікації посилань на теги. - --no-tags
-
За замовчуванням теги, що вказують на об’єкти, завантажені з віддаленого репозиторію, отримуються та зберігаються локально. Ця опція вимикає автоматичне відстеження тегів. Поведінку за замовчуванням для віддаленого репозиторію можна вказати за допомогою параметра remote.<name>.tagOpt. Див. git-config[1].
- --refmap=<refspec>
-
Під час отримання посилань, перелічених у командному рядку, використовуйте вказану специфікацію посилань (можна вказати більше одного разу) для зіставлення посилань з гілками віддаленого відстеження, замість значень змінних конфігурації
remote.*.fetch
для віддаленого репозиторію. Надання порожньої <refspec> для опції--refmap
призведе до того, що Git ігноруватиме налаштовані специфікації посилань та повністю покладатиметься на специфікації посилань, надані як аргументи командного рядка. Див. розділ "Налаштовані гілки віддаленого відстеження" для отримання детальної інформації. - -t
- --tags
-
Отримати всі теги з віддаленого сервера (тобто отримати віддалені теги
refs/tags/*
у локальні теги з такою ж назвою), на додаток до всього іншого, що було б отримано в іншому випадку. Використання лише цієї опції не призводить до обрізання тегів, навіть якщо використовується --prune (хоча теги можуть бути обрізані в будь-якому випадку, якщо вони також є місцем призначення явної специфікації посилань; див.--prune
). - -j
- --jobs=<n>
-
Кількість паралельних дочірніх об’єктів, які будуть використовуватися для всіх форм вибірки.
Якщо було вказано опцію
--multiple
, різні віддалені модулі будуть завантажуватися паралельно. Якщо вибирається кілька підмодулів, вони будуть завантажуватися паралельно. Щоб керувати ними незалежно, використовуйте налаштування конфігураціїfetch.parallel
таsubmodule.fetchJobs
(див. git-config[1]).Зазвичай паралельні рекурсивні та багатовіддалені вибірки будуть швидшими. За замовчуванням вибірки виконуються послідовно, а не паралельно.
- --set-upstream
-
Якщо віддалений доступ успішно отримано, додайте посилання на вихідний код (відстеження), яке використовується командою git-pull[1] без аргументів та іншими командами. Для отримання додаткової інформації див.
branch.
<name>.merge
таbranch.
<name>.remote
у git-config[1]. - --upload-pack <upload-pack>
-
Якщо задано, і репозиторій для отримання даних обробляється git fetch-pack, то команді передається
--exec=
<upload-pack>, щоб вказати шлях, відмінний від стандартного, для виконання команди на іншому кінці. - --progress
-
Стан виконання за замовчуванням повідомляється у стандартному потоці помилок, коли він підключений до терміналу, якщо не вказано -q. Цей прапорець примусово повідомляє про стан виконання, навіть якщо стандартний потік помилок не спрямований до терміналу.
- -o <option>
- --server-option=<опція>
-
Передати заданий рядок на сервер під час зв’язку за протоколом версії 2. Заданий рядок не повинен містити символів NUL або LF. Обробка сервером параметрів сервера, включаючи невідомі, залежить від сервера. Якщо задано кілька параметрів
--server-option=
<опція>, усі вони надсилаються іншій стороні в порядку, зазначеному в командному рядку. Якщо параметр--server-option=
<опція> не задано в командному рядку, замість нього використовуються значення змінної конфігураціїremote.
<назва>.serverOption
. - --show-forced-updates
-
За замовчуванням git перевіряє, чи гілка примусово оновлюється під час fetch. Це можна вимкнути за допомогою fetch.showForcedUpdates, але опція --show-forced-updates гарантує виконання цієї перевірки. Див. git-config[1].
- --no-show-forced-updates
-
За замовчуванням git перевіряє, чи гілка примусово оновлюється під час fetch. Передайте --no-show-forced-updates або встановіть fetch.showForcedUpdates на false, щоб пропустити цю перевірку з міркувань продуктивності. Якщо використовувати під час git-pull, опція --ff-only все одно перевірятиме наявність примусових оновлень перед спробою швидкого оновлення. Див. git-config[1].
- -4
- --ipv4
-
Використовуйте лише адреси IPv4, ігноруючи адреси IPv6.
- -6
- --ipv6
-
Використовуйте лише адреси IPv6, ігноруючи адреси IPv4.
- <repository>
-
«Віддалене» сховище, яке є джерелом операції fetch або pull. Цей параметр може бути або URL-адресою (див. розділ GIT URLS нижче), або іменем віддаленого сховища (див. розділ REMOTES нижче).
- <refspec>
-
Визначає, які посилання потрібно отримати, а які локальні посилання потрібно оновити. Якщо в командному рядку немає <refspec>, посилання для отримання зчитуються зі змінних
remote.
<repository>.fetch
(див. розділ «НАЛАШТУВАНІ ВІДДІЛЕННЯ ДИСТАНЦІЙНОГО ВІДСТЕЖЕННЯ» in git-fetch[1]).Формат параметра <refspec> – це необов’язковий символ плюса
+
, за яким іде джерело <src>, далі двокрапка:
, а потім кінцевий <dst>. Двокрапку можна пропустити, якщо <dst> порожній. <src> зазвичай є посиланням або шаблоном глобального типу з однією символом*
, який використовується для зіставлення набору посилань, але також може бути повним шістнадцятковим ім’ям об’єкта, написаним у вигляді назви.<refspec> може містити
*
у своєму <src>, щоб вказати просте збігання зі зразком. Така специфікація посилань функціонує як глобальний об’єкт, який зіставляє будь-яке посилання зі зразком. Шаблон <refspec> повинен мати одну і тільки одну*
як у <src>, так і в <dst>. Вона зіставлятиме посилання з місцем призначення, замінюючи*
вмістом, що збігається з джерелом.Якщо специфікація посилань починається з префікса
^
, вона буде інтерпретована як негативна специфікація посилань. Замість того, щоб вказувати, які посилання потрібно вибрати або які локальні посилання потрібно оновити, така специфікація посилань натомість визначатиме посилання, які потрібно виключити. Посилання вважатиметься таким, що відповідає, якщо воно відповідає принаймні одній позитивній специфікації посилань і не відповідає жодній негативній специфікації посилань. Негативні специфікації посилань можуть бути корисними для обмеження області дії специфікації посилань шаблону, щоб вона не включала певні посилання. Негативні специфікації посилань самі по собі можуть бути специфікаціями посилань шаблону. Однак вони можуть містити лише <src> і не вказувати <dst>. Повністю написані шістнадцяткові імена об’єктів також не підтримуються.tag
<tag> означає те саме, щоrefs/tags/
<tag>:refs/tags/
<tag>; він запитує отримання всього до заданого тегу.Вибирається віддалене посилання, яке відповідає <src>, і якщо <dst> не є порожнім рядком, робиться спроба оновити локальне посилання, яке йому відповідає.
Чи дозволено це оновлення без
--force
, залежить від простору імен посилань, до якого воно вибирається, типу об’єкта, що вибирається, та від того, чи вважається оновлення перемотуванням вперед. Загалом, для вибирання застосовуються ті самі правила, що й під час надсилання, див. розділ <refspec>... у git-push[1], щоб дізнатися, що це таке. Винятки з цих правил, що стосуютьсяgit
fetch
, наведено нижче.До версії Git 2.20, на відміну від push-надсилання за допомогою git-push[1], будь-які оновлення
refs/tags/*
приймалися без+
у специфікації refs (або--force
). Під час отримання змін ми без розбору вважали всі оновлення тегів з віддаленого сервера примусовими. Починаючи з версії Git 2.20, отримання змін для оновленняrefs/tags/*
працює так само, як і під час надсилання змін. Тобто будь-які оновлення будуть відхилені без+
у специфікації refs (або--force
).На відміну від push-у з git-push[1], будь-які оновлення поза
refs/{tags,heads}/*
будуть прийняті без+
у специфікації refs (або--force
), незалежно від того, чи це заміна, наприклад, об’єкта дерева на blob, чи коміту на інший коміт, який не має попереднього коміту як предка тощо.На відміну від push-управління за допомогою git-push[1], немає жодної конфігурації, яка б змінювала ці правила, і нічого подібного до хука
pre-fetch
, аналогічного хукуpre-receive
.Як і у випадку з push-надсиланням за допомогою git-push[1], усі описані вище правила щодо того, що не дозволено як оновлення, можна перевизначити, додавши необов’язковий початковий символ
+
до специфікації посилань (або використовуючи параметр командного рядка--force
). Єдиним винятком є те, що жодне примусове надсилання не змусить простір іменrefs/heads/*
приймати об’єкт без коміту.NoteКоли відомо, що віддалена гілка, яку ви хочете отримати, регулярно перемотується та перебазується, очікується, що її нова підказка не буде нащадком попередньої підказки (як вона зберігалася у вашій гілці з віддаленим відстеженням під час останнього отримання). Вам слід використовувати знак +
, щоб вказати, що для таких гілок будуть потрібні оновлення без перемотування вперед. Немає способу визначити або оголосити, що гілка буде доступною в репозиторії з такою поведінкою; користувач, що витягує, просто повинен знати, що це очікуваний шаблон використання гілки.NoteІснує різниця між перерахуванням кількох <refspec> безпосередньо в командному рядку git pull та наявністю кількох записів remote.
<repository>.fetch
у вашій конфігурації для <repository> та запуском команди git pull без будь-яких явних параметрів <refspec>. <refspec>, явно перелічені в командному рядку, завжди об’єднуються з поточною гілкою після отримання. Іншими словами, якщо ви перерахуєте більше одного віддаленого посилання, git pull створить злиття Octopus. З іншого боку, якщо ви не перерахуєте жодного явного параметра <refspec> у командному рядку, git pull отримає всі <refspec>, які він знайде в конфігураціїremote.
<repository>.fetch
, та об’єднає лише перший знайдений <refspec> з поточною гілкою. Це тому, що створення Octopus з віддалених посилань рідко виконується, тоді як відстеження кількох віддалених заголовків за один раз шляхом отримання більш ніж одного часто корисне.
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[1] для отримання детальної інформації.
Команди 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-адреса.
ПУЛЬТИ КЕРУВАННЯ
Замість URL-адреси як аргумент <repository> можна використовувати назву одного з наступних:
-
віддалений сервер у файлі конфігурації Git:
$GIT_DIR/config
, -
файл у каталозі
$GIT_DIR/remotes
, або -
файл у каталозі
$GIT_DIR/branches
.
Усі вони також дозволяють вам пропустити refspec з командного рядка, оскільки кожен з них містить refspec, який git використовуватиме за замовчуванням.
Назва віддаленого пристрою у файлі конфігурації
Ви можете вказати назву віддаленого сервера, який ви раніше налаштували за допомогою git-remote[1], git-config[1] або навіть вручну редагуючи файл $GIT_DIR/config
. URL-адреса цього віддаленого сервера буде використана для доступу до репозиторію. Специфікація посилань цього віддаленого сервера буде використовуватися за замовчуванням, якщо ви не вкажете специфікацію посилань у командному рядку. Запис у файлі конфігурації виглядатиме так:
[remote "<name>"] url = <URL> pushurl = <pushurl> push = <refspec> fetch = <refspec>
<pushurl> використовується лише для надсилання змін. Він необов’язковий і за замовчуванням має значення <URL>. Надсилання змін на віддалений сервер впливає на всі визначені адреси pushurl або всі визначені URL-адреси, якщо жодної адреси pushurl не визначено. Однак Fetch буде отримувати дані лише з першої визначеної URL-адреси, якщо визначено кілька URL-адрес.
Іменований файл у $GIT_DIR/remotes
Ви можете вказати назву файлу в $GIT_DIR/remotes
. URL-адреса з цього файлу буде використана для доступу до репозиторію. Специфікація посилань у цьому файлі буде використовуватися за замовчуванням, якщо ви не вкажете специфікацію посилань у командному рядку. Цей файл повинен мати такий формат:
URL: один із наведених вище форматів URL-адрес Push: <refspec> Pull: <refspec>
Рядки Push:
використовуються командами git push, а рядки Pull:
використовуються командами git pull та git fetch. Для додаткових зіставлень гілок можна вказати кілька рядків Push:
та Pull:
.
Іменований файл у $GIT_DIR/branches
Ви можете вказати назву файлу в $GIT_DIR/branches
. URL-адреса з цього файлу буде використана для доступу до репозиторію. Цей файл повинен мати такий формат:
<URL>#<head>
<URL> is required; #
<head> є необов’язковим.
Залежно від операції, git використовуватиме одну з наступних специфікацій refspecs, якщо ви не вкажете її в командному рядку. <branch> – це назва цього файлу в $GIT_DIR/branches
, а <head> за замовчуванням має значення master
.
git fetch uses:
refs/heads/<head>:refs/heads/<branch>
git push uses:
HEAD:refs/heads/<head>
СТРАТЕГІЇ ЗЛИТТЯ
Механізм злиття (команди git
merge
та git
pull
) дозволяє вибирати бекенд-«стратегії злиття» за допомогою опції -s
. Деякі стратегії також можуть приймати власні опції, які можна передати, надаючи аргументи -X
<опція> командам git
merge
та/або git
pull
.
-
ort
-
Це стратегія злиття за замовчуванням під час витягування або об’єднання однієї гілки. Ця стратегія може вирішити лише дві гілки за допомогою 3-стороннього алгоритму злиття. Коли є більше одного спільного предка, якого можна використовувати для 3-стороннього злиття, створюється об’єднане дерево спільних предків і використовується його як опорне дерево для 3-стороннього злиття. Повідомлялося, що це призводить до меншої кількості конфліктів злиття без виникнення помилок злиття, згідно з тестами, проведеними на фактичних коммітах злиття, взятих з історії розробки ядра Linux 2.6. Крім того, ця стратегія може виявляти та обробляти злиття, що включають перейменування. Вона не використовує виявлені копії. Назва цього алгоритму є абревіатурою ("Ostensibly Recursive’s Twin") і походить від того факту, що він був написаний як заміна попереднього алгоритму за замовчуванням,
recursive
.У випадку, коли шлях є підмодулем, якщо коміт підмодуля, використаний на одному боці злиття, є нащадком коміту підмодуля, використаного на іншому боці злиття, Git намагається перейти до нащадка. В іншому випадку Git розглядатиме цей випадок як конфлікт, пропонуючи як вирішення коміт підмодуля, який є нащадком конфліктуючих, якщо такий існує.
Стратегія
ort
може приймати такі варіанти:-
ours
-
Ця опція примусово автоматично вирішує конфліктуючі фрагменти, надаючи перевагу «нашій» версії. Зміни з іншого дерева, які не конфліктують з нашою стороною, відображаються в результаті злиття. Для бінарного файлу весь вміст береться з нашої сторони.
Це не слід плутати зі стратегією злиття
ours
, яка навіть не дивиться на те, що містить інше дерево. Вона відкидає все, що зробило інше дерево, оголошуючи, що історіяour
містить усе, що в ній сталося. -
theirs
-
Це протилежність до «ours»; зверніть увагу, що на відміну від «ours», немає стратегії злиття «hirs», з якою можна було б сплутати цей варіант злиття.
-
ignore-space-change
-
ignore-all-space
-
ignore-space-at-eol
-
ignore-cr-at-eol
-
Обробляє рядки з вказаним типом зміни пробілів як незмінні для тристороннього об’єднання. Зміни пробілів, змішані з іншими змінами в рядку, не ігноруються. Див. також git-diff[1]
-b
,-w
,--ignore-space-at-eol
та--ignore-cr-at-eol
.-
Якщо «їхня» версія вносить лише зміни пробілами в рядок, використовується «наша» версія;
-
Якщо «наша» версія містить зміни пробілів, але «їхня» версія містить суттєві зміни, використовується «їхня» версія;
-
В іншому випадку об’єднання відбувається у звичайному порядку.
-
-
renormalize
-
Це запускає віртуальне отримання та повернення всіх трьох етапів будь-якого файлу, який потребує тристороннього злиття. Цей параметр призначений для використання під час об’єднання гілок з різними фільтрами очищення або правилами нормалізації кінця рядка. Див. "Об’єднання гілок з різними атрибутами реєстрації/вивантаження" в gitattributes[5] для отримання детальної інформації.
-
no-renormalize
-
Вимикає опцію
renormalize
. Це замінює змінну конфігураціїmerge.renormalize
. -
find-renames
[=
<n>] -
Увімкнути виявлення перейменування, за потреби встановити поріг подібності. Це значення за замовчуванням. Це перевизначає змінну конфігурації
merge.renames
. Див. також git-diff[1]--find-renames
. -
rename-threshold=
<n> -
Застарілий синонім до
find-renames=
<n>. -
no-renames
-
Вимкніть виявлення перейменування. Це замінює змінну конфігурації
merge.renames
. Див. також git-diff[1]--no-renames
. -
histogram
-
Застарілий синонім до
diff-algorithm=histogram
. -
patience
-
Застарілий синонім до
diff-algorithm=patience
. -
diff-algorithm=
(histogram
|minimal
|myers
|patience
) -
Використовуйте інший алгоритм порівняння під час об’єднання, що може допомогти уникнути неправильних злиття, що виникають через неважливі збіги рядків (наприклад, фігурні дужки з різних функцій). Див. також git-diff[1]
--diff-algorithm
. Зверніть увагу, щоort
за замовчуванням має значенняdiff-algorithm=histogram
, тоді як звичайні порівняння наразі за замовчуванням використовують налаштування конфігураціїdiff.algorithm
. -
subtree
[=
<path>] -
Цей варіант є більш просунутою формою стратегії «піддерева», де стратегія робить припущення щодо того, як два дерева мають бути зміщені, щоб збігатися під час об’єднання. Натомість, зазначений шлях додається до початку (або видаляється з самого початку), щоб форма двох дерев збігалася.
-
-
recursive
-
Тепер це синонім до
ort
. Це була альтернативна реалізація до версії 2.49.0, але була перенаправлена наort
у версії 2.50.0. Попередня рекурсивна стратегія була стратегією за замовчуванням для розв’язання двох голов з Git версії 0.99.9k до версії 2.33.0. -
resolve
-
Це може вирішити лише дві гілки (тобто поточну гілку та іншу гілку, з якої ви витягли дані) за допомогою 3-стороннього алгоритму злиття. Він намагається ретельно виявити перехресні неоднозначності злиття. Він не обробляє перейменування.
-
octopus
-
Це вирішує випадки з більш ніж двома заголовками, але відмовляється від складного об’єднання, яке потребує ручного вирішення. В основному це призначено для об’єднання заголовків тематичних гілок. Це стратегія об’єднання за замовчуванням під час витягування або об’єднання кількох гілок.
-
ours
-
Це дозволяє вирішувати будь-яку кількість заголовків, але результуюче дерево злиття завжди буде таким, як поточна заголовка гілки, фактично ігноруючи всі зміни з усіх інших гілок. Це призначено для використання для заміни старої історії розробки бічних гілок. Зверніть увагу, що це відрізняється від опції
-Xours
для стратегії злиттяort
. -
subtree
-
Це модифікована стратегія
ort
. Під час об’єднання дерев A та B, якщо B відповідає піддереву A, B спочатку коригується відповідно до структури дерева A, замість того, щоб зчитувати дерева на одному рівні. Це коригування також виконується для дерева спільного предка.
Зі стратегіями, що використовують 3-стороннє злиття (включаючи ort
за замовчуванням), якщо зміна внесена в обидві гілки, але пізніше скасована в одній з гілок, ця зміна буде присутня в результаті об’єднання; деякі люди вважають таку поведінку заплутаною. Це відбувається тому, що під час виконання злиття враховуються лише заголовки та база злиття, а не окремі коміти. Тому алгоритм злиття вважає скасовану зміну як таку, що взагалі не вносила змін, і замінює її зміненою версією.
ПОВЕДІНКА ЗА ЗАМОВЧАННЯМ
Часто люди використовують git
pull
без надання жодних параметрів. Традиційно це було еквівалентно використанню git
pull
origin
. Однак, коли конфігурація branch.
<name>.remote
присутня на гілці <name>, це значення використовується замість origin
.
Щоб визначити, з якої URL-адреси отримувати дані, використовується значення конфігурації remote.
<origin>.url
, і якщо такої змінної немає, використовується значення з рядка URL:
у $GIT_DIR/remotes/
<origin>.
Щоб визначити, які віддалені гілки потрібно отримати (і, за бажанням, зберегти у гілках віддаленого відстеження), коли команда виконується без будь-яких параметрів refspec у командному рядку, перевіряються значення змінної конфігурації remote.
<origin>.fetch
, а якщо таких немає, перевіряється $GIT_DIR/remotes/
<origin> та використовуються її рядки Pull:
. На додаток до форматів refspec, описаних у розділі OPTIONS, ви можете мати глобальну refspec, яка виглядає так:
refs/heads/*:refs/remotes/origin/*
Глобальна специфікація посилань повинна мати непорожній правий зріз (тобто повинна зберігати дані, отримані у гілках віддаленого відстеження), а його лівий зріз та правий зріз повинні закінчуватися на /*
. Вищезазначене вказує, що всі віддалені гілки відстежуються за допомогою гілок віддаленого відстеження в ієрархії refs/remotes/origin/
під однаковою назвою.
Правило визначення віддаленої гілки для об’єднання після отримання даних дещо складне, щоб не порушувати зворотну сумісність.
Якщо в командному рядку git
pull
було задано явні специфікації посилань, усі вони об’єднуються.
Якщо в командному рядку не було вказано специфікацію посилання (refspec), тоді git
pull
використовує специфікацію посилання з конфігурації або $GIT_DIR/remotes/
<origin>. У таких випадках застосовуються такі правила:
-
Якщо конфігурація
branch.
<name>.merge
для поточної гілки <name> існує, це назва гілки на віддаленому сайті, яка об’єднується. -
Якщо специфікація посилань є глобальною, нічого не об’єднується.
-
В іншому випадку віддалена гілка першої специфікації посилань об’єднується.
ПРИКЛАДИ
-
Оновіть гілки віддаленого відстеження для репозиторію, з якого ви клонували, а потім об’єднайте одну з них з вашою поточною гілкою:
$ git pull $ git pull origin
Зазвичай гілка, в яку здійснюється об’єднання, є HEAD віддаленого репозиторію, але вибір визначається опціями branch.<name>.remote та branch.<name>.merge; див. git-config[1] для отримання детальної інформації.
-
Об’єднати з поточною гілкою віддалену гілку
next
:$ git pull origin next
Це тимчасово залишає копію
next
у FETCH_HEAD та оновлює гілку віддаленого відстеженняorigin/next
. Те саме можна зробити, викликавши fetch та merge:$ git fetch origin $ git merge origin/next
Якщо ви спробували витягнути дані, що призвело до складних конфліктів, і хочете почати спочатку, ви можете відновити їх за допомогою git reset.
БЕЗПЕКА
Протоколи fetch та push не розроблені для запобігання крадіжці однією стороною даних з іншого репозиторію, які не призначалися для спільного використання. Якщо у вас є конфіденційні дані, які потрібно захистити від зловмисного зловмисника, найкращим варіантом буде зберігати їх в іншому репозиторії. Це стосується як клієнтів, так і серверів. Зокрема, простори імен на сервері не є ефективними для контролю доступу на читання; вам слід надавати доступ на читання до простору імен лише тим клієнтам, яким ви довіряєте доступ на читання до всього репозиторію.
Відомі вектори атаки такі:
-
Жертва надсилає рядки "have", що рекламують ідентифікатори об’єктів, які вона має, але які не призначені для спільного використання, але можуть бути використані для оптимізації передачі, якщо вони також є у вузла. Зловмисник вибирає ідентифікатор об’єкта X для крадіжки та надсилає посилання на X, але не зобов’язаний надсилати вміст X, оскільки жертва вже має його. Тепер жертва вважає, що зловмисник має X, і пізніше надсилає вміст X назад зловмиснику. (Цю атаку найпростіше виконати на сервері, створюючи посилання на X у просторі імен, до якого клієнт має доступ, а потім отримуючи його. Найімовірніший спосіб для сервера виконати це на клієнті - це "злити" X у публічну гілку та сподіватися, що користувач виконає додаткову роботу над цією гілкою та надішле її назад на сервер, не помічаючи злиття.)
-
Як і в пункті №1, зловмисник вибирає ідентифікатор об’єкта X для крадіжки. Жертва надсилає об’єкт Y, який у зловмисника вже є, а зловмисник хибно стверджує, що має X, а не Y, тому жертва надсилає Y як дельту відносно X. Дельта показує зловмиснику області X, схожі на Y.
ПОМИЛКИ
Використання --recurse-submodules може отримувати нові коміти лише у вже отриманих підмодулях на даний момент. Наприклад, коли основний розробник додає новий підмодуль у щойно отримані коміти суперпроекту, сам підмодуль не може бути отриманий, що унеможливлює отримання цього підмодуля пізніше без необхідності повторного виконання отримання. Очікується, що це буде виправлено в майбутній версії Git.
GIT
Частина набору git[1]