Git

git-fetch last updated in 2.54.0

НАЗВА

git-fetch — Завантаження обʼєктів та посилань з іншого репозиторію

СИНОПСИС

git fetch [<options>] [<repository> [<refspec>…]]
git fetch [<options>] <group>
git fetch --multiple [<options>] [(<repository>|<group>)…]
git fetch --all [<options>]

ОПИС

Завантажує гілки та/або теги (разом — «refs») з одного або декількох інших репозиторіїв разом з об’єктами, необхідними для відновлення їхньої історії. Гілки з віддаленим відстеженням оновлюються (щодо способів керування цією поведінкою див. опис <refspec> нижче).

Як правило, будь-який тег, що вказує на гілки, які завантажуються, також завантажується; це дозволяє завантажити теги, що вказують на гілки, які вас цікавлять. Цю стандартну поведінку можна змінити за допомогою опцій --tags або --no-tags або шляхом налаштування параметра remote.<name>.tagOpt. Використовуючи refspec, який явно завантажує теги, ви також можете завантажити теги, що не вказують на гілки, які вас цікавлять.

Команда git fetch може завантажувати дані як з одного репозиторію, вказаного за назвою або URL-адресою, так і з декількох репозиторіїв одночасно, якщо вказано <group> і у файлі конфігурації є запис remotes.<group>. (Див. git-config[1]).

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

Імена ref, які було завантажено, разом з іменами об’єктів, на які вони вказують, записуються у файл .git/FETCH_HEAD. Ця інформація може використовуватися скриптами або іншими командами Git, такими як git-pull[1].

ОПЦІЇ

--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.
--filter=<filter-spec>: Скористайтеся функцією часткового клонування та попросіть сервер надіслати підмножину доступних об’єктів відповідно до заданого фільтра об’єктів. При використанні параметра --filter для часткового отримання використовується вказаний <filter-spec>.

Якщо використовується параметр --filter=auto, специфікація фільтра визначається автоматично шляхом обʼєднання специфікацій фільтрів, оголошених сервером для віддалених promisor, які клієнт приймає (див. gitprotocol-v2[5] та параметр конфігурації promisor.acceptFromServer у git-config[1]).

Детальнішу інформацію про всі інші доступні специфікації фільтрів див. в описі параметра --filter=<filter-spec> у документації git-rev-list[1].

Наприклад, параметр --filter=blob:none відфільтрує всі блоби (вміст файлів), доки вони не знадобляться Git. Крім того, параметр --filter=blob:limit=<size> відфільтрує всі блоби розміром не менше <size>.
--write-fetch-head
--no-write-fetch-head: Список віддалених посилань, отриманих під час операції FETCH_HEAD, записується у файл, розташований безпосередньо в теці $GIT_DIR. Це стандартне значення. Якщо в командному рядку вказати параметр --no-write-fetch-head, Git не записуватиме цей файл. При використанні параметра --dry-run файл не записується взагалі.
-f
--force: Якщо команда git fetch використовується з refspec <src>:<dst>, вона може відмовитися оновлювати локальну гілку, як описано в розділі <refspec> нижче. Цей параметр замінює цю перевірку.
-k
--keep: Зберігати завантажений пакунок.
--multiple: Дозволяє вказувати кілька аргументів <repository> та <group>. Не можна вказувати жодних <refspec>.
--auto-maintenance
--no-auto-maintenance
--auto-gc
--no-auto-gc: Наприкінці запустити команду git maintenance run --auto, щоб за потреби виконати автоматичне обслуговування репозиторію. Ця опція є стандартно увімкненою.
--write-commit-graph
--no-write-commit-graph: Створити граф комітів після завантаження. Це замінює значення параметра конфігурації fetch.writeCommitGraph.
--prefetch: Замінити налаштований refspec, щоб розмістити всі посилання в просторі імен refs/prefetch/. Див. завдання prefetch у git-maintenance[1].
-p
--prune: Перед завантаженням видалити усі посилання на віддалені відстеження, які більше не існують на віддаленому репозиторії. Теги не підлягають очищенню, якщо вони завантажуються лише завдяки типовому автоматичному відстеженню тегів або через опцію --tags. Однак, якщо теги завантажуються через явний refspec (або в командному рядку, або в конфігурації віддаленого репозиторію, наприклад, якщо віддалений репозиторій було клоновано з опцією --mirror), то вони також підлягають очищенню. Вказання --prune-tags є скороченим варіантом надання refspec тегу.

