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

НАЗВА

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

СИНОПСИС

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

ОПИС

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

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

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

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

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

ОПЦІЇ

--[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.

--[no-]write-fetch-head

Записати список віддалених посилань, отриманих у файлі FETCH_HEAD, безпосередньо в $GIT_DIR. Це значення за замовчуванням. Передача --no-write-fetch-head з командного рядка вказує Git не записувати файл. З опцією --dry-run файл ніколи не записується.

-f
--force

Коли git fetch використовується з <src>:<dst> refspec, він може відмовитися оновлювати локальну гілку, як обговорювалося in the <refspec> part below. Цей параметр замінює цю перевірку.

-k
--keep

Збережіть завантажений пакет.

--multiple

Дозволяє вказувати кілька аргументів <repository> та <group>. Не можна вказувати <refspec>.

--[no-]auto-maintenance
--[no-]auto-gc

Виконайте git maintenance run --auto в кінці, щоб виконати автоматичне обслуговування репозиторію, якщо це необхідно. (--[no-]auto-gc – синонім.) Це вмикається за допомогою.

--[no-]write-commit-graph

Записати граф комітів після отримання. Це замінює налаштування конфігурації fetch.writeCommitGraph.

--prefetch

Змініть налаштовану специфікацію посилань, щоб розмістити всі посилання в просторі імен refs/prefetch/. Див. завдання prefetch у git-maintenance[1].

-p
--prune

Перед отриманням видаліть усі посилання на віддалене відстеження, яких більше немає на віддаленому сервері. Теги не підлягають обрізанню, якщо вони отримані лише через автоматичне слідування за тегами за замовчуванням або через опцію --tags. Однак, якщо теги отримані через явну специфікацію посилань (або в командному рядку, або в конфігурації віддаленого сервера, наприклад, якщо віддалений сервер було клоновано з опцією --mirror), то вони також підлягають обрізанню. Надання --prune-tags – це скорочення для надання специфікації посилань на теги.

Дивіться розділ ОБРІЗКА нижче для отримання додаткової інформації.

-P
--prune-tags

Перед отриманням даних видаліть усі локальні теги, яких більше немає на віддаленому сервері, якщо увімкнено --prune. Цю опцію слід використовувати обережніше, на відміну від --prune, вона видалить усі створені локальні посилання (локальні теги). Ця опція є скороченням для надання явного значення тегу refspec разом з --prune, див. обговорення цього в документації.

Дивіться розділ ОБРІЗКА нижче для отримання додаткової інформації.

-n
--no-tags

За замовчуванням теги, що вказують на об’єкти, завантажені з віддаленого репозиторію, отримуються та зберігаються локально. Ця опція вимикає автоматичне відстеження тегів. Поведінку за замовчуванням для віддаленого репозиторію можна вказати за допомогою параметра remote.<name>.tagOpt. Див. git-config[1].

--refetch

Замість узгодження із сервером, щоб уникнути перенесення комітів та пов’язаних об’єктів, які вже присутні локально, ця опція отримує всі об’єкти так, як це зробив би новий клон. Використовуйте це, щоб повторно застосувати фільтр часткового клонування з конфігурації або за допомогою --filter=, коли визначення фільтра змінилося. Автоматичне обслуговування після отримання виконає консолідацію пакетів бази даних об’єктів, щоб видалити будь-які дублікати об’єктів.

--refmap=<refspec>

Під час отримання посилань, перелічених у командному рядку, використовуйте вказану специфікацію посилань (можна вказати більше одного разу) для зіставлення посилань з гілками віддаленого відстеження, замість значень змінних конфігурації remote.*.fetch для віддаленого репозиторію. Надання порожньої <refspec> для опції --refmap призведе до того, що Git ігноруватиме налаштовані специфікації посилань та повністю покладатиметься на специфікації посилань, надані як аргументи командного рядка. Див. розділ "Налаштовані гілки віддаленого відстеження" для отримання детальної інформації.

-t
--tags

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

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

Цей параметр контролює, чи слід також отримувати нові коміти підмодулів і за яких умов. Під час рекурсії через підмодулі, git fetch завжди намагається отримати "змінені" підмодулі, тобто підмодуль, який містить коміти, на які посилається щойно отриманий коміт суперпроекту, але відсутні в локальному клоні підмодуля. Змінений підмодуль можна отримати, якщо він присутній локально, наприклад, у $GIT_DIR/modules/ (див. gitsubmodules[7]); якщо основний твір додає новий підмодуль, цей підмодуль не можна отримати, доки він не буде клонований, наприклад, за допомогою git submodule update.

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

Якщо не вказано значення, використовується значення fetch.recurseSubmodules, якщо воно встановлено (див. git-config[1]), за замовчуванням використовується значення on-demand, якщо не встановлено. Коли цей параметр використовується без значення, значення за замовчуванням використовується значення yes.

-j
--jobs=<n>

Кількість паралельних дочірніх об’єктів, які будуть використовуватися для всіх форм вибірки.

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

Зазвичай паралельні рекурсивні та багатовіддалені вибірки будуть швидшими. За замовчуванням вибірки виконуються послідовно, а не паралельно.

--no-recurse-submodules

Вимкнути рекурсивне отримання підмодулів (це має той самий ефект, що й використання опції --recurse-submodules=no).

--set-upstream

Якщо віддалений доступ успішно отримано, додайте посилання на вихідний код (відстеження), яке використовується командою git-pull[1] без аргументів та іншими командами. Для отримання додаткової інформації див. branch.<name>.merge та branch.<name>.remote у git-config[1].

--submodule-prefix=<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=<опція>, усі вони надсилаються іншій стороні в порядку, зазначеному в командному рядку. Якщо параметр --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 нижче).

