git-blame - Интернет в облаке

ПРОГРАММА:

ИМЯ

git-blame - показывает, какая ревизия и автор в последний раз изменяли каждую строку файла

СИНТАКСИС

мерзавец обвинять [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--инкрементно]
[-L ] [-S ] [-M] [-C] [-C] [-C] [--since = ]
[--abbrev = ] [ | --содержание | --задний ход ] [-]

ОПИСАНИЕ

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

Если указано один или несколько раз, -L ограничивает аннотацию запрошенными строками.

Источник строк автоматически отслеживается при переименовании всего файла (в настоящее время
нет возможности отключить отслеживание переименования). Следить за строками, перемещенными из одного файла в
другой, или чтобы следовать строкам, которые были скопированы и вставлены из другого файла и т. д., см.
Опции -C и -M.

В отчете ничего не говорится о строках, которые были удалены или заменены; ты
нужно использовать такой инструмент, как мерзавец Разница или интерфейс "кирки", кратко упомянутый в
следующий абзац.

Помимо поддержки аннотации файлов, Git также поддерживает поиск в истории разработки.
когда фрагмент кода произошел в изменении. Это позволяет отслеживать, когда код
фрагмент был добавлен в файл, перемещен или скопирован между файлами и в конечном итоге удален или
заменены. Он работает путем поиска текстовой строки в diff. Небольшой пример
Pickaxe интерфейс, который ищет blame_usage:

$ git log --pretty = oneline -S'blame_usage '
5040f17eba15504bad66b14a645bddd9b015ebb7 blame -S <ancestry-file>
ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output

ДОПОЛНИТЕЛЬНЫЕ УСЛУГИ, НЕ ВКЛЮЧЕННЫЕ В ПАКЕТ

-b
Показывать пустой SHA-1 для фиксации границ. Этим также можно управлять с помощью
Параметр конфигурации blame.blankboundary.

--корень
Не относитесь к корневым коммитам как к границам. Этим также можно управлять с помощью
Опция конфигурации blame.showRoot.

--show-stats
Включите дополнительную статистику в конце вывода обвинений.

-L , , -L:
Аннотировать только указанный диапазон строк. Можно указывать несколько раз. Перекрытие
допустимые диапазоны.

а также являются необязательными. «-L »Или« -L , ”Простирается от к
конец файла. «-L, »Простирается от начала файла до .

а также может принимать одну из следующих форм:

· количество

Если или это число, оно указывает абсолютный номер строки (количество строк
с 1 г.)

· / Регулярное выражение /

Эта форма будет использовать первую строку, соответствующую заданному регулярному выражению POSIX. Если это
regex, он будет искать с конца предыдущего диапазона -L, если таковой имеется, в противном случае
с начала файла. Если это «^ / regex /», поиск будет выполняться с начала
файл. Если является регулярным выражением, он будет искать, начиная со строки, заданной .

· + Смещение или -смещение

Это действительно только для и укажет количество строк до или после
строка, данная .

Если ": »Дается вместо а также , это регулярное выражение
который обозначает диапазон от первой строки имени функции, которая соответствует , вверх к
следующая строка имени функции. «: »Выполняет поиск с конца предыдущего диапазона -L, если
любой, иначе с начала файла. «^: »Поиск с начала файла.

-l
Показывать длинный оборот (по умолчанию: выключено).

-t
Показывать необработанную временную метку (по умолчанию: выключено).

-S
Используйте ревизии из revs-файла вместо вызова git-rev-список(1).

--задний ход
Идите по истории вперед, а не назад. Вместо того, чтобы показывать ревизию, в которой
Появилась строка, показывающая последнюю ревизию, в которой существовала строка. Это требует
диапазон ревизий, таких как START..END, где путь к виноватым существует в START.

-p, - фарфор
Шоу в формате, предназначенном для машинного потребления.

--линий-фарфор
Показать фарфоровый формат, но вывести информацию о фиксации для каждой строки, а не только для
Ссылка на фиксацию впервые. Подразумевается - фарфор.

- инкрементальный
Покажите результат постепенно в формате, предназначенном для машинного потребления.

--encoding =
Задает кодировку, используемую для вывода имен авторов и резюме фиксации. Установив его на
none делает вывод виновных в неконвертированных данных. Для получения дополнительной информации см. Обсуждение
о кодировании в git-журнал(1) страница руководства.

--содержание
Когда не указан, команда аннотирует изменения, начиная с
копия рабочего дерева. Этот флаг заставляет команду делать вид, будто копия рабочего дерева
содержит содержимое указанного файла (укажите - чтобы команда считывалась из
стандартный ввод).

--Дата
Задает формат, используемый для вывода дат. Если --date не указан, значение
Используется конфигурационная переменная blame.date. Если конфигурационная переменная blame.date также не установлена,
используется формат iso. Для поддерживаемых значений см. Обсуждение параметра --date.
at git-журнал(1).

