Просмотр истории изменений файла с помощью управления версиями Git
Как я могу просмотреть историю изменений отдельного файла в Git, полную информацию о том, что было изменено?
Я дошел до:
git log -- [filename]
который показывает мне историю фиксации файла, но как мне получить доступ к содержимому каждого из изменений файла?
Я пытаюсь перейти с MS SourceSafe, и раньше это был простой right-click → show history.
Ссылка выше (опубликованная Крисом) больше не действительна. Эта ссылка сегодня работает: git-scm.com/book/en/v2
Ответы 24
Если вы используете графический интерфейс git (в Windows) в меню «Репозиторий», вы можете использовать «Визуализировать историю мастера». Выделите фиксацию на верхней панели и файл в правом нижнем углу, и вы увидите разницу для этой фиксации в нижнем левом углу.
Как это отвечает на вопрос?
Что ж, OP не указывал командную строку, и, переходя от SourceSafe (который является графическим интерфейсом пользователя), казалось уместным указать, что вы можете делать почти то же самое, что вы можете делать в VSS в графическом интерфейсе Git в Windows.
Вы можете использовать
git log -p filename
чтобы позволить git генерировать патчи для каждой записи журнала.
Видеть
git help log
для дополнительных опций - он действительно может делать много хороших вещей :) Чтобы получить только разницу для конкретного коммита, вы можете
git show HEAD
или любая другая ревизия по идентификатору. Или используйте
gitk
для просмотра изменений визуально.
git show HEAD показывает все файлы, знаете ли вы, как отслеживать отдельный файл (как просил Ричард)?
вы используете: git show <revision> - имя файла, которое покажет различия для этой ревизии, если она существует.
--stat также полезен. Вы можете использовать его вместе с -p.
Отлично. gitk плохо себя ведет при указании путей, которые больше не существуют. Я использовал git log -p - path.
Плюс gitk выглядит так, будто его построил монстр буги-вуги. Это отличный ответ, который лучше всего подходит для исходного вопроса.
добавление --follow также учитывает переименование файлов.
На этот вопрос есть лучший ответ, в котором используется флаг --follow.
Мне нравится ответ @ghayes: p И +1 за этот ответ; Я считаю, что хороший терминал может отображать разницу гораздо четче, чем визуальный инструмент.
git log --follow -p file_path должен быть принят ответ
-p = Generate patch = показать разница кроме фиксации описаниеgit whatchanged -p filename в этом случае также эквивалентен git log -p filename.
Вы также можете увидеть, когда определенная строка кода внутри файла была изменена с помощью git blame filename. Это распечатает короткий идентификатор фиксации, автора, метку времени и полную строку кода для каждой строки в файле.
Это очень полезно после того, как вы обнаружили ошибку и хотите знать, когда она появилась (или кто виноват в ней).
«Новым пользователям рекомендуется использовать вместо этого git-log. (...) Команда сохраняется в основном по историческим причинам»;
Для графического представления я бы использовал gitk:
gitk [filename]
или следовать за именем файла после переименований
gitk --follow [filename]
Но у меня даже есть инструмент, сочетающий вышесказанное с git blame, позволяющий мне просматривать источник файла по мере его изменения во времени ...
GitWeb - ответ на этот вопрос.
К сожалению, это не соответствует истории прошлых переименований файла.
Я также искал историю файлов, которые были ранее переименованы, и первым нашел эту ветку. Решение состоит в том, чтобы использовать «git log --follow <filename>», как указал Фил здесь.
Автор искал инструмент командной строки. Хотя gitk поставляется с GIT, это не приложение командной строки и не особо хороший графический интерфейс.
Хороший совет. На моей машине (git v1.7.10) мне пришлось использовать gitk -- [filename].
Он искал инструмент командной строки? "щелчок правой кнопкой мыши -> показать историю", конечно, не подразумевает этого.
Внимание! Пользователи Windows ... Путь к имени файла чувствителен к регистру.
@DanMoulding: gitk --follow [filename] показывает историю последних переименований файла. Однако он не показывает изменения содержимого файла перед переименованием. См. Ответ это.
если этот файл удален, и вы хотите узнать, кто его удалил, следует использовать git log -- [filename]
не ищу ничего, кроме git, это не должен быть принятый ответ
gitk не входит в базовый пакет git. Вам необходимо загрузить пакет tk, чтобы использовать gitk. @ VolkA ответ лучше, git log -p filename работает без каких-либо зависимостей.
Возник вопрос: «Просмотрите историю изменений файла с помощью управления версиями Git». Это именно то, что делает gitk. Он ищет изменения в истории коммитов git. Меня не волнует, является ли он частью базового пакета git, если он выполняет свою работу быстро и просто.
@HenriquedeSousa: Потому что спрашивающий посчитал этот ответ самым полезным ему.
gitk работает как шарм. это помогло мне проверить историю одного файла, именно то, что мне было нужно.
Есть ли способ сделать это с помощью gitGUI?
голосование против из-за использования другого инструмента, лучше использовать стандартный cli из ответа stackoverflow.com/a/278242/1700569
В принятом ответе следует учитывать, что не у всех в системе установлен gitk. Если бы я был в среде только с интерфейсом командной строки, не было бы доступного графического интерфейса. OP попросил использовать команду "git". Использование gitweb, gitk или чего-то еще - это то же самое, что сказать «просто зайдите на GitHub и проверьте там историю».
Этот ответ не должен быть принятым imo. Я лично использую Gitx, а не Gitk, но мне тоже не нужен ответ, специфичный для Gitx. Ответ git log -p ниже гораздо более применим для большинства пользователей.
независимо от того, каким должен быть принятый ответ, +1 за содействие умопомрачительным действиям gitk
Что такое gitk?
@JimAho инструмент визуализации git
почему этот ответ считается правильным, если он предлагает использовать стороннюю утилиту? правильный ответ остается ниже (@DanMoulding является автором)
Если вы пришли, как и я, из среды Windows и не знаете, что такое gitk, вы найдете его как часть Git for Windows. Запуск из приложения git-bash.exe (эмулятора командной строки Linux). Git for Windows, git bash и gitk потрясающие ...
Чтобы показать, какая редакция и автор последний раз изменяли каждую строку файла:
git blame filename
или если вы хотите использовать мощный графический интерфейс пользователя:
git gui blame filename
Или же:
gitx -- <path/to/filename>
если вы используете gitx
По какой-то причине мой gitx открывается пустым.
@IgorGanapolsky, вы должны убедиться, что находитесь в корне вашего репозитория git
git log --follow -p -- path-to-file
Это покажет историю весь файла (включая историю помимо переименований и с различиями для каждого изменения).
Другими словами, если файл с именем bar когда-то назывался foo, то git log -p bar (без опции --follow) будет отображать историю файла только до того момента, когда он был переименован - он не будет отображать историю файла, когда он был известен. как foo. Использование git log --follow -p bar покажет всю историю файла, включая любые изменения в файле, когда он был известен как foo. Опция -p гарантирует включение различий при каждом изменении.
Я нахожу это немного странным, но вы не можете использовать флаг -CC с log --follow file, иначе он ничего не найдет (git 1.7.0.4).
--stat также полезен. Вы можете использовать его вместе с -p.
Я согласен, это НАСТОЯЩИЙ ответ. (1.) --follow гарантирует, что вы видите переименования файлов (2.) -p гарантирует, что вы видите, как файл изменяется (3.) это только командная строка.
Добавьте -- перед вашим file, и это будет абсолютно лучший ответ!
Вау. Меня устраивает. stackoverflow.com/a/1321962/3034747 и stackoverflow.com/a/5493663/3034747 нет. Не знаю почему .. Я использую Ubuntu и GIT версии 2.0.2
«фатальный: неоднозначный аргумент 'my_file_name': неизвестная ревизия или путь не в рабочем дереве».
@NHDaly Я заметил, что был добавлен --, но я не знаю, почему это лучше всего? Что он делает?
@Benjohn Параметр -- сообщает Git, что он достиг конца параметров и что все, что следует за --, следует рассматривать как аргумент. Для git log это имеет значение только в том случае, если у вас есть путь, начинающийся с бросаться. Допустим, вы хотите узнать историю файла с неудачным именем "--follow": git log --follow -p -- --follow
@Benjohn: Обычно -- полезен, потому что он также может защитить от любых имен revision, которые соответствуют введенному вами имени файла, что на самом деле может напугать. Например: если у вас есть и ветка, и файл с именем foo, git log -p foo будет показывать историю журнала git до foo, а не историю для файлfoo. Но @DanMoulding прав в том, что, поскольку команда --follow принимает в качестве аргумента только одно имя файла, в этом нет необходимости, поскольку это не может быть revision. Я только что узнал об этом. Может быть, вы были правы, когда не упомянули об этом в своем ответе; Я не уверен.
Это безумие, как далеко на длинной странице документации по git журнал нужно прочитать до раздела «Генерация патчей с -p». Этот ответ отлично объясняет --follow, было бы полезно объяснить и -p.
на самом деле @JohnLawrenceAspden поднял хороший момент (в своем ответе), чтобы также включить --all для просмотра истории файлов во всех ветвях. может быть полезно в некоторых случаях.
Будьте осторожны, чтобы не ввести неправильно имя файла (я забыл букву «s» в конце имени файла). В журнале git вы увидите сообщение skipping..., за которым следует серия тильд ~ (предположительно, по одной для каждой фиксации / я не знаю).
Выкидывающая ошибка. fatal: unrecognized argument: --folow. Но команда git log -p <file/to/the/path> работала.
Ответ, который я искал, которого не было в этой теме, - это увидеть изменения в файлах, которые я подготовил для фиксации. т.е.
git diff --cached
Если вы хотите включить локальные (неустановленные) изменения, я часто запускаю git diff origin/master, чтобы показать полные различия между вашей локальной и главной ветвью (которые можно обновить удаленно через git fetch).
Если вы предпочитаете оставаться на основе текста, вы можете использовать тигр.
Быстрая установка:
- apt-get:
# apt-get install tig - Домашнее пиво (OS X):
$ brew install tig
Используйте его для просмотра истории одного файла: tig [filename]
Или просмотрите подробную историю репо: tig
Аналогичен gitk, но основан на тексте. Поддерживает цвета в терминале!
Отличный текстовый инструмент, отличный ответ. Я испугался, когда увидел зависимости для установки gitk на мой безголовый сервер. Проголосовал бы снова A +++
Вы также можете посмотреть определенные файлы с помощью tig, например tig -- path/to/specific/file
Если вы хотите увидеть всю историю файла, включая в ветках все остальные используйте:
gitk --all <filename>
Я написал git-воспроизведение именно для этой цели
pip install git-playback
git playback [filename]
Это имеет то преимущество, что результаты отображаются в командной строке (например, git log -p), а также позволяет вам проходить каждую фиксацию с помощью клавиш со стрелками (например, gitk).
С помощью отличного Расширения Git вы переходите к точке в истории, где файл все еще существовал (если он был удален, в противном случае просто переходите в HEAD), переключаетесь на вкладку File tree, щелкаете правой кнопкой мыши по файлу и выбираете File history.
По умолчанию он следует за файлом через переименования, а вкладка Blame позволяет увидеть имя данной ревизии.
У него есть некоторые незначительные ошибки, например, отображение fatal: Not a valid object name на вкладке View при нажатии на ревизию для удаления, но я могу с этим жить. :-)
Стоит отметить, что это только для Windows.
@EvanHahn неточно, через моно можно использовать GitExtension также в Linux, мы используем его в ubuntu и вполне довольны этим. см. git-extensions-documentation.readthedocs.org/en/latest/…
Краткое изложение других ответов, прочитанных и немного поигравших:
Обычная команда командной строки будет
git log --follow --all -p dir/file.c
Но вы также можете использовать либо gitk (gui), либо tig (text-ui), чтобы сделать его более понятным для человека.
gitk --follow --all -p dir/file.c
tig --follow --all -p dir/file.c
В debian / ubuntu команда установки этих прекрасных инструментов выглядит так, как ожидалось:
sudo apt-get install gitk tig
И в настоящее время я использую:
alias gdf='gitk --follow --all -p'
так что я могу просто набрать gdf dir, чтобы получить целенаправленную историю всего в подкаталоге dir.
Думаю, это отличный ответ. Возможно, вас тоже не проголосуют, потому что вы отвечаете другими способами (имхо лучше), чтобы увидеть изменения, то есть через gitk и tig в дополнение к git.
Просто чтобы добавить к ответу. Найдите путь (в пространстве git, до которого все еще существует в репозитории). Затем используйте указанную выше команду «git log --follow --all -p <folder_path / file_path>». Может случиться так, что папка filde / была бы удалена из истории, поэтому найдите максимальный путь, который еще существует, и попытайтесь получить его историю. работает !
--all предназначен для всех веток, остальное объясняется в ответе @Dan
О, чувак, после столь долгого поиска хорошего решения для отслеживания файлов, помимо переименований, я наконец нашел его здесь. Работает как шарм! Спасибо!
Если вы используете eclipse с подключаемым модулем git, у него есть отличный обзор для сравнения с историей. Щелкните файл правой кнопкой мыши и выберите «сравнить с» => «история».
Однако это не позволит вам найти удаленный файл.
Сравнение двух версий файла отличается от просмотра истории изменений файла.
git diff -U <filename> даст вам унифицированный diff.
Он должен быть окрашен в красный и зеленый цвета. Если это не так, запустите сначала: git config color.ui auto.
Добавьте этот псевдоним в свой .gitconfig:
[alias]
lg = log --all --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset'\n--abbrev-commit --date=relative
И используйте такую команду:
> git lg
> git lg -- filename
Вывод будет выглядеть почти так же, как вывод gitk. Наслаждаться.
После того, как я запустил этот ярлык lg, я сказал (и цитирую) «Красиво!». Однако обратите внимание, что "\ n" после "--graph" является ошибкой.
Также можно использовать git lg -p filename - он возвращает красивый diff искомого файла.
Пользователи SourceTree
Если вы используете SourceTree для визуализации своего репозитория (это бесплатно и неплохо), вы можете щелкнуть файл правой кнопкой мыши и выбрать Выбран журнал
Дисплей (ниже) намного удобнее, чем gitk и большинство других перечисленных опций. К сожалению (в настоящее время) нет простого способа запустить это представление из командной строки - интерфейс командной строки SourceTree в настоящее время просто открывает репозиторий.
Мне особенно нравится опция «Следить за переименованными файлами», которая позволяет увидеть, был ли файл переименован или перемещен.
но если я не ошибаюсь (пожалуйста, дайте мне знать!), в графическом интерфейсе можно одновременно сравнивать только две версии? Есть ли клиенты, у которых есть элегантный интерфейс, позволяющий различать сразу несколько разных версий? Возможно, с уменьшенным изображением, как в Sublime Text? Думаю, это было бы действительно полезно.
@SamLewallen Если я правильно понял, вы хотите сравнить три разных коммита? Это похоже на трехстороннее слияние (мое, ваше, базовое) - обычно эта стратегия используется для разрешения конфликтов слияния, не обязательно для сравнения трех произвольных коммитов. Есть много инструментов, которые поддерживают трехстороннее слияние stackoverflow.com/questions/10998728/…, но хитрость заключается в том, что для этих инструментов используются определенные версии gitready.com/intermediate/2009/02/27/….
Спасибо, Марк Фокс, вот что я имею в виду. Вы случайно не знаете какие-нибудь приложения, которые будут это делать?
Вы спасаете мне жизнь. Вы можете использовать gitk, чтобы найти хэш SHA1, а затем открыть SourceTree, чтобы ввести Log Selected.. на основе найденного SHA1.
Идеально. Я искал такое же решение в сообществе ATLASSIAN community.atlassian.com/t5/Sourcetree-questions/…
@AechoLiu Зачем вам SHA, если у вас уже есть имя файла? (В любом случае, если вам нужен SHA, вы также можете найти его с помощью SourceTree.)
@ MarnenLaibow-Koser Я не могу вспомнить, зачем мне тогда нужен SHA. Ахаха.
Если вы используете TortoiseGit, вы сможете щелкнуть файл правой кнопкой мыши и выполнить TortoiseGit --> Show Log. В появившемся окне убедитесь:
Опция «
Show Whole Project» не отмечена.Опция «
All Branches» отмечена.
TortoiseGit (а также Eclipse Git) как-то пропускает ревизии выбранного файла, не рассчитывайте на это!
@NoamManos, я не сталкивался с этой проблемой, поэтому я не могу проверить правильность вашего утверждения.
Моя ошибка, это происходит только в Eclipse, но в TortoiseGit вы можете видеть все версии файла, если сняли флажок «показать весь проект» + отметили «все ветки» (в случае, если файл был зафиксирован в другой ветке, до того, как он был объединен с основным ветка). Я обновлю твой ответ.
Вы также можете попробовать это, в котором перечислены коммиты, которые изменили определенную часть файла (реализовано в Git 1.8.4).
Возвращенным результатом будет список коммитов, которые изменили эту конкретную часть. Команда:
git log --pretty=short -u -L <upperLimit>,<lowerLimit>:<path_to_filename>
где upperLimit - это start_line_number, а lowerLimit - это конечный_line_number файла.
Подробнее на https://www.techpurohit.com/list-some-useful-git-commands
Недавно я обнаружил tig и нашел его очень полезным. В некоторых случаях я бы хотел, чтобы он выполнял A или B, но в большинстве случаев это довольно аккуратно.
В вашем случае tig <filename> может быть тем, что вы ищете.
на centos yum установить tig
- В меню включить отображение неизмененных файлов: Просмотр / Показать неизмененные файлы
- Щелкните файл правой кнопкой мыши и выберите «Журнал» или нажмите «Ctrl-L».
Вы можете использовать vscode с GitLens, это очень мощный инструмент.
После установки GitLens перейдите на вкладку GitLens, выберите FILE HISTORY, и вы сможете просмотреть его.
Я, наверное, о том, где был OP, когда это началось, ищу что-то простое, что позволило бы мне использовать git difftool с vimdiff для просмотра изменений файлов в моем репо, начиная с определенного коммита. Я был не очень доволен найденными ответами, поэтому я скинул этот сценарий git incremental представительorter (gitincrep) вместе, и он мне пригодился:
#!/usr/bin/env bash
STARTWITH = "${1:-}"
shift 1
DFILES=( "$@" )
RunDiff()
{
GIT1=$1
GIT2=$2
shift 2
if [ "$(git diff $GIT1 $GIT2 "$@")" ]
then
git log ${GIT1}..${GIT2}
git difftool --tool=vimdiff $GIT1 $GIT2 "$@"
fi
}
OLDVERS = ""
RUNDIFF = ""
for NEWVERS in $(git log --format=format:%h --reverse)
do
if [ "$RUNDIFF" ]
then
RunDiff $OLDVERS $NEWVERS "${DFILES[@]}"
elif [ "$OLDVERS" ]
then
if [ "$NEWVERS" = "${STARTWITH:=${NEWVERS}}" ]
then
RUNDIFF=true
RunDiff $OLDVERS $NEWVERS "${DFILES[@]}"
fi
fi
OLDVERS=$NEWVERS
done
Вызывается без аргументов, он будет начинаться с начала истории репо, в противном случае он начнется с любого сокращенного хеша фиксации, который вы предоставите, и перейдет к настоящему моменту - вы можете в любой момент выйти с помощью Ctrl-C. Любые аргументы после первого будут ограничивать отчеты о различиях, чтобы включать только файлы, перечисленные среди этих аргументов (что, я думаю, это то, что хотел OP, и я бы рекомендовал для всех, кроме крошечных проектов). Если вы проверяете изменения в определенных файлах, которые и хочет начать с самого начала, вам нужно будет предоставить пустую строку для arg1. Если вы не являетесь пользователем vim, вы можете заменить vimdiff своим любимым инструментом сравнения.
Поведение - выводить комментарии фиксации при обнаружении соответствующих изменений и предлагать запуски vimdiff для каждого измененного файла (это поведение git difftool, но здесь оно работает).
Этот подход, вероятно, довольно наивен, но, просматривая множество решений здесь и в соответствующем посте, многие включали установку новых инструментов в системе, в которой у меня нет доступа администратора, с интерфейсами, которые имели свою кривую обучения. Приведенный выше сценарий делал то, что я хотел, не обращая на это внимания. Я рассмотрю множество отличных предложений здесь, когда мне понадобится что-то более сложное, но я думаю, что это напрямую связано с OP.
В пользовательском интерфейсе Sourcetree (https://www.sourcetreeapp.com/) вы можете найти историю файла, выбрав опцию «Журнал выбранных» в контекстном меню правой кнопки мыши:
Он покажет историю всех коммитов.
Откуда этот графический интерфейс?
Sourcetree UI. Спасибо
что такое окна?
Вышеупомянутая ссылка больше не действительна. Эта ссылка сегодня работает: Книга сообщества Git