<group>

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

<refspec>

Визначає, які посилання потрібно отримати, а які локальні посилання потрібно оновити. Якщо в командному рядку немає <refspec>, посилання для отримання зчитуються зі змінних remote.<repository>.fetch (see CONFIGURED REMOTE-TRACKING BRANCHES below).

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

Зчитує специфікації посилань, по одній на рядок, зі stdin на додаток до тих, що надані як аргументи. Формат "tag <назва>" не підтримується.

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

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

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

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

  • Коли git fetch виконується без вказівки, які гілки та/або теги отримувати в командному рядку, наприклад, git fetch origin або git fetch, значення remote.<repository>.fetch використовуються як специфікації посилань – вони вказують, які посилання отримувати та які локальні посилання оновлювати. У наведеному вище прикладі буде отримано всі гілки, що існують в origin (тобто будь-яке посилання, що відповідає лівій частині значення refs/heads/*), та оновлено відповідні гілки віддаленого відстеження в ієрархії refs/remotes/origin/*.

  • Коли git fetch запускається з явними гілками та/або тегами для вибірки в командному рядку, наприклад, git fetch origin master, <refspec>, задані в командному рядку, визначають, що потрібно вибрати (наприклад, master у прикладі, що є скороченням від master:, що, у свою чергу, означає "отримати гілку master, але я не вказую явно, яку гілку віддаленого відстеження оновлювати нею з командного рядка"), і команда прикладу отримає лише гілку master. Значення remote.<repository>.fetch визначають, яка гілка віддаленого відстеження, якщо така є, оновлюється. При такому використанні значення remote.<repository>.fetch не мають жодного впливу на визначення того, що потрібно вибрати (тобто значення не використовуються як refspecs, коли командний рядок перераховує refspecs); вони використовуються лише для визначення де зберігаються вибрані посилання, діючи як відображення.

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

Обрізка

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

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

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

# While fetching
$ git fetch --prune <name>

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

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

Ось тут-то все стає складнішим і більш специфічним. Функція обрізання насправді не звертає уваги на гілки, натомість вона обрізатиме локальні ←→ віддалені посилання як функцію специфікації віддаленого об’єкта (див. <refspec> та CONFIGURED REMOTE-TRACKING BRANCHES вище).

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

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

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

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

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

# Ці обидва теги вилучення
$ 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-адреси замість іменованого віддаленого об’єкта. Це призведе до обрізання всіх тегів, які не знайдено на оригіналі:

$ 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/*.

прапор

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

(простір)

для успішно отриманого швидкого перемотування вперед;

+

для успішного примусового оновлення;

-

для успішно обрізаного посилання;

t

для успішного оновлення тегу;

*

для успішно отриманого нового посилання;

!

для посилання, яке було відхилено або не вдалося оновити; та

=

для актуального посилання, яке не потребувало отримання.

короткий зміст

Для успішно отриманого посилання, зведення показує старі та нові значення посилання у формі, придатній для використання як аргумент git log (у більшості випадків це <old>..<new>, а <old>...<new> для примусових оновлень без перемотування вперед).

з

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

до

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

причина

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

ПРИКЛАДИ

  • Оновіть гілки віддаленого відстеження:

    $ git fetch origin

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

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

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

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

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

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

Warning

Missing uk/config/fetch.adoc

See original version for this content.

ПОМИЛКИ

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

ДИВ. ТАКОЖ

git-pull[1]

GIT

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