-M | |
Обнаружение перемещенных или скопированных строк в файле. Когда коммит перемещает или копирует блок
строки (например, в исходном файле есть A, а затем B, а фиксация изменяет его на B и
затем A), традиционный обвинять алгоритм замечает только половину движения и
обычно обвиняет родителя в перемещенных строках (например, B) и назначает вину
к строкам, которые были перемещены вниз (то есть A) для дочернего коммита. С этой опцией оба
группы строк перекладываются на родительский элемент путем выполнения дополнительных проходов проверки.

необязательно, но это нижняя граница количества буквенно-цифровых символов
что Git должен определить перемещение / копирование в файле, чтобы связать эти строки
с родительским коммитом. Значение по умолчанию - 20.

-C | |
В дополнение к -M обнаруживать строки, перемещенные или скопированные из других файлов, которые были изменены в
тот же коммит. Это полезно, когда вы реорганизуете свою программу и перемещаете код.
через файлы. Когда эта опция указана дважды, команда дополнительно ищет
копирует из других файлов в коммите, который создает файл. Когда предоставляется этот вариант
трижды команда дополнительно ищет копии из других файлов в любом коммите.

необязательно, но это нижняя граница количества буквенно-цифровых символов
что Git должен определять перемещение / копирование между файлами, чтобы связать эти строки
с родительским коммитом. И значение по умолчанию - 40. Если их больше одного -C
предоставленные варианты, аргумент последнего -C вступит в силу.

-h
Показать справочное сообщение.

-c
Используйте тот же режим вывода, что и git-аннотировать(1) (По умолчанию: выключено).

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

-f, --показать-имя
Показать имя файла в исходной фиксации. По умолчанию имя файла отображается, если есть
любая строка, полученная из файла с другим именем, из-за обнаружения переименования.

-n, --показать-номер
Показывать номер строки в исходной фиксации (по умолчанию: выключено).

-s
Убрать имя автора и отметку времени из вывода.

-e, --show-e-mail
Показывать адрес электронной почты автора вместо имени автора (по умолчанию: выключено). Это также может быть
контролируется с помощью параметра конфигурации blame.showEmail.

-w
Игнорируйте пробелы при сравнении родительской и дочерней версий, чтобы найти, где
строки пришли из.

--abbrev =
Вместо использования шестнадцатеричных цифр по умолчанию 7 + 1 в качестве сокращенного имени объекта,
использовать +1 цифра. Обратите внимание, что для отметки фиксации границы используется 1 столбец.

ФАРФОР ФОРМАТ

В этом формате каждая строка выводится после заголовка; заголовок как минимум имеет
первая строка, в которой есть:

· 40-байтовый SHA-1 коммита, которому приписана строка;

· Номер строки в исходном файле;

· Номер строки в конечном файле;

· В строке, которая начинает группу строк из другой фиксации, чем предыдущая,
количество строк в этой группе. В последующих строках это поле отсутствует.

За этой строкой заголовка, по крайней мере, один раз для каждой фиксации следует следующая информация:

· Имя автора («автор»), адрес электронной почты («электронная почта автора»), время («время автора») и часовой пояс
(«автор-т.з.»); аналогично для коммиттера.

· Имя файла в фиксации, которому приписана строка.

· Первая строка сообщения журнала фиксации («сводка»).

Содержимое фактической строки выводится после указанного выше заголовка с префиксом TAB. Этот
позволяет позже добавить больше элементов заголовка.

Формат фарфора обычно подавляет информацию о фиксации, которая уже была просмотрена.
Например, будут показаны две строки, относящиеся к одной и той же фиксации, но
детали для этого коммита будут показаны только один раз. Это более эффективно, но может потребоваться
больше состояния будет сохранено читателем. Параметр --line-porcelain можно использовать для вывода полного
фиксировать информацию для каждой строки, что позволяет более простое (но менее эффективное) использование, например:

# подсчитываем количество строк, приписываемых каждому автору
git blame - линейно-фарфоровый файл |
sed -n 's / ^ author // p' |
сортировать | uniq -c | sort -rn

УКАЗАНИЕ ДИАПАЗОНЫ

В отличие от мерзавец обвинять и мерзавец аннотированный в более старых версиях git степень аннотации
может быть ограничен как линейными диапазонами, так и диапазонами ревизий. Параметр -L, ограничивающий
аннотация к диапазону строк может быть указана несколько раз.

Если вы хотите найти начало координат строк 40-60 для файла foo, вы можете использовать
вариант -L (они означают одно и то же - оба запрашивают 21 строку, начинающуюся с строки
40):

git виноват -L 40,60 foo
git blame -L 40, + 21 foo

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

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

