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

НАЗВА

git-pull — Отримання та інтеграція даних з іншого репозиторію або локальної гілки

СИНОПСИС

git pull [<options>] [<repository> [<refspec>…​]]

ОПИС

Інтеграція змін з віддаленого репозиторію в поточну гілку.

Спочатку команда git pull виконує команду git fetch з тими самими аргументами (за винятком опцій злиття), щоб завантажити віддалені гілки. Потім вона визначає, яку віддалену гілку потрібно інтегрувати: якщо запустити git pull без аргументів, типовим значенням для поточної гілки буде upstream. Після цього ця гілка інтегрується в поточну гілку.

Існує 4 основні варіанти інтеграції віддаленого гілки:

  1. Команда git pull --ff-only виконує лише оновлення перемотуванням вперед («fast-forward»): вона завершиться з помилкою, якщо ваша локальна гілка розійшлася з віддаленою гілкою. Це є стандартною поведінкою.

  2. git pull --rebase запускає git rebase

  3. git pull --no-rebase запускає git merge.

  4. git pull --squash запускає git merge --squash

Ви також можете встановити параметри конфігурації pull.rebase, pull.squash або pull.ff з бажаною поведінкою.

Якщо під час злиття або ребейзу виник конфлікт, який ви не хочете розвʼязувати, ви можете безпечно перервати процес за допомогою команд git merge --abort або git rebase --abort.

ОПЦІЇ

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

«Віддалений» ("remote") репозиторій, з якого потрібно завантажити дані. Це може бути або URL-адреса (див. розділ GIT URLS нижче), або ім’я віддаленого екземпляра (див. розділ ВІДДАЛЕНІ ЕКЗЕМПЛЯРИ нижче).

Стандартне значення — це налаштований upstream для поточної гілки або origin. Докладнішу інформацію про налаштування upstream див. у розділі ВИСХІДНІ ГІЛКИ нижче.

<refspec>

Яку гілку або інші посилання потрібно завантажити та інтегрувати в поточну гілку, наприклад main у команді git pull origin main. Стандартним значенням є налаштований upstream для поточної гілки.

Це може бути гілка, тег або інший набір посилань. Повний синтаксис див. у <refspec> нижче в розділі «Параметри, повʼязані з вибіркою», а також у розділі СТАНДАРТНА ПОВЕДІНКА нижче, щоб дізнатися, як git pull використовує цей аргумент для визначення віддаленої гілки для інтеграції.

-q
--quiet

Цей параметр передається як базовій функції git-fetch для придушення повідомлень під час передачі, так і базовій функції git-merge для придушення виводу під час злиття.

-v
--verbose

Передає --verbose до git-fetch та git-merge.

--recurse-submodules[=(yes|on-demand|no)]
--no-recurse-submodules

Цей параметр контролює, чи слід отримувати нові коміти заповнених субмодулів, а також чи слід оновлювати робочі дерева активних субмодулів (див. git-fetch[1], git-config[1] та gitmodules[5]).

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

Якщо оновлення виконується через злиття, конфлікти субмодулів розвʼязуються та перевіряються.

Параметри, повʼязані з обʼєднанням

--commit
--no-commit

Виконати обʼєднання та зафіксувати результат. Цю опцію можна використовувати для перевизначення параметра --no-commit. Корисно лише під час обʼєднання.

З параметром --no-commit виконується обʼєднання, але процес зупиняється безпосередньо перед створенням коміту обʼєднання, щоб дати користувачеві можливість перевірити та додатково налаштувати результат обʼєднання перед фіксацією.

Зверніть увагу, що оновлення з переходом вперед (fast-forward) не створюють коміт злиття, тому немає можливості зупинити ці злиття за допомогою --no-commit. Отже, якщо ви хочете переконатися, що ваша гілка не буде змінена або оновлена командою злиття, використовуйте --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, коли можливо, виконувати злиття як перемотування вперед (fast-forward) (оновлювати лише вказівник гілки, щоб він відповідав обʼєднаній гілці; не створювати коміт злиття). Якщо неможливо (коли історія обʼєднання не є нащадком поточної історії), створювати коміт злиття.

З опцією --no-ff створюється коміт злиття у всіх випадках, навіть якщо злиття можна було б виконати як перемотування вперед (fast-forward).

-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

Додає наприкінці повідомлення журналу коміту підпис Signed-off-by, поставлений автором коміту. Значення такого підпису залежить від проєкту, до якого ви робите коміт. Наприклад, він може підтверджувати, що автор коміту має права на публікацію роботи відповідно до ліцензії проєкту або погоджується з певними запевненнями щодо авторів, такими як «Сертифікат походження розробника». (Див. https://developercertificate.org, щоб ознайомитися з тим, що використовується в ядрі Linux та проектах Git.) Зверніться до документації або керівництва проєкту, до якого ви робите внесок, щоб зрозуміти, як підписи використовуються в цьому проєкті.

Опцію --no-signoff можна використовувати для скасування попередньої опції --signoff у командному рядку.

У Git немає (і не буде) змінної конфігурації, яка б стандартно вмикала опцію командного рядка --signoff; детальніше див. елемент commit.signoff у gitfaq[7].

--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 є недопустимою і призведе до помилки.

Корисно лише під час обʼєднання.

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

Переконайтеся, що останній коміт бічної гілки, яка об’єднується, підписано дійсним ключем, тобто ключем із дійсним ідентифікатором (uid): у стандартній моделі довіри це означає, що ключ підписання був підписаний ключем, якому довіряють. Якщо останній коміт бічної гілки не підписано дійсним ключем, об’єднання не відбудеться.

Корисно лише під час обʼєднання.

--summary
--no-summary

Синоніми до --stat та --no-stat; вони застарілі та будуть видалені в майбутньому.

--autostash
--no-autostash

Перед початком операції автоматично створити тимчасовий запис у сховку, записати його в посилання MERGE_AUTOSTASH і застосувати після завершення операції. Це означає, що операцію можна виконувати на брудному робочому дереві. Однак слід бути обережними: остаточне застосування запису зі сховку після успішного злиття може призвести до серйозних конфліктів.

--allow-unrelated-histories

Стандартно команда git merge відмовляється обʼєднувати історії, які не мають спільного предка. Цю опцію можна використовувати, щоб обійти це обмеження під час обʼєднання історій двох проєктів, які спочатку розвивалися незалежно один від одного. Оскільки такі випадки трапляються вкрай рідко, конфігураційної змінної, яка б увімкнула цю функцію в стандартному режимі, не існує і не планується додавати.

Корисно лише під час обʼєднання.

-r
--rebase[=(true|merges|false|interactive)]
true

перебазувати поточну гілку поверх висхідної (upsatream) гілки після отримання даних. Якщо існує гілка віддаленого відстеження, що відповідає висхідній гілці, і гілка upstream була перебазована з моменту останньої отримання даних, перебазування використовує цю інформацію, щоб уникнути перебазування нелокальних змін. Це стандартна поведінка.

merges

перебазувати за допомогою git rebase --rebase-merges, щоб локальні коміти злиття були включені до перебазування (див. git-rebase[1] для деталей).

false

обʼєднати висхідну гілку (upstream) з поточною гілкою.

interactive

увімкнути інтерактивний режим перебазування.

Дивіться pull.rebase, branch.<name>.rebase та branch.autoSetupRebase у git-config[1], якщо ви хочете, щоб git pull завжди використовував --rebase замість злиття.

+

Note
 Це потенційно небезпечний режим роботи. Він переписує історію, що не віщує нічого доброго, враховуючи, що ви вже опублікували цю історію. Не використовуйте цю опцію, якщо ви уважно не прочитали git-rebase[1].
--no-rebase

Це скорочення для --rebase=false.

Параметри, пов’язані з отриманням даних

--all
--no-all

Завантажити всі віддалені ресурси, за винятком тих, для яких встановлено змінну конфігурації remote.<name>.skipFetchAll. Це замінює значення змінної конфігурації fetch.all.

-a
--append

Додати назви посилань та назви обʼєктів отриманих посилань до наявного вмісту .git/FETCH_HEAD. Без цієї опції старі дані в .git/FETCH_HEAD будуть перезаписані.

--atomic

Використовувати атомарну транзакцію для оновлення локальних посилань. Усі посилання оновлюються, або, у разі помилки, жодне посилання не оновлюється.

--depth=<depth>

Обмежте завантаження до вказаної кількості комітів з кінця історії кожної віддаленої гілки. Якщо завантаження здійснюється у «поверхневий» репозиторій, створений командою git clone з опцією --depth=<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 повідомляє серверу про коміти, доступні з усіх локальних ref, щоб знайти спільні коміти та зменшити розмір файлу pack, який потрібно отримати. Якщо вказати цей параметр, Git повідомлятиме лише про коміти, доступні з вказаних вершин. Це корисно для прискорення завантаження, коли користувач знає, який локальний ref, ймовірно, має спільні коміти з ref, що завантажується з upstream.

Цей параметр можна вказати більше одного разу; якщо так, 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, він може відмовитися оновлювати локальну гілку, як обговорювалося в частині <refspec> документації 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.<name>.fetch для віддаленого репозиторію. Надання порожньої <refspec> для опції --refmap призведе до того, що Git ігноруватиме налаштовані специфікації посилань та повністю покладатиметься на специфікації посилань, надані як аргументи командного рядка. Див. розділ "Налаштовані гілки віддаленого відстеження" для отримання детальної інформації.

-t
--tags

Отримати всі теги з віддаленого сервера (тобто отримати віддалені теги refs/tags/* у локальні теги з такою ж назвою), на додаток до всього іншого, що було б отримано в іншому випадку. Використання лише цієї опції не призводить до обрізання тегів, навіть якщо використовується --prune (хоча теги можуть бути обрізані в будь-якому випадку, якщо вони також є місцем призначення явної специфікації посилань; див. --prune).

-j <n>
--jobs=<n>

Паралелізуйте всі форми отримання до <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.

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

«Віддалений» репозиторій, який є джерелом операції fetch або pull. Цим параметром може бути або URL-адреса (див. розділ GIT URLS нижче), або імʼя віддаленого репозиторію (див. розділ ВІДДАЛЕНІ ЕКЗЕМПЛЯРИ нижче).

<refspec>

Визначає, які посилання потрібно отримати, а які локальні посилання потрібно оновити. Якщо в командному рядку немає змінних <refspec>s, посилання для отримання зчитуються зі змінних remote.<repository>.fetch (див. розділ «НАЛАШТОВАНІ ГІЛКИ ВІДДАЛЕНОГО ВІДСТЕЖЕННЯ» in git-fetch[1]).

Формат параметра <refspec> складається з необов’язкового знака плюс +, за яким йде джерело <src>, потім двокрапка :, а потім — місце призначення <dst>. Двокрапку можна опустити, якщо <dst> порожнє. <src> зазвичай є посиланням або шаблоном з одним символом *, який використовується для пошуку набору посилань, але це також може бути повністю написане шестнадцяткове ім’я обʼєкта.

<refspec> може містити символ * в частині <src>, щоб вказати на простий шаблонний збіг. Такий refspec функціонує як символ підстановки, який відповідає будь-якому ref з цим шаблоном. <refspec> з шаблоном має містити лише один символ * як у <src>, так і в <dst>. Він буде зіставляти refs в призначеі, замінюючи * на вміст, отриманий з джерела.

Якщо перед refspec стоїть префікс ^, він буде інтерпретуватися як негативний refspec. Замість того, щоб вказувати, які refs потрібно завантажити або які локальні refs оновити, такий refspec вказує refs, які слід виключити. Вважається, що ref має збіг, якщо він збігається принаймні з одним позитивним refspec і не збігається з жодним негативним refspec. Негативні refspec можуть бути корисними для обмеження області дії шаблонного refspec, щоб він не включав певні ref. Негативні refspec самі по собі можуть бути шаблонними refspec. Однак вони можуть містити лише <src> і не вказують <dst>. Повні шестнадцяткові імена об’єктів також не підтримуються.

tag <tag> означає те саме, що refs/tags/<tag>:refs/tags/<tag>; він запитує отримання всього до заданого тегу.

Віддалене посилання, яке відповідає <src>, отримується, і якщо <dst> не є порожнім рядком, робиться спроба оновити локальне посилання, яке йому відповідає.

Чи дозволено це оновлення без параметра --force, залежить від простору імен посилань, куди воно завантажується, типу об’єкта, що завантажується, а також від того, чи вважається це оновлення переходом уперед (fast-forward). Загалом, для завантаження застосовуються ті самі правила, що й для надсилання, див. розділ <refspec>... у git-push[1], щоб дізнатися, які саме. Винятки з цих правил, що стосуються саме git fetch, зазначені нижче.

До версії Git 2.20, на відміну від надсилання за допомогою команди git-push[1], будь-які оновлення в refs/tags/* приймалися без символу + у refspec (або з опцією --force). Під час отримання ми без розбору розглядали всі оновлення тегів з віддаленого репозиторію як примусові. Починаючи з версії Git 2.20, завантаження для оновлення refs/tags/* працює так само, як і під час надсилання. Тобто будь-які оновлення будуть відхилені без + у refspec (або --force).

На відміну від надсилання за допомогою команди linkgit:git-push[1], будь-які оновлення поза межами refs/{tags,heads}/* будуть прийняті без символу + у refspec (або з опцією --force), незалежно від того, чи йдеться про заміну, наприклад, об’єкта дерева на об’єкт blob, чи заміну коміту на інший коміт, який не має попереднього коміту як предка, тощо.

На відміну від надсилання за допомогою git-push[1], тут немає налаштувань, які б змінювали ці правила, і немає нічого подібного до гачка pre-fetch, аналогічного гачку pre-receive.

Як і у випадку з надсиланням за допомогою команди git-push[1], усі описані вище правила щодо того, що не допускається в якості оновлення, можна обійти, додавши опціональний символ + на початку refspec (або використавши опцію командного рядка --force). Єдиний виняток полягає в тому, що жодне примусове надсилання не змусить простір імен refs/heads/* прийняти об’єкт, що не є комітом.

Note
 Коли відомо, що віддалена гілка, яку ви хочете отримати, регулярно перемотується та перебазується, очікується, що її нова вершина не буде нащадком попередньої вершини (як вона зберігалася у вашій гілці з віддаленим відстеженням під час останнього отримання). Вам слід використовувати знак +, щоб вказати, що для таких гілок будуть потрібні оновлення без перемотування вперед. Немає способу визначити або оголосити, що гілка буде доступною в репозиторії з такою поведінкою; користувач, що витягує дані, просто повинен знати, що це очікуваний шаблон використання гілки.
Note
 Існує різниця між вказанням декількох <refspec> безпосередньо в командному рядку git pull та наявністю декількох записів remote.<repository>.fetch у вашому файлі конфігурації для <repository> і виконанням команди git pull без явно вказаних параметрів <refspec>. Параметри <refspec>, явно вказані в командному рядку, завжди зливаються в поточну гілку після завантаження. Іншими словами, якщо ви вказали більше одного віддаленого ref, git pull створить злиття типу Octopus. З іншого боку, якщо ви не вказали жодного явного параметра <refspec> у командному рядку, git pull завантажить усі <refspec>, які знайде у конфігурації remote. <repository>.fetch і злиє лише перший знайдений <refspec> у поточну гілку. Це пов’язано з тим, що створення злиття Octopus із віддалених refs відбувається рідко, тоді як відстеження декількох віддалених вершин одночасно шляхом завантаження більше ніж одної часто є корисним.

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 використовуватиме стандартно.

Назва віддаленого репозиторію в файлі конфігурації

Ви можете вказати ім’я віддаленого репозиторію, яке раніше було налаштоване за допомогою команд linkgit:git-remote[1], linkgit:git-config[1] або навіть шляхом ручного редагування файлу $GIT_DIR/config. URL-адреса цього віддаленого репозиторію буде використовуватися для доступу до репозиторію. Refspec цього віддаленого репозиторію буде використовуватися як стандартний, якщо ви не вкажете refspec у командному рядку. Запис у файлі конфігурації матиме такий вигляд:

	[remote "<name>"]
		url = <URL>
		pushurl = <pushurl>
		push = <refspec>
		fetch = <refspec>

<pushurl> використовується виключно для надсилання. Цей параметр є необов’язковим, а стандартним значенням є <URL>. Надсилання на віддалений сервер впливає на всі визначені pushurl або на всі визначені url, якщо pushurl не визначено. Натомість, якщо визначено кілька url, завантаження відбуватиметься лише з першого визначеного url.

Іменований файл у $GIT_DIR/remotes

Ви можете вказати ім’я файлу в теці $GIT_DIR/remotes. URL-адреса, вказана в цьому файлі, буде використовуватися для доступу до репозиторію. Refspec у цьому файлі буде використовуватися як стандартний, якщо ви не вкажете refspec у командному рядку. Цей файл повинен мати такий формат:

	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> —обовʼязково; #<head> —необовʼязково.

Залежно від операції, git використовуватиме один із наведених нижче refspecs, якщо ви не вкажете його в командному рядку. <branch> — це назва відповідного файлу в теці $GIT_DIR/branches, а <head> має стандартне значення master.

git fetch використовує:

	refs/heads/<head>:refs/heads/<branch>

git push використовує:

	HEAD:refs/heads/<head>

ВИСХІДНІ ГІЛКИ

Гілки в Git можуть, за бажанням, мати висхідну віддалену гілку. Зазвичай Git використовує висхідну (upstream) гілку для віддалених операцій, наприклад:

  • Вона є стандартною для git pull або git fetch без аргументів.

  • Вона є стандартною для git push без аргументів, за деякими винятками. Наприклад, ви можете використати опцію branch.<name>.pushRemote, щоб надіслати дані до іншого віддаленого репозиторію, ніж той, з якого ви завантажуєте, і відповідно до стандартного значення push.default=simple гілка, яку ви налаштовуєте, повинна мати таку саму назву.

  • Різні команди, зокрема git checkout та git status, покажуть вам, скільки комітів було додано до вашої поточної гілки та висхідної (upstream) гілки з моменту відгалуження від неї, наприклад, «Ваша гілка та origin/main розійшлися та мають 2 та 3 різні коміти відповідно».

Дані upstream зберігаються у файлі .git/config, у полях "remote" та "merge". Наприклад, якщо upstream для main є origin/main:

[branch "main"]
   remote = origin
   merge = refs/heads/main

Ви можете явно встановити гілку upstream за допомогою git push --set-upstream <remote> <branch>, але Git часто автоматично встановить її за вас, наприклад:

  • Під час клонування репозиторію Git автоматично встановить upstream для стандартної гілки.

  • Якщо у вас встановлено параметр конфігурації push.autoSetupRemote, команда git push автоматично налаштує upstream під час першого надсилання гілки.

  • Перевірка гілки віддаленого відстеження за допомогою git checkout <branch> автоматично створить локальну гілку з цією назвою та встановить посилання на джерело (upstream) на віддалену гілку.

Note
 Висхідні гілки іноді називають «інформацією відстеження», наприклад, «встановити інформацію відстеження гілки».

СТРАТЕГІЇ ЗЛИТТЯ

Механізм злиття (команди git merge та git pull) дозволяє вибирати бекенд-«стратегії злиття» за допомогою опції -s. Деякі стратегії також можуть приймати власні опції, які можна передати, надаючи аргументи -X<опція> командам git merge та/або git pull.

ort

Це стандартна стратегія злиття при витягуванні або злитті однієї гілки. Ця стратегія дозволяє об’єднати лише дві вершини за допомогою алгоритму тристороннього злиття. Коли існує більше ніж один спільний предок, який можна використати для тристороннього злиття, вона створює злите дерево спільних предків і використовує його як дерево-орієнтир для тристороннього злиття. За результатами тестів, проведених на реальних комітах злиття, взятих з історії розробки ядра Linux 2.6, це призводить до меншої кількості конфліктів злиття без створення помилкових злиттів. Крім того, ця стратегія може виявляти та обробляти злиття, що містять перейменування. Вона не використовуватиме виявлені копії. Назва цього алгоритму є акронімом («Ostensibly Recursive’s Twin») і походить від того, що він був написаний як заміна попереднього стандартного алгоритму, recursive.

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

Стратегія ort може приймати такі варіанти:

ours

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

Це не слід плутати зі стратегією злиття ours, яка взагалі не враховує вміст іншого дерева. Вона відкидає всі зміни, внесені в іншому дереві, і вважає, що «наша» історія містить усе, що там відбувалося.

theirs

Це протилежність параметру ours; зверніть увагу, що, на відміну від ours, не існує стратегії злиття theirs, з якою можна було б сплутати цей параметр злиття.

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

Ця опція виконує перевірку та реєстрацію всіх трьох стадій будь-якого файлу, який потребує тристороннього злиття. Цю опцію слід використовувати під час злиття гілок із різними фільтрами очищення або правилами нормалізації кінців рядків. Детальніше див. розділ «Злиття гілок із різними атрибутами checkin/checkout» у статті 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>]

Цей варіант є вдосконаленою формою стратегії subtree, за якої стратегія робить припущення щодо того, як слід змістити два дерева, щоб вони збігалися під час об’єднання. Натомість до вказаного шляху додається префікс (або з його початку видаляється частина), щоб форми двох дерев збігалися.

recursive

Тепер це синонім до ort. Це стратегія була альтернативною реалізацією до версії 2.49.0, але була перенаправлена на ort у версії 2.50.0. Попередня рекурсивна стратегія була стандартною стратегією для розвʼязання для двох вершин з Git версії 0.99.9k до версії 2.33.0.

resolve

Може розвʼязувати лише дві гілки (тобто поточну гілку та іншу гілку, з якої було виконано злиття) за допомогою алгоритму тристороннього злиття. Намагається ретельно виявляти неоднозначності, пов’язані з перехресним злиттям. Не підтримує перейменування.

octopus

Ця стратегія розвʼязує випадки, коли є більше двох вершин, але відмовляється виконувати складне злиття, яке потребує ручного втручання. Вона призначена насамперед для обʼєднання вершин гілок тем. Це стратегія злиття є стандартною під час злиття або об’єднання кількох гілок.

ours

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

subtree

Це модифікована стратегія ort. Під час обʼєднання дерев A та B, якщо B відповідає піддереву A, B спочатку коригується відповідно до структури дерева A, замість того, щоб зчитувати дерева на одному рівні. Це коригування також виконується для дерева спільного предка.

У стратегіях, що використовують тристороннє злиття (включно зі стандартною стратегією 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, описаних у розділі ОПЦІЇ, ви можете мати шаблон refspec, який виглядає так:

refs/heads/*:refs/remotes/origin/*

Шаблон <refspec> повинен мати непусту праву частину (тобто, повинен зберігати те, що було отримано в гілках remote-tracking), і його ліва та права частини повинні закінчуватися на /*. Вище описано, що всі віддалені гілки відстежуються за допомогою гілок remote-tracking в ієрархії refs/remotes/origin/ з однаковим іменем.

Правило визначення віддаленої гілки для обʼєднання після отримання даних дещо складне, щоб не порушувати зворотну сумісність.

Якщо в командному рядку команди git pull було вказано явні refspecs, то всі вони об’єднуються.

Якщо в командному рядку не було вказано refspec, тоді git pull використовує refspec з конфігурації або $GIT_DIR/remotes/<origin>. У таких випадках застосовуються такі правила:

  1. Якщо конфігурація branch.<name>.merge для поточної гілки <name> існує, це назва гілки на віддаленому сайті, яка була обʼєднана.

  2. Якщо refspec є символом підстановки, об’єднання не відбувається.

  3. В іншому випадку віддалена гілка першого refspec обʼєднується.

ПРИКЛАДИ

  • Оновіть гілки віддаленого відстеження для репозиторію, з якого ви клонували, а потім обʼєднайте одну з них з вашою поточною гілкою:

    $ 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 не призначені для запобігання викраденню однією стороною даних з іншого репозиторію, які не призначалися для спільного використання. Якщо у вас є приватні дані, які потрібно захистити від зловмисного користувача, найкращим варіантом буде зберігати їх в іншому репозиторії. Це стосується як клієнтів, так і серверів. Зокрема, простори імен на сервері не є ефективними для контролю доступу на читання; ви повинні надавати доступ на читання до простору імен лише тим клієнтам, яким ви довіряєте доступ на читання до всього репозиторію.

Відомі вектори атак такі:

  1. Жертва надсилає рядки «have», в яких вказує ідентифікатори об’єктів, що є в її розпорядженні, які не призначені для явного спільного використання, але можуть бути використані для оптимізації передачі даних, якщо у партнера вони також є. Зловмисник обирає ідентифікатор об’єкта X, який хоче викрасти, і надсилає посилання на X, але не зобов’язаний надсилати вміст X, оскільки жертва вже його має. Тепер жертва вважає, що зловмисник має X, і пізніше надсилає вміст X назад зловмиснику. (Цю атаку найпростіше здійснити клієнту на сервері, створивши посилання на X у просторі імен, до якого клієнт має доступ, а потім отримавши його. Найбільш ймовірний спосіб для сервера здійснити її на клієнті — це «злити» X у публічну гілку та сподіватися, що користувач виконає додаткову роботу над цією гілкою та надішле її назад на сервер, не помітивши злиття.)

  2. Як і у випадку №1, зловмисник вибирає ідентифікатор об’єкта X, який він хоче викрасти. Жертва надсилає об’єкт Y, який вже є у зловмисника, а той неправдиво заявляє, що має X, а не Y, тож жертва надсилає Y як дельту відносно X. Ця дельта розкриває зловмиснику ділянки об’єкта X, які схожі на Y.

ПОМИЛКИ

Наразі використання параметра --recurse-submodules дозволяє завантажувати лише нові коміти з уже завантажених субмодулів. Наприклад, якщо в щойно завантажених комітах суперпроєкту автори додали новий субмодуль, сам субмодуль не завантажується, що унеможливлює його подальше завантаження без повторного виконання команди fetch. Очікується, що ця проблема буде виправлена в майбутній версії Git.

ДИВ. ТАКОЖ

git-fetch[1], git-merge[1], git-config[1]

GIT

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