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

НАЗВА

git-blame — Показати, в якій ревізії та ким було востаннє змінено кожен рядок файлу

СИНОПСИС

git blame [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--incremental]
	    [-L <range>] [-S <revs-file>] [-M] [-C] [-C] [-C] [--since=<date>]
	    [--ignore-rev <rev>] [--ignore-revs-file <file>]
	    [--color-lines] [--color-by-age] [--progress] [--abbrev=<n>]
	    [ --contents <file> ] [<rev> | --reverse <rev>..<rev>] [--] <file>

ОПИС

Анотує кожен рядок у заданому файлі інформацією з версії, яка востаннє змінювала рядок. За потреби, можна почати анотування з заданої версії.

Якщо вказати параметр -L один або кілька разів, він обмежує анотацію запитуваними рядками.

При перейменуванні всього файлу походження рядків відстежується автоматично (наразі немає можливості вимкнути цю функцію). Щоб відстежувати рядки, переміщені з одного файлу в інший, або рядки, скопійовані та вставлені з іншого файлу тощо, див. параметри -C та -M.

У звіті нічого не повідомляється про рядки, які були видалені або замінені; вам потрібно скористатися інструментом, таким як git diff або інтерфейсом «pickaxe», про який трохи далі.

Окрім підтримки анотацій файлів, Git також підтримує пошук в історії розробки, щоб дізнатися, коли фрагмент коду зʼявлявся під час зміни. Це дозволяє відстежувати, коли фрагмент коду був доданий до файлу, переміщений або скопійований між файлами, а також видалений або замінений. Це працює шляхом пошуку текстового рядка в diff. Невеликий приклад інтерфейсу pickaxe, який шукає blame_usage:

$ git log --pretty=oneline -S'blame_usage'
5040f17eba15504bad66b14a645bddd9b015ebb7 blame -S <ancestry-file>
ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Зробіть вихід

ОПЦІЇ

-b

Показувати порожній SHA-1 для комітів, що є граничними. Цю поведінку також можна налаштувати за допомогою параметра конфігурації blame.blankBoundary.

--root

Не слід розглядати кореневі коміти як межі. Цю поведінку також можна налаштувати за допомогою параметра конфігурації blame.showRoot.

--show-stats

Додати додаткові статистичні дані в кінці виводу команди blame.

-L <початок>,<кінець>
-L :<імʼя-функції>

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

<початок> та <кінець> необовʼязкові. -L <початок> або -L <початок>, охоплює рядки від <початку> до кінця файлу. -L ,<кінець> — від початку файлу до <кінця>.

<start> і <end> може мати одну з цих форм:

  • <number>

    Якщо <start> або <end> є числом, воно визначає абсолютний номер рядка (рядки рахуються від 1).

  • /<regex>/

    Ця форма використовуватиме перший рядок, що відповідає заданому POSIX-виразу <regex>. Якщо <start> є регулярним виразом, пошук розпочнеться з кінця попереднього діапазону -L, якщо такий є, інакше — з початку файлу. Якщо <start> є ^/<regex>/, пошук розпочнеться з початку файлу. Якщо <end> є регулярним виразом, пошук розпочнеться з рядка, вказаного в <start>.

  • +<offset> або -<offset>

    Є дійсним лише для <end> та визначатиме кількість рядків до або після рядка, заданого <start>.

Якщо :<funcname> вказано замість <start> та <end>, це регулярний вираз, який позначає діапазон від першого рядка funcname, що відповідає <funcname>, до наступного рядка funcname. :<funcname> шукає з кінця попереднього діапазону -L, якщо такий є, інакше з початку файлу. ^:<funcname> шукає з початку файлу. Назви функцій визначаються так само як git diff обчислює заголовки латок (див. «Визначення власного заголовка фрагмента» у gitattributes[5]).

-l

Показує повне значення ревізії (Типово: вимкнено).

-t

Показує необроблений відбиток часу (Типово: вимкнено).

-S <файл-ревізій>

Використовує ревізії із вказаного файлу ревізій замість виклику git-rev-list[1].

--reverse <ревізія>..<ревізія>

