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

НАЗВА

git-status — Перегляд стану робочого дерева

СИНОПСИС

git status [<options>] [--] [<pathspec>…​]

ОПИС

Показує шляхи, у яких є розбіжності між індексним файлом і поточним комітом HEAD; шляхи, у яких є розбіжності між робочим деревом і індексним файлом; а також шляхи в робочому дереві, які не відстежуються Git (і не ігноруються за допомогою gitignore[5]). Перші — це те, що ви мали б зафіксувати, виконавши команду git commit; другі та треті — це те, що ви могли б зафіксувати, виконавши команду git add перед виконанням git commit.

ОПЦІЇ

-s
--short

Надавати результат у скороченому форматі.

-b
--branch

Показувати інформацію про гілку та інформацію про відстеження навіть у скороченому форматі.

--show-stash

Показати кількість записів, що наразі зберігаються в сховищі stash.

--porcelain[=<version>]

Надавати вихідні дані у форматі, зручному для обробки скриптами. Це схоже на стислий вивід, але залишатиметься незмінним у різних версіях Git та незалежно від налаштувань користувача. Детальніше див. нижче.

Параметр <version> використовується для визначення версії формату. Є опціональним, стандартним значенням є формат оригінальної версії — v1.

--long

Виводити результат у розгорнутому форматі. Це стандартне значення.

-v
--verbose

Окрім назв файлів, які було змінено, також показувати текстові зміни, які підготовлені для фіксації (тобто, як у виводі git diff --cached). Якщо -v вказано двічі, тоді також показувати зміни в робочому дереві, які ще не знаходяться в stage (тобто, як у виводі git diff).

-u[<режим>]
--untracked-files[=<режим>]

Показує файли, які не відстежуютьтся в репозиторії.

Параметр mode використовується для визначення обробки не відстежуваних файлів. Є опціональним, стандартне значення  — all, коли його вказано, він має бути приєднаний до параметра (наприклад, -uno, але не -u no).

Можливі варіанти:

no

Не показувати файли, які не відстежуються.

normal

Показати файли та теки, що не відстежуються.

all

Також показувати окремі файли в теках, що не відстежуються.

Якщо опція -u не використовується, відображаються файли та теки, що не відстежуються (тобто це те саме, що вказати normal), щоб ви не забули додати новостворені файли. Оскільки пошук файлів, що не відстежуються, у файловій системі вимагає додаткових зусиль, у великому робочому дереві цей режим може зайняти деякий час. Розгляньте можливість увімкнення кешу невідстежуваних файлів та розділеного індексу, якщо це підтримується (див. git update-index --untracked-cache та git update-index --split-index). В іншому випадку ви можете використовувати no, щоб git status повертав результати швидше, не показуючи невідстежуваних файлів. Усі звичайні написання булевого значення true трактуються як normal, а false — як no.

Стандартне значення можна змінити за допомогою змінної конфігурації status.showUntrackedFiles, описаної в документації git-config[1].

--ignore-submodules[=<when>]

Ігнорувати зміни в субмодулях під час пошуку змін. <when> може мати значення none, untracked, dirty або all, яке є стандартним значенням.

none

вважати субмодуль зміненим, якщо він містить невідстежувані або змінені файли, або його HEAD відрізняється від коміту, записаного в суперпроєкті, і може бути використаний для перевизначення будь-яких налаштувань опції ignore в git-config[1] або gitmodules[5].

untracked

субмодулі не вважаються зміненими (dirty), якщо вони містять лише вміст, що не відстежується (проте вони все одно скануються на наявність зміненого вмісту).

dirty

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

all

приховувати всі зміни в субмодулях (та придушувати вивід підсумків для субмодулів, коли встановлено параметр конфігурації status.submoduleSummary).

--ignored[=<mode>]

Також показувати ігноровані файли.

Параметр mode використовується для визначення обробки ігнорованих файлів. Є опціональним, стандартне значення — traditional.

