Как узнать кто автор строчки в файле используя систему git
Изучение истории коммитов — важная составляющая работы с репозиторием. Увы, ввиду ветвления с этой историей не всегда просто разобраться. Обычно я для этой цели пользуюсь различными визуальными оболочками, но не всегда есть такая возможность. Временами приходится пользоваться средствами консоли, а именно командой git log. Основы работы с этой командой можно почитать в чудесной книге ProGit . git log имеет множество различных полезных параметров. Рассмотрим несколько примеров их использования.
Древовидный вид
Выводим полный граф коммитов, отводя по одной строке на коммит.
Линейный вид
Вывод списка коммитов с параметрами по умолчанию.
Выводим список коммитов и показываем diff для каждого.
Выводим список коммитов и показываем статистику по каждому.
Выводим список коммитов по одному на строчке.
Визуальный интерфейс
Если есть возможность, то всё таки коммиты приятнее изучать через специализированный интерфейс, а не из консоли. Лично я очень люблю GitExtensions:
Также удобно использовать встроенную утилиту gitk:
Полезные параметры
Все параметры команды git log не нужны, но некоторые самые полезные хорошо бы помнить. Приведу несколько примеров использования ходовых параметров.
- --graph Показывать древовидную структуру графа истории в ASCII-виде
- -5 Посмотреть последних пять коммитов
- --skip=3 Пропустить три коммита
- --pretty=oneline Отводить по одной строчке на коммит
- --since="today" Показать коммиты за сегодня
- --since=2.weeks Показать коммиты за последние две недели
- -p Показывать diff каждого коммита
- --decorate Показывать ссылки на этот коммит
- --stat Показывать подробную статистику по каждому коммиту
- --shortstat Показывать краткую статистику по каждому коммиту
- --name-only Показывать список изменённых файлов
- --name-status Показывать список изменённых файлов с информацией о них
- --abbrev-commit Показывать только несколько первых цифр SHA-1
- --relative-date Показывать дату в относительной форме
C помощью замечательного параметра --pretty=format:"" можно указать, какие именно данные о коммите нужно выводить, определив внутри кавычек общий паттерн, используя следующие обозначения:
Полный список обозначений можно найти в мануале , в разделе «PRETTY FORMATS».
Программирование — это не только написание нового кода, но и постоянный анализ уже написанного кода. Иногда код понятен и без слов (это хороший код), но так происходит не всегда. Код может вызывать вопросы. Почему он написан именно так, кто его написал и когда.
Ответить на эти вопросы помогает история изменений. Если коммиты сделаны хорошо, то есть они имеют понятное описание, и каждый из них делает ровно одну законченную вещь, то история становится мощным инструментом для анализа кода. Именно поэтому так важно хорошо понимать философию Git и следовать лучшим практикам при работе с ним.
Git предоставляет целую пачку команд со множеством опций, позволяющих вытащить невероятное количество информации и показать всё, что скрыто.
Git Log
Самая простая аналитика выполняется командой git log . Она показывает список всех выполненных коммитов, отсортированных по дате добавления (сверху самые последние):
Из этого вывода мы можем узнать кто, когда и какие коммиты делал. Если коммиты оформлены хорошо, то по их описанию уже многое понятно. Оформление коммитов — отдельная тема, которую мы рассмотрим позже.
У команды git log есть полезный флаг -p , который сразу выводит диф для каждого коммита:
Git Show
У каждого коммита есть идентификатор (говорят "хеш"), уникальный набор символов. С помощью хеша можно посмотреть все изменения, сделанные в рамках одного коммита:
Хеши коммитов в git очень длинные, и ими бывает неудобно пользоваться. Поэтому разработчики git добавили возможность указывать только часть хеша. Достаточно взять первые 8 символов и подставить их в ту команду, которая работает с коммитами:
Чаще всего вам не придётся высчитывать их самим, большая часть команд git выводит хеш коммита в сокращенном варианте, облегчая его использование. Такое упрощение хорошо работает, потому что даже первые 8 символов будут всегда уникальными.
Git Blame
А что если мы не знаем коммита, но нам интересно, кто последним менял конкретную строку в файле? Для этого подойдет команда git blame <путь до файла> . Эта команда выводит файл и рядом с каждой строкой показывает того, кто её менял и в каком коммите.
Важно помнить, что изменение строчки — не то же самое, что её написание. Вполне возможно, что программист исправил небольшую опечатку, а саму строку написал кто-то до него. В любом случае, имея такой вывод, уже легко пойти дальше и изучить конкретный коммит.
Git Grep
Команда git grep ищет совпадение с указанной строкой во всех файлах проекта. Это очень удобная команда для быстрого анализа из терминала. Она удобнее обычного grep , так как знает про игнорирование и не смотрит в директорию .git, а ещё умеет искать по истории:
Github
В простых ситуациях анализировать проект можно прямо на Гитхабе. Он позволяет просматривать историю коммитов, изменения в конкретном коммите и многое другое.
Самостоятельная работа
- Выполните все команды из урока в нашем репозитории
- Попробуйте изучить историю репозитория ru-local-communities
Дополнительные материалы
Вам ответят команда поддержки Хекслета или другие студенты.
Нашли опечатку или неточность?
Выделите текст, нажмите ctrl + enter и отправьте его нам. В течение нескольких дней мы исправим ошибку или улучшим формулировку.
Что-то не получается или материал кажется сложным?
- задайте вопрос. Вы быстрее справитесь с трудностями и прокачаете навык постановки правильных вопросов, что пригодится и в учёбе, и в работе программистом;
- расскажите о своих впечатлениях. Если курс слишком сложный, подробный отзыв поможет нам сделать его лучше;
- изучите вопросы других учеников и ответы на них. Это база знаний, которой можно и нужно пользоваться.
Об обучении на Хекслете
- Статья «Как учиться и справляться с негативными мыслями»
- Статья «Ловушки обучения»
- Статья «Сложные простые задачи по программированию»
- Урок «Как эффективно учиться на Хекслете»
- Вебинар «Как самостоятельно учиться»
Открыть доступ
Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно.
как я могу просмотреть историю изменений отдельного файла в Git, полную информацию о том, что изменилось?
который показывает мне историю фиксации файла, но как я могу получить содержимое каждого из изменений файла?
Я пытаюсь сделать переход от MS SourceSafe, и это раньше было просто right-click → show history .
для этого я использую:
или следовать за именем файла мимо переименований
чтобы git генерировал исправления для каждой записи журнала.
для большего количества опций-на самом деле он может сделать много хороших вещей :) чтобы получить только разницу для конкретного фиксации, вы можете
или любая другая редакция по идентификатору. Или использовать
для визуального просмотра изменений.
git log --follow -p -- file
это покажет весь история (включая историю переименований и изменения для каждого изменения).
другими словами, если файл с именем bar когда-то называли foo , потом git log -p bar (без --follow опция) покажет только историю файла до момента, когда он был переименован - он не будет показывать историю файла, когда он был известен как foo . Используя git log --follow -p bar показать всю историю файла, в том числе любые изменения в файле, когда он был известен как foo . The -p опция гарантирует, что различия включены для каждого изменения.
если вы предпочитаете оставаться текстовым, вы можете использовать Тиг.
используйте его для просмотра истории в одном файле: tig [filename]
Или просмотреть подробную историю РЕПО: tig
аналогично gitk но текст на основе. Поддерживает цвета в терминале!
вы также можете увидеть, когда определенная строка кода внутри файла была изменена с git blame filename . Это распечатает короткий идентификатор фиксации, автора, метку времени и полную строку кода для каждой строки в файле. Это очень полезно после того как вы нашли ошибку, и вы хотите знать, когда она была введена (или кто виноват).
пользователи SourceTree
Если вы используете SourceTree для визуализации вашего репозитория (это бесплатно и довольно хорошо), вы можете щелкнуть правой кнопкой мыши файл и выбрать Журнал Выбранный
дисплей (ниже) намного дружелюбнее, чем gitk и большинство других перечисленных опций. К сожалению (в это время) нет простого способа запустить это представление из командной строки - CLI SourceTree в настоящее время просто открывает репозитории.
чтобы показать, какая редакция и автор последней изменили каждую строку файла:
или если вы хотите использовать мощный GUI вины:
обычная команда командной строки будет
но вы также можете использовать gitk (gui) или tig (text-ui), чтобы дать гораздо более читаемые человеком способы взглянуть на него.
в debian / ubuntu команда установки для этих прекрасных инструментов, как и ожидалось:
и в настоящее время я использую:
так что я могу просто типа gdf dir чтобы получить сфокусированную историю всего в подкаталоге dir .
добавить этот псевдоним .gitconfig хранит настройки:
и используйте команду следующим образом:
выход будет выглядеть почти точно так же, как выход gitk. Наслаждаться.
я писал git-воспроизведение именно с этой целью
это имеет преимущество как отображения результатов в командной строке (например, git log -p ), а также позволяя вам проходить через каждую фиксацию с помощью клавиш со стрелками (например, gitk ).
Если вы используете gitx
недавно я обнаружил tig и нашел его очень полезным. Есть несколько случаев, когда я бы хотел, чтобы он делал A или B, но в большинстве случаев это довольно аккуратно.
для вашего случая, tig <filename> может быть то, что вы ищете.
Если вы хотите увидеть всю историю файла, в том числе on все остальные ветки использовать:
Если вы используете Git GUI (в Windows) в меню репозитория, вы можете использовать "визуализировать историю мастера". Выделите фиксацию в верхней панели и файл в правом нижнем углу, и вы увидите разницу для этой фиксации в левом нижнем углу.
отличное Расширения Git, вы переходите к точке в истории, где файл все еще существовал (если он был удален, в противном случае просто перейдите к голове), переключитесь на щелкните правой кнопкой мыши на файле и выберите File history .
по умолчанию он следует за файлом через переименования и Blame вкладка позволяет увидеть имя в данной редакции.
Он имеет некоторые незначительные проблемы, как показывает fatal: Not a valid object name на View вкладка при нажатии на исправление удаления, но я могу жить с этим. :-)
ответ, который я искал, не был в этом потоке, - это увидеть изменения в файлах, которые я поставил для фиксации. т. е.
вы также можете попробовать это, в котором перечислены коммиты, которые изменили определенную часть файла (реализован в git 1.8.4).
возвращаемый результат будет списком коммитов, которые изменили эту конкретную часть. Команда звучит так:
где upperLimit-это start_line_number, а lowerLimit-это ending_line_number файла.
Если вы используете TortoiseGit, вы должны иметь возможность щелкнуть правой кнопкой мыши по файлу и сделать TortoiseGit --> Show Log . В появившемся окне убедитесь:
Вне зависимости от размера кодовой базы, часто возникает необходимость поиска места вызова/определения функции или получения истории изменения метода. Git предоставляет несколько полезных утилит, с помощью которых легко и просто осуществлять поиск по коду и коммитам. Мы обсудим некоторые из них.
Команда git grep
Git поставляется с командой grep , которая позволяет легко искать в истории коммитов или в рабочем каталоге по строке или регулярному выражению. В следующих примерах, мы обратимся к исходному коду самого Git.
По умолчанию эта команда ищет по файлам в рабочем каталоге. В качестве первого варианта вы можете использовать любой из параметров -n или` --line-number`, чтобы распечатать номера строк, в которых Git нашел совпадения:
В дополнение к базовому поиску, показанному выше, git grep поддерживает множество других интересных параметров.
Например, вместо того, чтобы печатать все совпадения, вы можете попросить git grep обобщить выводимые командой данные, показав только те файлы, в которых обнаружены совпадения, вместе с количеством этих совпадений в каждом файле. Для этого потребуется параметр ` -c` или --count :
Если вас интересует контекст строки поиска, можно показать метод или функцию, в котором присутствует совпадение с помощью параметра -p или` --show-function`:
Здесь вы можете видеть, что gmtime_r вызывается из функций match_multi_number и match_digit в файле date.c (третье отображаемое совпадение представляет собой только строку, появившуюся в комментарии).
Вы также можете искать сложные комбинации строк, используя опцию --and , которая гарантирует, что будут отображены только строки, имеющие сразу несколько совпадений. Например, давайте поищем любые строки, которые определяют константу, имя которой содержит любую из подстрок «LINK» или «BUF_MAX», особенно в более старой версии кодовой базы Git, представленной тегом v1.8.0 (мы добавим параметры --break и --heading, которые помогут вывести результаты в более читаемом виде):
Команда git grep имеет несколько преимуществ перед поиском с помощью таких команд, как grep и ack . Во-первых, она действительно быстрая, во-вторых — git grep позволяет искать не только в рабочем каталоге, но и в любом другом дереве Git. Как вы видели, в прошлом примере мы искали в старой версии исходных кодов Git, а не в текущем снимке файлов.
Поиск в журнале Git
Например, если вы хотите найти, когда была добавлена константа ZLIB_BUF_MAX , то вы можете с помощью опции -S попросить Git показывать только те коммиты, в которых была добавлена или удалена эта строка.
Если мы посмотрим на изменения, сделанные в этих коммитах, то увидим, что в ef49a7a константа была добавлена, а в e01503b — изменена.
Если вам нужно найти что-то более сложное, вы можете с помощью опции -G передать регулярное выражение.
Поиск по журналу изменений строки
Другой, довольно продвинутый, поиск по истории, который бывает чрезвычайно полезным — поиск по истории изменений строки. Просто запустите git log с параметром -L , и он покажет вам историю изменения функции или строки кода в вашей кодовой базе.
Например, если мы хотим увидеть все изменения, произошедшие с функцией git_deflate_bound в файле zlib.c , мы можем выполнить git log -L :git_deflate_bound:zlib.c . Эта команда постарается определить границы функции, выполнит поиск по истории и покажет все изменения, которые были сделаны с функцией, в виде набора патчей в обратном порядке до момента создания функции.
Если для вашего языка программирования Git не умеет правильно определять функции и методы, вы можете передать ему регулярное выражение. Например, следующая команда выполнит такой же поиск как и предыдущая git log -L '/unsigned long git_deflate_bound/',/^>/:zlib.c . Также вы можете передать интервал строк или номер определённой строки и в этом случае вы получите похожий результат.
Читайте также: