Что делает git виноват?

Ответ 1

Из git -scm http://git-scm.com/docs/git-blame

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

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

Пример:

[email protected]:~# git blame .htaccess
...
^e1fb2d7 (John Doe 2015-07-03 06:30:25 -0300  4) allow from all
^72fgsdl (Arthur King 2015-07-03 06:34:12 -0300  5)
^e1fb2d7 (John Doe 2015-07-03 06:30:25 -0300  6) <IfModule mod_rewrite.c>
^72fgsdl (Arthur King 2015-07-03 06:34:12 -0300  7)     RewriteEngine On
...

Обратите внимание, что git blame не показывает историю изменений в хронологическом смысле. Он показывает только, кто был последним человеком, который изменил строку в документе до последнего фиксации в HEAD.

То есть, чтобы просмотреть полную историю/журнал строки документа, вам нужно запустить git blame path/to/file для каждой фиксации в git log.

Ответ 2

Команда объясняет себя довольно хорошо, чтобы выяснить, кто из сотрудников написал конкретную строку или разрушил проект, чтобы вы могли винить их:)

Ответ 3

Из GitHub https://help.github.com/articles/using-git-blame-to-trace-changes-in-a-file

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

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

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

Ответ 4

Команда git blame используется, чтобы узнать, кто/какой коммит отвечает за последние изменения, внесенные в файл. Автор/коммит каждой строки также можно увидеть.

git blame filename (принимает ответственность за изменения для всех строк в коде)

git blame filename -L 0,10 (фиксирует ответственность за изменения со строки "0" на строку "10")

Есть много других вариантов обвинения, как правило, они могут помочь.

Ответ 5

Команда git blame комментирует строку с информацией из ревизии, которая последний раз модифицировала строку, и... с Git 2.22 (Q2 2019) будет делать это быстрее из-за исправления производительности вокруг " git blame ", особенно в линейной истории (что является нормой, для которой мы должны оптимизировать).

См. Коммит f892014 (02 апреля 2019 г.) Дэвида Каструпа (fedelibre).
^{(Объединено Junio C Hamano - gitster - в коммите 4d8c4da, 25 апреля 2019 г.)}

blame.c: не роняйте blame.c блобы

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

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