[go: up one dir, main page]
українська мова ▾ Topics ▾ Latest version ▾ git-fetch last updated in 2.53.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.

--write-fetch-head
--no-write-fetch-head

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

-f
--force

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

-k
--keep

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

--multiple

Дозволяє вказувати кілька аргументів <репозиторій> та <група>. Не можна вказувати <посилання>s.

--auto-maintenance
--no-auto-maintenance
--auto-gc
--no-auto-gc

Виконайте git maintenance run --auto в кінці, щоб виконати автоматичне обслуговування репозиторію, якщо це необхідно. Це ввімкнено за замовчуванням.

--write-commit-graph
--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.<name>.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.

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

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

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

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

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

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

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

  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]