Можливі варіанти:

traditional

Показувати ігноровані файли та теки, якщо не вказано --untracked-files=all, у такому разі відображаються окремі файли в ігнорованих теках.

no

Не показувати ігноровані файли.

matching

Показувати ігноровані файли та теки, що відповідають шаблону ігнорування.

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

-z

Завершувати записи символом NUL замість LF. Це має на увазі формат виводу --porcelain=v1, якщо не вказано інший формат.

--column[=<опція>]
--no-column

Показувати файли, що не відстежуються, у стовпцях. Синтаксис параметрів див. у змінній конфігурації column.status. Параметри --column та --no-column без додаткових опцій відповідають значенням always та never відповідно.

--ahead-behind
--no-ahead-behind

Показувати або ні детальні показники відставання/випередження гілки відносно її висхідної (upstream) гілки. Стандартне значення  — true.

--renames
--no-renames

Увімкнути/вимкнути виявлення перейменування незалежно від налаштувань користувача. Див. також git-diff[1] --no-renames.

--find-renames[=<n>]

Увімкнути виявлення перейменування, за бажанням встановивши поріг подібності. Див. також git-diff[1] --find-renames.

<pathspec>...

Див. довідку pathspec у gitglossary[7].

ВИВІД

Вивід цієї команди призначений для використання як коментар шаблону коміту. Стандартний, довгий формат розроблений таким чином, щоб бути зрозумілим людині, докладним та описовим. Його вміст та формат можуть бути змінені в будь-який час.

Шляхи, згадані у виводі, на відміну від багатьох інших команд Git, створюються відносно поточної теки, якщо ви працюєте в субтеці (це зроблено навмисно, щоб полегшити копіювання та вставку). Дивіться параметр конфігурації status.relativePaths нижче.

Короткий формат

У скороченому форматі статус кожного шляху відображається в одній з цих форм

<xy> <path>
<xy> <orig-path> -> <path>

де <orig-path> — це походження перейменованого/скопійованого вмісту. <orig-path> відображається лише тоді, коли запис перейменовано або скопійовано. <xy> — це дволітерний код стану XY.

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

Існує три різні типи станів, що відображаються за допомогою цього формату, і кожен з них використовує синтаксис <xy> по-різному:

  • Коли відбувається злиття, і воно пройшло успішно, або поза межами злиття, у цій ситуації X показує стан індексу, а Y показує стан робочого дерева.

  • Коли виник конфлікт злиття, який ще не вирішено, X та Y показують стан, запроваджений кожною вершиною гілок злиття, відносно спільного предка. Ці шляхи називаються незлитими.

  • Коли шлях не відстежується, X та Y завжди однакові, оскільки індекс про них не знає. Для невідстежуваних шляхів використовується ??. Ігноровані файли не відображаються у списку, якщо не використовується параметр --ignored; у цьому випадку, ігноровані файли позначаються !!.

Зверніть увагу, що термін merge тут також включає перебазування з використанням стандартно стратегії --merge , копіювання комітів (cherry-pick) та будь-що інше, що використовує механізм злиття.

У наступній таблиці ці три класи показано в окремих розділах, а ці символи використовуються для полів X та Y для перших двох розділів, які показують відстежувані шляхи:

' '

незмінені

M

змінені

T

тип файлу змінено (звичайний файл, символічне посилання або субмодуль)

A

додані

D

вилучені

R

перейменовані

C

скопійовані (якщо для параметра конфігурації status.renames встановлено значення "copies")

U

оновлені, але не обʼєднані

X Y Значення

[AMD]

не оновлено

M

[ MTD]

оновлено в індексі

T

[ MTD]

тип змінено в індексі

A

[ MTD]

додано до індексу

D

видалено з індексу

R

[ MTD]

перейменовано в індексі

C

[ MTD]

скопійовано в індексі

[MTARC]