Рухає історію вперед, а не назад. Замість показу ревізії, у якій рядок зʼявився, показує останню ревізію у якій він існував. Для цього потрібно вказати проміжок ревізій, наприклад, ПОЧАТОК..КІНЕЦЬ, де рядок, який ви шукаєте, повинен існувати у ПОЧАТКУ. git blame --reverse ПОЧАТОК є скороченням для git blame --reverse ПОЧАТОК..HEAD.

--first-parent

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

-p
--porcelain

Показує у форматі, призначеному для машинного використання.

--line-porcelain

Показувати формат porcelain, але виводити інформацію про коміт для кожного рядка, а не лише при першому згадуванні коміту. Передбачає використання параметра --porcelain.

--incremental

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

--encoding=<encoding>

Визначає кодування для виводу імені автора та заголовку коміту. Встановлення значення none призводить до виводу неконвертованих даних. Детальніше дивіться обговорення кодування на сторінці посібника git-log[1].

--contents <файл>

Анотує використовуючи вміст вказаного файлу, починаючи з <ревізії>, якщо її визначено, або ж з HEAD. Ви можете вказати - аби команда зчитувала контент файлу зі стандартного вводу.

--date <формат>

Визначає формат виводу дати. Якщо цей параметр відсутній, буде використано значення параметру конфігурації blame.date. Якщо ж і його немає, то буде використано формат ISO. Задля ознайомлення із підтримуваними значенням дивіться обговорення параметру --date у git-log[1].

--progress
--no-progress

Типово, статус виконання виводиться у стандартному потоці помилок, коли він підключений до терміналу. Цей прапорець дозволяє виводити прогрес навіть коли такий потік не підключено. --progress не може використовуватися разом з --porcelain чи --incremental.

-M[<число>]

Виявляє переміщені чи скопійовані рядки всередині файлу. Коли коміт переміщує чи копіює сукупність рядків (наприклад, коли вихідний файл містить рядок А і потім Б, а коміт переставляє спочатку Б, а тоді А), традиційний алгоритм розпізнає лише половину руху і, зазвичай, приписує рядки, що були переміщені вгору (тобто Б), батьківському коміту, а рядки, що були переміщені вниз (тобто А), — дочірньому. Із цим параметром, обидві групи рядків приписуються батьківському шляхом виконання додаткових перевірок.

<Число> необовʼязкове. Це нижня межа кількості літерно-цифрових символів, які Git має визначити як переміщені/скопійовані всередині файлу, щоб повʼязати ці рядки із батьківським комітом. Типово дорівнює 20.

-C[<число>]

На додачу до -M визначає переміщені або скопійовані рядки з інших файлів, що були змінені у тому самому коміті. Це корисно коли ви реорганізовуєте вашу програму та переміщуєте код між файлами. Коли цей параметр вказано двічі, команда додатково шукає копії з інших файлів у коміті, в якому файл було створено. Якщо ж його вказано тричі, то команда додатково шукає копії з інших файлів у будь-якому коміті.

<Число> необовʼязкове. Це нижня межа кількості літерно-цифрових символів, які Git має визначити як переміщені/скопійовані між файлами, аби повʼязати ці рядки із батьківським комітом. Типово дорівнює 40. Якщо вказано більше одного параметру -C, то буде використано <число> останнього з них.

--ignore-rev <ревізія>

При визначенні відповідальності ігнорувати зміни, внесені цією версією, так ніби ці зміни ніколи не відбувалися. Рядки, які були змінені або додані ігнорованим комітом, будуть приписані попередньому коміту, який змінив цей рядок або сусідні рядки. Цю опцію можна вказати кілька разів, щоб ігнорувати більше ніж одну ревізію. Якщо встановлено опцію конфігурації blame.markIgnoredLines, то рядки, які були змінені ігнорованим комітом і приписані іншому коміту, будуть позначені символом ? у результатах blame. Якщо встановлено опцію конфігурації blame.markUnblamableLines, то ті рядки, яких торкнувся ігнорований комміт, які ми не змогли приписати іншій ревізії, позначаються символом *. У режимах porcelain ми виводимо ignored та unblamable відповідно на новому рядку.

--ignore-revs-file <файл>

