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

НАЗВА

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

СИНОПСИС

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

ОПИС

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

--allow-unrelated-histories

За замовчуванням команда 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>. У таких випадках застосовуються такі правила:

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

  2. Якщо специфікація посилань є глобальною, нічого не об’єднується.

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

ПРИКЛАДИ

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

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

ДИВ. ТАКОЖ

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

GIT

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