Дивіться розділ ОЧИЩЕННЯ нижче для отримання додаткової інформації.
-P
--prune-tags: Перед отриманням даних видалити усі локальні теги, яких більше немає на віддаленому сервері, якщо увімкнено --prune. Цю опцію слід використовувати обережніше, на відміну від --prune, вона видалить усі створені локальні посилання (локальні теги). Ця опція є скороченням для надання явного значення тегу refspec разом з --prune, див. обговорення цього в документації.

Дивіться розділ ОЧИЩЕННЯ нижче для отримання додаткової інформації.
-n
--no-tags: За звичай теги, що вказують на об’єкти, завантажені з віддаленого репозиторію, отримуються та зберігаються локально. Ця опція вимикає таке автоматичне відстеження тегів. Стандартну поведінку для віддаленого репозиторію можна вказати за допомогою параметра remote.<name>.tagOpt. Див. git-config[1].
--refetch: Замість того, щоб узгоджувати з сервером, щоб уникнути передачі комітів та пов’язаних об’єктів, які вже є локально, ця опція завантажує всі об’єкти так, як це робив би новий клон. Використовуйте цю опцію для повторного застосування фільтра часткового клонування з конфігурації або за допомогою параметра --filter=, якщо визначення фільтра змінилося. Автоматичне обслуговування після завантаження виконає консолідацію пакунків бази даних об’єктів, щоб видалити всі дублікати об’єктів.
--refmap=<refspec>: Під час завантаження посилань, вказаних у командному рядку, використовуйте вказаний refspec (його можна вказати кілька разів) для зіставлення посилань із гілками, що відстежуються на віддаленому сервері, замість значень конфігураційних змінних remote. <name>.fetch для віддаленого репозиторію. Вказання порожнього <refspec> для опції --refmap змушує Git ігнорувати налаштовані refspec та повністю покладатися на refspec, вказані як аргументи командного рядка. Дивіться розділ «Налаштовані гілки віддаленого відстеження» для детальної інформації.
-t
--tags: Завантажити всі теги з віддаленого репозиторію (тобто завантажити теги з refs/tags/* у локальні теги з тими самими іменами), на додачу до всього іншого, що завантажується звичайним чином. Використання лише цієї опції не призводить до видалення тегів, навіть якщо вказано --prune (хоча теги можуть бути видалені в будь-якому разі, якщо вони також є пунктом призначення явного refspec; див. --prune).
--recurse-submodules[=(yes|on-demand|no)]: Визначає, чи слід також завантажувати нові коміти субмодулів і за яких умов. Під час рекурсивного обходу субмодулів команда git fetch завжди намагається завантажити «змінені» субмодулі, тобто ті, що містять коміти, на які посилається щойно завантажений коміт суперпроєкту, але яких немає у локальному клоні субмодуля. Змінений субмодуль можна отримати, якщо він присутній локально, наприклад, у $GIT_DIR/modules/ (див. gitsubmodules[7]); якщо у верхньому рівні додано новий субмодуль, його не можна отримати, доки його не клоновано, наприклад, за допомогою git submodule update.

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

Якщо не вказано значення, використовується значення fetch.recurseSubmodules, якщо воно встановлено (див. git-config[1]), типово використовується значення on-demand, якщо не встановлено. Коли цей параметр використовується без значення, стандартно використовується значення yes.
-j <n>
--jobs=<n>: Робити всі операції завантаження паралельно, до <n> завдань одночасно.

Якщо вказано значення 0, буде використано якесь обґрунтоване стандартне значення.

Якщо вказано параметр --multiple, завантаження даних з різних віддалених репозиторіїв відбуватиметься паралельно. Якщо завантажується кілька субмодулів, їх завантаження також відбуватиметься паралельно. Щоб керувати цими процесами незалежно один від одного, скористайтеся параметрами конфігурації fetch.parallel та submodule.fetchJobs (див. git-config[1]).

Як правило, паралельні рекурсивні та множинні віддалені запити виконуються швидше. Стандартно запити виконуються послідовно, а не паралельно.
--no-recurse-submodules: Вимкнути рекурсивне завантаження субмодулів (це дає той самий ефект, що й використання опції --recurse-submodules=no).
--set-upstream: Якщо віддалений репозиторій завантажено успішно, додайте посилання на висхідний репозиторій (upstream для відстеження), яке використовується командою git-pull[1] без аргументів та іншими командами. Докладнішу інформацію див. у розділах branch.<name>.merge та branch.<name>.remote у файлі git-config[1].
--submodule-prefix=<path>: Додавати префікс <path> до шляхів, що виводяться в інформаційних повідомленнях, таких як «Завантаження субмодуля foo». Ця опція використовується внутрішньо під час рекурсивного обходу субмодулів.
--recurse-submodules-default=(yes|on-demand): Цей параметр використовується внутрішньо для тимчасового надання невід’ємного стандартного значення для параметра --recurse-submodules. Усі інші способи налаштування рекурсії субмодулів у fetch (наприклад, параметри у файлах gitmodules[5] та git-config[1]) мають пріоритет над цим параметром, так само як і пряме вказання параметра --[no-]recurse-submodules.
-u
--update-head-ok: Типово команда git fetch не оновлює головну гілку, що відповідає поточній гілці. Цей прапорець вимикає цю перевірку. Він призначений виключно для внутрішнього використання командою git pull з метою взаємодії з git fetch, і, якщо ви не створюєте власний механізм Porcelain, вам не слід його використовувати.
--upload-pack <upload-pack>: Якщо вказано цей параметр, а репозиторій, з якого потрібно завантажити дані, обробляється командою git fetch-pack, то до команди передається параметр --exec=<upload-pack>, щоб вказати нестандартний шлях для команди, яка виконується на іншому боці.
-q
--quiet: Передайте аргумент --quiet команді git-fetch-pack та вимкніть виведення повідомлень для всіх інших внутрішніх команд Git. Інформація про хід виконання не виводитиметься у стандартний потік помилок.
-v
--verbose: Докладний вивід.
--progress: Прогрес роботи зазвичай показується у стандартному потоці помилок, якщо програма приєднана до терміналу, за винятком випадків, коли вказано параметр -q. Цей параметр примусово виводить інформацію про прогрес, навіть якщо стандартний потік помилок не спрямований в термінал.
-o <option>
--server-option=<опція>: Передавати вказаний рядок на сервер під час зв’язку за допомогою протоколу версії 2. Вказаний рядок не повинен містити символів NUL або LF. Обробка сервером опцій, включаючи невідомі, залежить від конкретного сервера. Якщо вказано декілька --server-option=<option>, вони всі надсилаються на інший бік у порядку, вказаному в командному рядку. Якщо в командному рядку не вказано --server-option=<option>, замість цього використовуються значення змінної конфігурації remote.<name>.serverOption.
--show-forced-updates: Зазвичай git під час завантаження перевіряє, чи гілка оновлюється примусово. Цю функцію можна вимкнути за допомогою параметра fetch.showForcedUpdates, але опція --show-forced-updates гарантує, що така перевірка відбудеться. Див. git-config[1].
--no-show-forced-updates: Зазвичай git під час завантаження перевіряє, чи гілка оновлюється примусово. Щоб пропустити цю перевірку з метою підвищення продуктивності, передайте аргумент --no-show-forced-updates або встановіть для параметра fetch.showForcedUpdates значення false. Якщо опція --ff-only використовується під час виконання команди git-pull, перевірка на наявність примусових оновлень все одно відбуватиметься перед спробою оновлення методом fast-forward. Див. git-config[1].
-4
--ipv4: Використовувати лише адреси IPv4, ігноруючи адреси IPv6.
-6
--ipv6: Використовувати лише адреси IPv6, ігноруючи адреси IPv4.

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

<refspec>

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

Формат параметра <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

Коли відомо, що віддалена гілка, яку ви хочете отримати, регулярно перемотується та перебазується, очікується, що її нова вершина не буде нащадком попередньої вершини (як вона зберігалася у вашій гілці з віддаленим відстеженням під час останнього отримання). Вам слід використовувати знак +, щоб вказати, що для таких гілок будуть потрібні оновлення без перемотування вперед. Немає способу визначити або оголосити, що гілка буде доступною в репозиторії з такою поведінкою; користувач, що витягує дані, просто повинен знати, що це очікуваний шаблон використання гілки.

--stdin: Окрім аргументів, що передаються у командному рядку, зчитує refspecs по одному в кожному рядку зі стандартного вводу. Формат «tag <name>» не підтримується.

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 fetch дозволяє налаштувати змінні конфігурації remote.<repository>.fetch.

Зазвичай така змінна може виглядати так:

[remote "origin"]
	fetch = +refs/heads/*:refs/remotes/origin/*

Ця конфігурація використовується двома способами:

Коли команда git fetch виконується без зазначення гілок та/або тегів для завантаження в командному рядку, наприклад git fetch origin або git fetch, як refspecs використовуються значення remote.<repository>.fetch — вони визначають, які посилання завантажувати та які локальні посилання оновлювати. У наведеному вище прикладі будуть завантажені всі гілки, що існують в origin (тобто будь-які ref, що відповідають лівій частині значення, refs/heads/*) та оновлені відповідні гілки віддаленого відстеження в ієрархії refs/remotes/origin/*.
Коли команда git fetch виконується з явно вказаними гілками та/або тегами для завантаження в командному рядку, наприклад git fetch origin master, то саме <refspec>, вказані в командному рядку, визначають, що саме потрібно завантажити (наприклад, master у прикладі, що є скороченим варіантом master:, що своєю чергою, означає «завантажити гілку master, але я явно не вказую, яку гілку віддаленого відстеження оновлювати нею з командного рядка»), і команда з прикладу завантажить лише гілку master. Значення remote.<repository>.fetch визначають, яка гілка віддаленого відстеження, якщо така є, оновлюється. При такому використанні значення remote.<repository>.fetch не впливають на рішення, що завантажується (тобто ці значення не використовуються як refspecs, коли командний рядок перелічує refspecs); вони використовуються лише для визначення, де зберігаються завантажені refs, діючи як зіставлення.

Останнє використання значень remote.<repository>.fetch можна перевизначити, надавши параметр(и) --refmap=<refspec> у командному рядку.

ОЧИЩЕННЯ

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

Якщо дозволити цим застарілим посиланням накопичуватися, вони можуть погіршити продуктивність великих і активних репозиторіїв, де відбувається часта зміна гілок, і, наприклад, зробити вивід команд на кшталт git branch -a --contains <commit> надмірно розлогим, а також вплинути на будь-які інші процеси, що працюють із повним набором відомих посилань.

Ці посилання на віддалене відстеження можна одноразово видалити за допомогою одного з цих способів:

# Під час завантаження
$ git fetch --prune <name>

# Тільки очистити, не завантажувати
$ git remote prune <name>

Щоб очищати посилання в рамках звичайного робочого процесу, не турбуючись про те, щоб не забути запустити цю операцію, вкажіть у конфігурації глобальний параметр fetch.prune або параметр remote.<name>.prune для кожного віддаленого екземпляра. Див. git-config[1].

Тут справа стає дещо складнішою та конкретнішою. Функція очищення насправді не звертає уваги на гілки, натомість вона очищає локальні ←→ віддалені посилання відповідно до refspec віддаленого екземпляра (див. <refspec> та НАЛАШТОВАНІ ГІЛКИ ВІДДАЛЕНОГО ВІДСТЕЖЕННЯ вище).

Отже, якщо refspec для віддаленого репозиторію містить, наприклад, refs/tags/*:refs/tags/*, або ви вручну запускаєте, наприклад, git fetch --prune <name> "refs/tags/*:refs/tags/*", то видалятися будуть не застарілі гілки віддаленого репозиторію, а будь-які локальні теги, яких немає у віддаленому репозиторії.

Можливо, це не зовсім те, чого ви очікуєте: ви хочете очистити віддалений репозиторій <name>, але при цьому явно завантажити з нього теги, тому під час завантаження ви видалите всі свої локальні теги, більшість з яких, можливо, і не походила з віддаленого репозиторію <name>.

Тому будьте обережні, використовуючи це з таким refspec, як refs/tags/*:refs/tags/*, або з будь-яким іншим refspec, який може зіставляти посилання з декількох віддалених репозиторіїв з одним і тим самим локальним простором імен.

Оскільки синхронізація гілок і тегів на віддаленому сервері є типовим випадком використання, можна вказати опцію --prune-tags разом з --prune, щоб видалити локальні теги, яких немає у віддаленому екземплярі, та примусово оновити ті теги, що відрізняються. Очищення тегів також можна увімкнути за допомогою fetch.pruneTags або remote.<name>.pruneTags у конфігурації. Див. git-config[1].

Параметр --prune-tags еквівалентний тому, що в refspecs віддаленого репозиторію вказано refs/tags/*:refs/tags/*. Це може призвести до деяких, на перший погляд, дивних взаємодій:

# Ці обидві команди завантажують теги
$ git fetch --no-tags origin 'refs/tags/*:refs/tags/*'
$ git fetch --no-tags --prune-tags origin

Причина, через яку система не видає помилку при запуску без параметра --prune або відповідних версій конфігурації, полягає у гнучкості налаштованих версій, а також у необхідності збереження співвідношення «1:1» між функціями параметрів командного рядка та функціями версій конфігурації.

Доцільно, наприклад, встановити параметр fetch.pruneTags=true у файлі ~/.gitconfig, щоб теги очищалися при виконанні команди git fetch --prune, при цьому не викликаючи помилку при кожному запуску команди git fetch без параметра --prune.

Очищення тегів за допомогою --prune-tags також працює при завантаженні URL-адреси замість віддаленого репозиторію за його назвою. Усі ці дії призведуть до видалення тегів, яких немає на сервері origin:

$ git fetch origin --prune --prune-tags
$ git fetch origin --prune 'refs/tags/*:refs/tags/*'
$ git fetch <url-of-origin> --prune --prune-tags
$ git fetch <url-of-origin> --prune 'refs/tags/*:refs/tags/*'

ВИВІД

Вивід команди «git fetch» залежить від використовуваного методу передачі даних; у цьому розділі описано вивід при завантаженні даних за протоколом Git (як локально, так і через SSH) та за протоколом Smart HTTP.

Статус запиту виводиться у вигляді таблиці, де кожен рядок показує статус окремого посилання. Кожен рядок має такий вигляд:

 <flag> <summary> <from> -> <to> [<reason>]

При використанні опції --porcelain формат виводу розрахований на машинний аналіз. На відміну від форматів виводу, призначених для читання людиною, він виводиться у стандартний вивід, а не у стандартний потік виводу помилок. Кожен рядок має такий вигляд:

<flag> <old-object-id> <new-object-id> <local-reference>

Статус актуальних посилань показується лише за наявності опції --verbose.

У режимі компактного виведення, що задається змінною конфігурації fetch.output, якщо в іншому рядку знайдено весь рядок <from> або <to>, він замінюється символом *. Наприклад, master -> origin/master перетворюється на master -> origin/*.

flag (прапорець)

Один символ, що вказує на статус посилання:

(пробіл): для успішно отриманого швидкого перемотування вперед (fast-forward);
+: для успішного примусового оновлення;
-: для успішного очищення посилання;
t: для успішного оновлення тегу;
*: для успішно отриманого нового посилання;
!: для посилання, яке було відхилено або не вдалося оновити; та
=: для актуального посилання, яке не потребувало отримання.

summary (підсумки)

У разі успішно отриманого посилання у підсумку відображаються старе та нове значення посилання у форматі, придатному для використання у вигляді аргументу команди git log (у більшості випадків це <old>..<new>, а для примусових оновлень, що не є fast-forward, — <old>...<new>).

з (from)

Імʼя віддаленого посилання, з якого здійснюється отримування, без префікса refs/<type>/. У разі видалення ім’я віддаленого посилання — «(none)».

до (to)

Назва локального посилання, що оновлюється, мінус його префікс refs/<тип>/.

причина (reason)

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

ПРИКЛАДИ

Оновлення гілки віддаленого відстеження:
```
$ git fetch origin
```
Зазначена вище команда копіює всі гілки з віддаленого простору імен refs/heads/ і зберігає їх у локальному просторі імен refs/remotes/origin/, якщо тільки для вказання нестандартного refspec не використовується опція remote.<repository>.fetch.
Явне використання refspecs:
```
$ git fetch origin +seen:seen maint:tmp
```
Ця команда оновлює (або, за необхідності, створює) гілки seen та tmp у локальному репозиторії, завантажуючи дані з гілок (відповідно) seen та maint із віддаленого репозиторію.

Гілка seen буде оновлена, навіть якщо вона не перемотується вперед, оскільки перед нею стоїть знак плюс; гілка tmp цього не робитиме.
Переглянути гілку віддаленого репозиторію, без налаштування віддаленого репозиторію у вашому локальному репозиторії:
```
$ git fetch git://git.kernel.org/pub/scm/git/git.git maint
$ git log FETCH_HEAD
```
Перша команда отримує гілку maint з репозиторію за адресою git://git.kernel.org/pub/scm/git/git.git, а друга команда використовує FETCH_HEAD для перевірки гілки за допомогою git-log[1]. Завантажені об’єкти з часом будуть видалені вбудованою функцією очищення git (див. git-gc[1]).

БЕЗПЕКА

Протоколи fetch та push не призначені для запобігання викраденню однією стороною даних з іншого репозиторію, які не призначалися для спільного використання. Якщо у вас є приватні дані, які потрібно захистити від зловмисного користувача, найкращим варіантом буде зберігати їх в іншому репозиторії. Це стосується як клієнтів, так і серверів. Зокрема, простори імен на сервері не є ефективними для контролю доступу на читання; ви повинні надавати доступ на читання до простору імен лише тим клієнтам, яким ви довіряєте доступ на читання до всього репозиторію.

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

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

КОНФІГУРАЦІЯ

Все, що знаходиться нижче цього рядка в цьому розділі, вибірково включено з документації git-config[1]. Вміст такий самий, як і там:

fetch.recurseSubmodules: Ця опція визначає, чи буде команда git fetch (а також відповідний виклик fetch у команді git pull) рекурсивно завантажувати дані в субмодулі. Цю опцію можна встановити як булеве значення або як on-demand. Встановлення булевого значення змінює поведінку команд fetch і pull: при значенні true вони беззастережно виконують рекурсію в субмодулях, а при значенні false — не виконують її взагалі. При значенні on-demand, команди fetch та pull будуть рекурсивно завантажувати дані в заповнений субмодуль тільки тоді, коли його суперпроєкт отримує коміт, що оновлює посилання субмодуля. Стандартним значенням є on-demand, або значення submodule.recurse, якщо воно встановлено.
fetch.fsckObjects: Якщо встановлено — true, git-fetch-pack перевірятиме всі отримані обʼєкти. Див. transfer.fsckObjects щоб дізнатись що перевіряється. Стандартно – false. Якщо не встановлено, використовується значення з transfer.fsckObjects.
fetch.fsck.<msg-id>: Діє так само як fsck.<msg-id> але використовується git-fetch-pack[1] а не git-fsck[1]. Див. fsck.<msg-id> для отримання докладних відомостей.
fetch.fsck.skipList: Діє так само як й fsck.skipList`але використовується в git-fetch-pack[1] а не в git-fsck[1]. Див. `fsck.skipList для отримання докладних відомостей.
fetch.unpackLimit: Якщо кількість об’єктів, отриманих за допомогою вбудованої функції передачі Git, не перевищує цього обмеження, об’єкти будуть розпаковані у вигляді окремих файлів. Однак якщо кількість отриманих об’єктів дорівнює цьому обмеженню або перевищує його, отриманий пакунок буде збережено як пакунок після додавання будь-яких відсутніх базових файлів дельта. Збереження пакунка з операції push може прискорити завершення цієї операції, особливо на повільних файлових системах. Якщо це значення не вказано, замість нього використовується значення transfer.unpackLimit.
fetch.prune: Якщо значення —true, fetch буде поводитись так ніби опцію --prune було вказано в командному рядку. Див. також remote.<name>.prune та розділ ОЧИЩЕННЯ в git-fetch[1].
fetch.pruneTags: Якщо значення — true, то під час очищення fetch автоматично поводитиметься так, ніби під час очищення було вказано refspec refs/tags/*:refs/tags/*, якщо він ще не встановлений. Це дозволяє встановити як цей параметр, так і fetch.prune, щоб зберегти співвідношення 1:1 з refs upstream. Див. також remote.<name>.pruneTags та розділ ОЧИЩЕННЯ в git-fetch[1].
fetch.all: Якщо значення — true, fetch намагатиметеся оновлювати всі доступні remotes. Цю поведінку можна перевизначити використанням параметра --no-all або явним вказанням одного чи більше remote для fetch. Стандартно – false.
fetch.output: Керує тим, як показується статус оновлення ref. Допустимі значення: full та compact. Стандартне значення — full. Детальніше див. розділ ВИВІД у документації git-fetch[1].
fetch.negotiationAlgorithm: Керує тим, як надсилається інформація про коміти в локальному репозиторії під час узгодження вмісту файлу packfile, який має надіслати сервер. Встановіть значення consecutive, щоб використовувати алгоритм, який послідовно перевіряє кожен з послідовних комітів. Встановіть значення skipping, щоб використовувати алгоритм, який пропускає коміти з метою швидшого збігу, але це може призвести до створення файлу packfile, розмір якого перевищує необхідний; або встановіть значення noop, щоб не надсилати жодної інформації, що майже напевно призведе до створення файлу packfile, розмір якого перевищує необхідний, але дозволить пропустити етап узгодження. Встановіть значення default, щоб замінити попередні налаштування та скористатися стандартною поведінкою. Стандартним значенням зазвичай є consecutive, але якщо feature.experimental має значення true, то стандартним значенням є skipping. Невідомі значення призведуть до помилки git fetch.

Дивіться також --negotiate-only та --negotiation-tip в git-fetch[1].
fetch.showForcedUpdates: Значення false дозволяє використовувати --no-show-forced-updates в командах git-fetch[1] та git-pull[1]. Стандартно — true.
fetch.parallel: Вказує максимальну кількість операцій завантаження, які одночасно виконуються паралельно (субмодулі або віддалені репозиторії, якщо активна опція --multiple команди git-fetch[1]).

Значення 0 забезпечить обґрунтовані стандартні налаштування. Якщо параметр не вказано, стандартним значенням буде 1.

Для субмодулів це налаштування можна замінити за допомогою параметра конфігурації submodule.fetchJobs.
fetch.writeCommitGraph: Встановіть значення true, щоб записувати граф комітів після кожної команди git fetch, яка завантажує файл pack з віддаленого репозиторію. При використанні опції --split більшість операцій створюватимуть дуже невеликий файл графа комітів поверх наявних файлів графа комітів. Іноді ці файли обʼєднуються, і запис може тривати довше. Наявність оновленого файлу графа комітів покращує продуктивність багатьох команд Git, зокрема git merge-base, git push -f та git log --graph. Стандартне значення — false.
fetch.bundleURI: Це значення зберігає URI для завантаження даних об’єктів Git із URI набору перед виконанням інкрементального завантаження з оригінального сервера Git. Це схоже на те, як працює опція --bundle-uri у команді git-clone[1]. Команда git clone --bundle-uri встановить значення fetch.bundleURI, якщо вказаний URI набору містить список наборів, організований для інкрементального завантаження.

Якщо ви зміните це значення, а у вашому репозиторії вже є значення fetch.bundleCreationToken, то перед завантаженням за новим URI набору видаліть це значення fetch.bundleCreationToken.
fetch.bundleCreationToken: При використанні fetch.bundleURI для поступового завантаження зі списку наборів, що використовує евристику «creationToken», це значення конфігурації зберігає максимальне значення creationToken завантажених наборів. Це значення використовується для запобігання завантаженню наборів у майбутньому, якщо оголошене значення creationToken не є строго більшим за це значення.

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

ПОМИЛКИ

Використання параметра --recurse-submodules дозволяє завантажувати нові коміти лише з тих субмодулів, які вже існують локально, наприклад, у теці $GIT_DIR/modules/. Якщо у висхідному репозиторії додано новий субмодуль, його неможливо завантажити, доки його не буде клоновано, наприклад, за допомогою команди git submodule update. Очікується, що ця проблема буде виправлена в майбутніх версіях Git.

ДИВ. ТАКОЖ

git-pull[1]

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

Setup and Config

Getting and Creating Projects

Basic Snapshotting

Branching and Merging

Sharing and Updating Projects

Inspection and Comparison

Patching

Debugging

Email

External Systems

Server Admin

Guides

Administration

Plumbing Commands