індекс і робоче дерево збігаються

[ MTARC]

M

робоче дерево змінено з моменту додавання в індекс

[ MTARC]

T

тип змінено в робочому дереві з моменту додавання в індекс

[ MTARC]

D

видалено в робочому дереві

R

перейменовано в робочому дереві

C

скопійовано в робочому дереві

D

D

необʼєднано, обидва видалені

A

U

необʼєднано, додано нами

U

D

необʼєднано, видалено ними

U

A

необʼєднано, додано ними

D

U

необʼєднано, видалено нами

A

A

необʼєднано, обидва додані

U

U

необʼєднано, обидва змінені

?

?

не відстежується

!

!

ігнорується

Субмодулі мають більше станів і замість цього повідомляють

M

субмодуль має значення HEAD, відмінне від записаного в індексі

m

субмодуль має змінений вміст

?

у субмодулі є файли, які не відстежуються

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

m та ? застосовуються рекурсивно. Наприклад, якщо вкладений субмодуль у субмодулі містить невідстежуваний файл, це також повідомляється як ?.

Якщо використовується опція -b, перед статусом у стислому форматі йде рядок

{empty}## <branchname> <tracking-info>

Формат Porcelain, версія 1

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

  1. Налаштування користувача color.status не враховується; колір завжди буде вимкнено.

  2. Налаштування користувача status.relativePaths не враховується; показані шляхи завжди будуть відносними до кореневої теки репозиторію.

Також існує альтернативний формат -z, рекомендований для обробки машиною. У цьому форматі поле статусу залишається незмінним, але деякі інші елементи змінюються. По-перше, у записах про перейменування опускається символ ->, а порядок полів змінюється на зворотний (наприклад, from -> to стає to from). По-друге, за кожним іменем файлу йде NUL (ASCII 0), що замінює пробіл як роздільник полів та завершальний символ нового рядка (але пробіл все ще відокремлює поле статусу від першого імені файлу). По-третє, імена файлів, що містять спеціальні символи, не форматуються окремо; не застосовуються лапки чи екранування за допомогою зворотної косої риски.

Будь-які зміни субмодулів показуються як зміни M замість m або одинарного ?.

Формат Porcelain, версія 2

Формат версії 2 додає детальнішу інформацію про стан робочого дерева та змінені елементи. Версія 2 також визначає розширюваний набір простих для розбору опціональних заголовків.

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

Заголовки гілок

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

Рядок Примітки

# branch.oid <commit> | (initial)

Поточний коміт.

# branch.head <branch> | (detached)

Поточна гілка.

# branch.upstream <upstream-branch>

Якщо встановлено upstream.

# branch.ab +<ahead> -<behind>

Якщо встановлено upstream і коміт присутній.

Інформація про Stash

Якщо вказано --show-stash, виводиться один рядок, який показує кількість записів stash, якщо вони не нульові:

# stash <N>

Змінені відстежувані елементи

За заголовками виводиться низка рядків, що містять відстежувані записи. Для опису запису може використовуватися один із трьох різних форматів рядків, залежно від типу зміни. Відстежувані записи виводяться у довільному порядку; парсери повинні враховувати можливість поєднання цих трьох типів рядків у будь-якому порядку.

Звичайні змінені записи мають такий формат:

1 <XY> <sub> <mH> <mI> <mW> <hH> <hI> <path>

Перейменовані або скопійовані записи мають такий формат:

2 <XY> <sub> <mH> <mI> <mW> <hH> <hI> <X><score> <path><sep><origPath>
Поле Значення

<XY>

Поле з 2 символів, що містить значення XY, які включені та не включені до stage, у короткому форматі, де незмінені значення позначаються крапкою, а не пробілом.

<sub>

Поле з 4 символів, що описує стан субмодуля.

"N…​" коли запис не є субмодулем.