Нехтує ревізіями, що перелічені у <файлі>, який має бути в тому ж форматі що й fsck.skipList. Цей параметр може бути вказано декілька разів. Ці файли будуть опрацьовані після усіх файлів, що визначені параметром конфігурації blame.ignoreRevsFile. Порожнє імʼя файлу ("") очищає перелік ревізій з попередніх опрацьованих файлів.

--color-lines

Позначати кольором рядки у стандартному форматі по-різному, якщо вони походять із того самого коміту, що й попередній рядок. Це полегшує розрізнення блоків коду, доданих у різних комітах. Зазвичай використовується блакитний колір, який можна змінити за допомогою параметра конфігурації color.blame.repeatedLines.

--color-by-age

Кольорові позначки рядків залежно від їхнього віку у типовому форматі. Параметр конфігурації color.blame.highlightRecent визначає, який колір використовуватиметься для кожного вікового діапазону.

-h

Показати повідомлення довідки.

-c

Використовувати той самий режим виводу, що й для git-annotate[1] (Стандартно: вимкнено).

--score-debug

Включити інформацію для налагодження, повʼязану з переміщенням рядків між файлами (див. -C) та рядків, переміщених у файлі (див. -M). Перше число у списку — це оцінка. Це кількість літерно-цифрових символів, які, як було виявлено, були переміщені між файлами або всередині них. Ця кількість має перевищувати певний поріг, щоб команда git blame визнала ці рядки коду переміщеними.

-f
--show-name

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

-n
--show-number

Показувати номер рядка в оригінальному коміті (зазвичай вимкнено).

-s

Приховати імʼя автора та позначку часу у виводі.

-e
--show-email

Показувати електронну адресу автора замість імені автора (зазвичай: вимкнено). Цим також можна керувати за допомогою параметра конфігурації blame.showEmail.

-w

Ігнорувати пробіли під час порівняння батьківської версії та дочірньої, щоб знайти, звідки взялися рядки.

--diff-algorithm=(patience|minimal|histogram|myers)

Вибір алгоритму порівняння. Є наступні варіанти:

default
myers

Базовий алгоритм «жадібного» порівняння. Наразі це типове значення.

minimal

Витрачає додатковий час, щоб переконатися, що отримано найменший можливий diff.

patience

При створенні латок використовується алгоритм «patience diff».

histogram

Цей алгоритм розширює алгоритм «patience» для «підтримки рідкісних загальних елементів».

Наприклад, якщо ви налаштували змінну diff.algorithm на значення, відмінне від стандартного, і хочете скористатись стандартним значенням, тоді вам потрібно використовувати опцію --diff-algorithm=default.

--abbrev=<n>

Замість використання стандартних шістнадцяткових цифр 7+1 як скороченої назви обʼєкта, використовуйте <m>+1 цифра, де <m> дорівнює щонайменше <n>, але гарантує унікальність назв обʼєктів коміту. Зверніть увагу, що 1 стовпець використовується для каретки, яка позначає межу коміту.

СТАНДАРТНИЙ ФОРМАТ

Якщо не вказано ні опції --porcelain, ні --incremental, git blame виведе анотацію для кожного рядка з таким виглядом:

  • скорочена назва обʼєкта для коміту, з якого походить рядок;

  • ідентифікатор автора (стандартно імʼя автора та дата, якщо не вказано -s або -e); та

  • номер рядка

перед вмістом рядка.

ФОРМАТ PORCELAIN

У цьому форматі кожен рядок виводиться після заголовка; заголовок щонайменше має перший рядок, який містить:

  • 40-байтовий SHA-1 коміта, до якого належить рядок;

  • номер рядка у вихідному файлі;

  • номер рядка в кінцевому файлі;

  • у рядку, що починає групу рядків з іншого коміту, ніж попередній, кількість рядків у цій групі. У наступних рядках це поле відсутнє.

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

  • імʼя автора ("author"), електронна адреса ("author-mail"), час ("author-time") та часовий пояс ("author-tz"); аналогічно для комітера.

  • імʼя файлу в коміті, до якого відноситься рядок.

  • перший рядок повідомлення журналу комітів ("summary").

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