что ограничивает аннотацию телом подпрограммы hello.

Если вас не интересуют изменения старше версии v2.6.18 или изменения старше 3
недель, вы можете использовать спецификаторы диапазона ревизий, аналогичные мерзавец список изменений:

git виноват v2.6.18 .. - foo
git blame --since = 3.weeks - foo

Когда спецификаторы диапазона ревизий используются для ограничения аннотации, строки, которые не
изменилось с момента границы диапазона (либо фиксация v2.6.18, либо самая последняя фиксация, которая
старше 3 недель в приведенном выше примере) виноваты в фиксации границы диапазона.

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

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

а затем аннотируйте изменение между коммитом и его родителями, используя commit ^! обозначение:

git blame -C -C -f $ commit ^! - фу

ДОПОЛНИТЕЛЬНЫЙ ВЫВОД

При вызове с параметром --incremental команда выводит результат в том виде, в каком он был построен. В
вывод обычно будет говорить о строках, затронутых более поздними коммитами (т. е.
строки будут аннотироваться не по порядку) и предназначен для использования интерактивными программами просмотра.

Формат вывода аналогичен формату Porcelain, но не содержит фактических
строки из аннотируемого файла.

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

<40-байтовое шестнадцатеричное sha1>

Номера строк отсчитываются от 1.

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

3. В отличие от формата Porcelain, информация об имени файла всегда указывается и заканчивается.
Вход:

"имя файла"

и, таким образом, действительно довольно легко выполнить синтаксический анализ для парсера, ориентированного на строки и слова
(что должно быть вполне естественно для большинства языков сценариев).

Внимание
Для людей, которые занимаются синтаксическим анализом: чтобы сделать его более надежным, просто игнорируйте любые строки между
первый и последний (" строки "и" имя файла "), в которых вы не узнаете
слова тега (или заботиться об этом конкретном) в начале
строки «расширенной информации». Таким образом, если будет добавлена ​​информация (например,
кодировку фиксации или расширенный комментарий фиксации), зрителю обвинения все равно.

ОТОБРАЖЕНИЕ АВТОРЫ

Если файл .mailmap существует на верхнем уровне репозитория или в указанном месте
к параметрам конфигурации mailmap.file или mailmap.blob, он используется для сопоставления автора и
связывать имена и адреса электронной почты с каноническими реальными именами и адресами электронной почты.

В простой форме каждая строка в файле состоит из канонического реального имени
автор, пробел и адрес электронной почты, использованные в фиксации (заключены в < и >) для отображения
к имени. Например:

Правильное имя[электронная почта защищена]>

Более сложные формы:

<[электронная почта защищена]>[электронная почта защищена]>

который позволяет mailmap заменять только электронную часть коммита и:

Правильное имя[электронная почта защищена]>[электронная почта защищена]>

который позволяет mailmap заменять как имя, так и адрес электронной почты коммита, совпадающего с
указанный адрес электронной почты фиксации и:

Правильное имя[электронная почта защищена]> Имя фиксации[электронная почта защищена]>

который позволяет mailmap заменять как имя, так и адрес электронной почты фиксации, совпадающей как с
указанное имя фиксации и адрес электронной почты.

Пример 1. Ваша история содержит коммиты двух авторов, Джейн и Джо, чьи имена указаны
в репозитории в нескольких формах:

Джо Разработчик[электронная почта защищена]>
Джо Р. Разработчик[электронная почта защищена]>
Джейн Доу[электронная почта защищена]>
Джейн Доу
Джейн Д.

Теперь предположим, что Джо хочет использовать инициалы своего второго имени, а Джейн предпочитает свою фамилию.
полностью прописано. Правильный файл .mailmap будет выглядеть так:

Джейн Доу
Джо Р. Разработчик[электронная почта защищена]>

Обратите внимание, что нет необходимости вводить , потому что настоящее имя
этот автор уже прав.

Пример 2: Ваш репозиторий содержит коммиты следующих авторов:

nick1[электронная почта защищена]>
nick2[электронная почта защищена]>
nick2[электронная почта защищена]>
Санта[электронная почта защищена]>
Клаус[электронная почта защищена]>
Технический директор[электронная почта защищена]>

Тогда вам может понадобиться файл .mailmap, который выглядит так:

<[электронная почта защищена]>[электронная почта защищена]>
Какой-то чувак[электронная почта защищена]> ник1[электронная почта защищена]>
Другой Автор[электронная почта защищена]> ник2[электронная почта защищена]>
Другой Автор[электронная почта защищена]>[электронная почта защищена]>
Дед Мороз[электронная почта защищена]>[электронная почта защищена]>

Использовать хеш # для комментариев, которые находятся либо в отдельной строке, либо после адреса электронной почты.

Используйте git-blame онлайн с помощью сервисов onworks.net