S<c><m><u> коли запис є субмодулем.

  • <c> є "C" якщо коміт змінився; інакше ".".

  • <m> дорівнює "M", якщо відстежуються зміни; інакше ".".

  • <u> дорівнює "U", якщо є невідстежені зміни; інакше ".".

<mH>

Вісімковий режим файлу в HEAD.

<mI>

Вісімковий режим файлу в індексі.

<mW>

Вісімковий режим файлу в робочому дереві.

<hH>

Імʼя обʼєкта в HEAD.

<hI>

Імʼя обʼєкта в індексі.

<X><score>

Оцінка перейменування або копіювання (що позначає відсоток подібності між джерелом та цільовим обʼєктом переміщення або копіювання). Наприклад, "R100" або "C75".

<path>

Шлях. У перейменованому/скопійованому записі це цільовий шлях.

<sep>

Коли використовується параметр -z, 2 імені шляхів розділяються байтом NUL (ASCII 0x00); інакше їх розділяє TAB (ASCII 0x09).

<origPath>

Шлях у коміті в HEAD або в індексі. Присутній лише у перейменованому/скопійованому записі та вказує, звідки взявся перейменований/скопійований вміст.

Необʼєднані записи мають такий формат; перший символ — це «u», щоб відрізнити їх від звичайних змінених записів.

u <XY> <sub> <m1> <m2> <m3> <mW> <h1> <h2> <h3> <path>
Поле Значення

<XY>

2-символьне поле, що описує тип конфлікту як описано в короткому форматі.

<sub>

4-символьне поле, що описує стан субмодуля як описано вище.

<m1>

Вісімковий режим файлу в stage 1.

<m2>

Вісімковий режим файлу в stage 2.

<m3>

Вісімковий режим файлу в stage 3.

<mW>

Вісімковий режим файлу в робочому дереві.

<h1>

Імʼя обʼєкта в stage 1.

<h2>

Імʼя обʼєкта в stage 2.

<h3>

Імʼя обʼєкта в stage 3.

<шлях>

Імʼя шляху.

Інші елементи

Після виведення відстежуваних записів (а також за запитом) буде виведено ряд рядків, що містять невідстежувані, а потім ігноровані елементи, знайдені в робочому дереві.

Невідстежувані елементи мають такий формат:

? <path>

Ігноровані елементи мають такий формат:

! <path>

Примітки щодо формату імені шляху та -z

Коли вказано опцію -z, шляхи виводяться як є та без лапок, а рядки завершуються байтом NUL (ASCII 0x00).

Без опції -z шляхи з "незвичайними" символами беруться в лапки, як пояснено для змінної конфігурації core.quotePath (див. git-config[1]).

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

Команда враховує змінні конфігурації color.status (або status.color — вони означають одне й те саме, і остання зберігається для зворотної сумісності) та color.status.<slot> для кольорового виводу.

Якщо для конфігураційної змінної status.relativePaths встановлено значення false, то всі вказані шляхи є відносними до кореня репозиторію, а не до поточної теки.

Якщо для параметра status.submoduleSummary встановлено значення, відмінне від нуля, або значення true (що еквівалентно -1 або необмеженій кількості), у довгому форматі буде ввімкнено підсумок щодо субмодулів, і буде показано підсумок комітів для змінених субмодулів (див. опцію --summary-limit команди git-submodule[1]). Зверніть увагу, що виведення підсумку з команди status буде приховано для всіх субмодулів, якщо diff.ignoreSubmodules встановлено на all, або лише для тих субмодулів, де submodule.<name>.ignore=all. Щоб також переглянути підсумок для ігнорованих субмодулів, ви можете використати або опцію командного рядка --ignore-submodules=dirty, або команду “git submodule summary”, яка показує подібний вивід, але не враховує ці налаштування.

ФОНОВЕ ОНОВЛЕННЯ