Формат porcelain зазвичай приховує інформацію про коміти, які вже були переглянуті. Наприклад, два рядки, що повʼязані з одним і тим самим комітом, будуть показані, але деталі цього коміту будуть показані лише один раз. Інформація, що стосується окремих рядків, не буде згрупована разом, як-от редагування, які будуть позначені як ignored або unblamable. Це ефективніше, але може вимагати від читача збереження більшої кількості даних про стан. Опцію --line-porcelain можна використовувати для виведення повної інформації про коміт для кожного рядка, що дозволяє простіше (але менш ефективне) використання, наприклад:

# підрахувати кількість рядків, що належать кожному автору
git blame --line-porcelain file |
sed -n 's/^author //p' |
sort | uniq -c | sort -rn

ВИЗНАЧЕННЯ ДІАПАЗОНІВ

На відміну від git blame та git annotate у старіших версіях git, обсяг анотації може бути обмежений як діапазонами рядків, так і діапазонами версій. Опцію -L, яка обмежує анотацію діапазоном рядків, можна вказувати кілька разів.

Якщо вам потрібно знайти початок рядків 40-60 для файлу foo, ви можете скористатися опцією -L ось так (вони означають одне й те саме — обидва запитують 21 рядок, починаючи з рядка 40):

git blame -L 40,60 foo
git blame -L 40,+21 foo

Також ви можете використовувати регулярний вираз для визначення діапазону рядків:

git blame -L '/^sub hello {/,/^}$/' foo

що обмежує анотацію тілом підпрограми hello.

Якщо вас не цікавлять зміни, старіші за версію v2.6.18, або зміни, старіші за 3 тижні, ви можете використовувати специфікатори діапазону версій, подібні до git rev-list:

git blame v2.6.18.. -- foo
git blame --since=3.weeks -- foo

Коли для обмеження анотації використовуються специфікатори діапазону редакцій, рядки, які не змінилися з моменту встановлення межі діапазону (або коміт версії 2.6.18, або найновіший коміт, якому більше 3 тижнів у наведеному вище прикладі), вважаються причиною встановлення межі діапазону.

Особливо корисним є перевірка того, чи містить доданий файл рядки, скопійовані з наявних файлів. Іноді це свідчить про те, що розробник працював недбало і не виконав належного рефакторингу коду. Спочатку можна знайти коміт, у якому було додано цей файл, за допомогою команди:

git log --diff-filter=A --pretty=short -- foo

а потім анотуйте зміну між комітом та його батьківськими обʼєктами, використовуючи нотацію commit^!:

git blame -C -C -f $commit^! -- foo

ІНКРЕМЕНТАЛЬНИЙ ВИВІД

Якщо команду запустити з опцією --incremental, вона виводитиме результат у міру його формування. Зазвичай у видачі спочатку йдуть рядки, до яких торкнулися останні коміти (тобто рядки будуть позначені не в хронологічному порядку), і це призначено для використання в інтерактивних переглядачах.

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

  1. Кожен запис blame завжди починається з рядка:

    <40-byte-hex-sha1> <sourceline> <resultline> <num-lines>

    Номери рядків рахуються від 1.

  2. Коли коміт вперше зʼявляється в потоці, на початку кожного рядка виводиться різна інша інформація про нього з тегом з одного слова, що описує додаткову інформацію про коміт (автор, електронна адреса, коміттер, дати, короткий опис тощо).

  3. На відміну від формату Porcelain, інформація про імʼя файлу завжди надається та завершує запис:

    "filename" <whitespace-quoted-filename-goes-here>

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

    Note
    		 Для тих, хто займається синтаксичним аналізом: щоб зробити його більш надійним, просто ігноруйте всі рядки між першим і останнім (рядками «<sha1>» та «filename»), у яких ви не розпізнаєте слова-теги (або які вас не цікавлять) на початку рядків «розширеної інформації». Таким чином, якщо коли-небудь буде додано інформацію (наприклад, кодування коміту або розширений коментар до коміту), програма для перегляду blame не буде на це зважати.

СПИСОК АВТОРІВ

Див. gitmailmap[5].

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

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

Warning

Missing uk/config/blame.adoc

See original version for this content.

ДИВ. ТАКОЖ

git-annotate[1]

GIT

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