2010-01-19 7 views
7

Я собираюсь переместить тонну файлов в существующий проект. Прежде чем я это сделаю, я хотел бы твердо понять некоторые методы, используемые для анализа кода, который имеет историю с несколькими файлами.Git: как анализировать код с многофайловой историей?

Как я могу использовать git, чтобы спросить: «Откуда взялась эта строка кода?» когда контент переместился через несколько файлов в его жизненный цикл?

Я знаю, что git не отслеживает переименования явно (по уважительной причине), поэтому мне кажется, что я могу это спросить, я просто не знаю, как это сделать. Если есть способ визуализировать это, было бы здорово это знать.

ответ

5

Я бы рекомендовал посмотреть на три инструмента в наборе инструментов git. Первый - это виноват, что очень похоже на то, что есть в cvs. Он показывает, какие фиксации последнего касались каждой строки файла. Если вы хотите посмотреть, что было раньше, вы можете взять фиксацию, которая коснулась строки, и посмотреть предыдущую фиксацию.

git show <sha1_of_interesting_commit>^ -- file/path 

Вы можете повторить вину, чтобы узнать, что произошло до этого.

git blame <sha1_of_interesting_commit>^ -- file/path 

Второй инструмент используется --follow для отслеживания файлов мимо переименовывает.

git log --follow -- file/path 

Третий - и, возможно, самый полезный инструмент - это опция кирки для регистрации. Это ведет поиск по истории изменений удаленных, введенных или измененных строк, содержащих данный бит текста. Это особенно полезно для отслеживания таких функций, как имена функций. Он может быть новым в файле в конкретном коммите, но он исходил из другого исходного файла? Был ли призыв к нему добавлен одновременно или раньше?

git log -S"Interesting_Function" 

Если вы используете патч или стат вариант (например, -p или --stat) выход будет ограничен для тех файлов, изменения фактически участвуют в строку поиска, если вы не используете --pickaxe-all, где отображается вся смена.

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

0

git blame это то, что вы хотели бы задать, «откуда взялась эта строка кода?». Я не знаю, обрабатывает ли он переименования. Наверное, делает.

+1

git винить не подходит для обнаружения движения линии (особенно при рефакторинге кода). Я имею в виду, если один разработчик написал строку, то следующий разработчик по какой-то причине переместил строку вверх или вниз - git виноват будет показывать последнее. – Eimantas

+0

Я не думаю, что этот ответ полезен, потому что 1) 'git blame' не говорит вам, откуда появился какой-то конкретный фрагмент кода, - вот что такое' git log'. 'git blame' просто говорит вам последнему, кто редактирует каждую существующую строку кода в файле. 2) 'git blame' не следует переименовать, если вы не добавите параметр' --follow', как указано принятым ответом (и даже тогда он распадается, если файлы были объединены, реструктурированы и т. Д.). –