Стандартно git status автоматично оновлює індекс, оновлюючи кешовану інформацію про стан з робочого дерева та записуючи результат. Запис оновленого індексу є оптимізацією, яка не є строго необхідною (status обчислює ці значення самостійно, але записує їх лише для того, щоб позбавити наступні програми від необхідності повторювати ці обчислення). Коли status запускається у фоновому режимі, блокування, що утримується під час запису, може конфліктувати з іншими одночасними процесами, що призведе до їхнього збою. Скрипти, що запускають status у фоновому режимі, повинні розглянути можливість використання git --no-optional-locks status (детальніше див. git[1]).

ФАЙЛИ, ЩО НЕ ВІДСТЕЖУЮТЬСЯ ТА ПРОДУКТИВНІСТЬ

Команда git status може бути дуже повільною у великих робочих деревах, якщо/коли потрібно шукати файли та теки, що не відстежуються. Існує багато опцій конфігурації, які дозволяють пришвидшити цей процес, або уникаючи цієї роботи, або використовуючи кешовані результати попередніх команд Git. Не існує єдиного оптимального набору налаштувань, який підходить усім. Ми наведемо короткий опис відповідних опцій, щоб допомогти вам, але перш ніж переходити до списку, можливо, ви захочете запустити git status ще раз, оскільки ваша конфігурація вже може кешувати результати git status, тому наступні запуски можуть бути швидшими.

  • Прапорець --untracked-files=no або налаштування status.showUntrackedFiles=no (див. вище для обох): вказує, що команда git status не повинна повідомляти про файли, які не відстежуються. Це найшвидший варіант. git status не відображатиме файли, що не відстежуються, тому вам слід пам’ятати про створення нових файлів і вручну додавати їх за допомогою команди git add.

  • advice.statusUoption=false (див. git-config[1]): встановлення цієї змінної на false вимикає попередження, яке виводиться, коли перерахування невідстежуваних файлів займає більше 2 секунд. У великому проєкті це може зайняти більше часу, і користувач, можливо, вже погодився на компроміс (наприклад, використання -uno може бути неприйнятним варіантом для користувача), у такому разі немає сенсу виводити попередження, і в такому випадку найкращим рішенням може бути його відключення.

  • core.untrackedCache=true (див. git-update-index[1]): вмикає функцію кешування не відстежуваних файлів, щоб шукати лише ті теки, які були змінені з моменту виконання попередньої команди git status. Git запамʼятовує набір файлів, що не відстежуються, у кожній теці та припускає, що якщо тека не змінювалася, то набір файлів, що не відстежуються, у ній також не змінився. Це значно швидше, ніж перебирати вміст кожної теки, але все одно має свої витрати, оскільки Git все одно мусить шукати набір змінених тек. Кеш невідстежуваних файлів зберігається у файлі .git/index. Зменшення витрат на пошук невідстежуваних файлів дещо компенсується збільшенням розміру індексу та витратами на його оновлення. Зазвичай скорочення часу пошуку виправдовує збільшення розміру.

  • core.untrackedCache=true та core.fsmonitor=true або core.fsmonitor=<hook-command-pathname> (див. git-update-index[1]): вмикає як кеш для файлів, що не відстежуються, так і функцію FSMonitor, і здійснює пошук лише в тих теках, які були змінені з моменту виконання попередньої команди git status. Це швидше, ніж використання лише кешу для файлів, що не відстежуються, оскільки Git також може уникнути пошуку змінених тек. Git має просто перерахувати точний набір тек, які нещодавно зазнали змін. Хоча функцію FSMonitor можна ввімкнути без кешу для файлів, що не відстежуються, у цьому випадку її переваги значно зменшуються.

Зверніть увагу, що після увімкнення функцій для відстеження кешу та/або FSMonitor може знадобитися кілька команд git status, щоб різні кеші «розігрілися», перш ніж ви помітите скорочення часу виконання команд. Це нормально.

ДИВ. ТАКОЖ

gitignore[5]

GIT

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