українська мова ▾ Topics ▾ Latest version ▾ git-blame last updated in 2.51.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 також підтримує пошук в історії розробки, щоб дізнатися, коли фрагмент коду з’являвся під час зміни. Це дозволяє відстежувати, коли фрагмент коду був доданий до файлу, переміщений або скопійований між файлами, а також видалений або замінений. Це працює шляхом пошуку текстового рядка в різниці. Невеликий приклад інтерфейсу 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

Подає додаткову статистику наприкінці інформації про авторство.

-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 обчислює заголовки патчів (див. «Визначення власного заголовка hunk» у gitattributes[5]).

-l

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

-t

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

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

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

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

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

--first-parent

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

-p
--porcelain

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

--line-porcelain

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

--incremental

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

--encoding=<кодування>

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

--contents <файл>

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

--date <формат>

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

--[no-]progress

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

-M[<число>]

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

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

-C[<число>]

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

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

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

Ігнорувати зміни, внесені ревізією, під час призначення звинувачення, ніби змін ніколи не було. Рядки, які були змінені або додані ігнорованим комітом, будуть звинувачені в попередньому коміті, який змінив цей рядок або сусідні рядки. Цей параметр можна вказати кілька разів, щоб ігнорувати більше однієї ревізії. Якщо встановлено параметр конфігурації blame.markIgnoredLines, то рядки, які були змінені ігнорованим комітом і віднесені до іншого коміту, будуть позначені символом ? у виводі звинувачення. Якщо встановлено параметр конфігурації 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

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

--abbrev=<n>

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

ФОРМАТ ЗА ЗАМОВЧАННЯМ

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

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

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

  • line number

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

ФОРМАТ ПОРЦЕЛЯНИ

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

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

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

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

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

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

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

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

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

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

Формат porcelain зазвичай приховує інформацію про коміти, які вже були переглянуті. Наприклад, два рядки, що пов’язані з одним і тим самим комітом, будуть показані, але деталі цього коміту будуть показані лише один раз. Інформація, що стосується окремих рядків, не буде згрупована разом, як-от редагування, які будуть позначені як «ігноровані» або «незвинувачувані». Це ефективніше, але може вимагати від читача збереження більшої кількості даних про стан. Опцію --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. Кожен запис про звинувачення завжди починається з рядка:

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

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

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

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

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

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

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

АВТОРИ КАРТОГРАФІЇ

Див. gitmailmap[5].

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

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

Warning

Missing uk/config/blame.adoc

See original version for this content.

ДИВ. ТАКОЖ

git-annotate[1]

GIT

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