2016-09-26 4 views
1

Я создал одну ветку xyz от мастера. Я сделал около 1000 коммитов и, возможно, изменил 20 файлов в xyz-ветке. Теперь я хочу перечислить все файлы, которые я изменил в ветке xyz.Как просмотреть все измененные файлы в определенной ветке?

Следующие файлы списков команд, измененные в обеих ветвях.

git diff --name-only master...xyz 
+0

drop '...': 'git diff - имя-только мастер xyz' – LeGEC

+0

Согласно [git diff documentation] (https://git-scm.com/docs/git-diff#_description) master ... xyz' для ** diff ** (а не 'log') должен дать именно то, что вам нужно. Если вы считаете, что это дает неверный результат, можете ли вы предоставить минимальный пример? – max630

ответ

3

Основная проблема здесь состоит в том, что git diff сравнивает два коммиты. Независимо от того, какие аргументы вы ему даете, это еще собирается выбрать два конкретных коммита, и сравнить эти два.

Что это означает, что для получения git diff, чтобы показать вам, что вы сделали в какой-то отрасли, вы должны выбрать два коммитов в этой ветви: одна для вызова «отправной точки» и один в называют «окончание точка». Если вы решите сделать это, это обычно помогает рисовать граф фиксации. Вы можете сделать это вручную или использовать git log --oneline --graph, чтобы помочь. (Хороший способ увидеть этот график для ваших двух ветвей по сравнению друг с другом - это git log --oneline --graph --decorate --boundary master...xyz.) Еще один способ - попробовать рисовать свой график самостоятельно, что может позволить вам представить его более компактно или использовать gitk или какой-либо другой графический просмотрщик, который будет рисовать график.

Если есть единый Merge базы COMMIT между наконечником фиксацией на master и кончик совершить на xyz, то:

git diff --name-only master...xyz 

будет сравнивать (и список имен файлов Modified), что конкретное объединение базой, против самого конца фиксации ветви XYZ. То есть, если граф выглядит что-то вроде:

  o--o--o--o--...--o--Z <-- master 
     /
...--o--* 
     \ 
      F--G-...--X    <-- xyz 

затем * является слияние базовой фиксации, Z является верхушкой фиксации на master, X является верхушкой фиксации на xyz и git diff master...xyz сравнит совершить * vs commit X. (В отличие от этого, git diff master..xyz -ночь две точки вместо трех, здесь будет сравнивать фиксацию Z против фиксации X.)

Тем не менее, учитывая, что git diff --name-only master...xyz не показывает вам, что вы хотите, вы можете git log --name-only master..xyz (вероятно, также с --oneline, я вижу gucce added this as a comment as well), чтобы показать вам, что происходит в каждый совершить что в xyz то есть не также в master. То есть, учитывая приведенный выше график, это будет присвоить значение * против фиксации F, затем F против G и т. Д. До сравнения с X. Обратите внимание, что это использует встроенную способность git log для разграничения каждой фиксации против ее родителя.


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

Это тоже немного преувеличение: давая git diff более чем одна пара фиксаций, вы можете получить его, чтобы производить то, что он называет комбинированный диф. Обычно это используется для коммитов слияния, чтобы показать точки, в которых объединенное содержимое отличается от всех родительских коммитов, т. Е. Когда конфликт слияния был разрешен путем выбора чего-то другого, кроме «того, что было в одной ветке». Но это тоже идет совсем не в том направлении, по сравнению с тем, что вы хотите достичь.

я имел это как T, для кончика из-хозяина, на мгновение, но потом понял, что T находится в алфавитном порядке между F и X. X для xyz, поэтому я изменил T на Z здесь, так что он приходит после X. Общая идея заключается в том, что мы не интересуемся большинством коммитов исключительно на master, за исключением самого наконечника, который выбирается именем master.

Если какое-либо из фиксаций в цепи F -through- X является слиянием совершить, git log даже не удосужился дифф его вообще, если не добавить некоторые дополнительные опции. То есть git log пропускает слияния, когда приходит время их разделить, если вы не попросите объединить различия (-c или --cc) или разделить слияния (-m). Все три из этих вариантов также имеют свои недостатки, поэтому лучше всего работать с ситуацией без слияния в первую очередь.

2

Как указано в @torek, команда git diff полностью игнорирует точечную нотацию.

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

git log --oneline --name-only develop..xyz | sort | uniq 

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

0871be6 commit 1 
9caad09 commit 2 
bb714f0 commit 3 
... 
path/to/file1 
path/to/file2 
path/to/file3 
path/to/file4 

Обратите внимание, есть только точек. Это означает, что учитывайте все изменения, которые находятся в xyz, но не в develop.

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

Ссылка: https://git-scm.com/book/tr/v2/Git-Tools-Revision-Selection#Commit-Ranges

+0

Я тоже это пробовал, он перечисляет файлы, даже которые я не изменил в ветке xyz. –

+0

Это верно для всех * других команд * Git, в частности 'git log', но не для' git diff', которые (ab) используют две и три точечных обозначения для других целей. В частности, 'git diff X ... Y' означает' git diff $ (git merge-base X Y) Y', а 'git diff X..Y' означает' git diff X Y'. 'git diff' не будет рассматривать промежуточные коммиты. (Нотация с тремя точками также подвержена другой проблеме, если нет базы слияния или если существует несколько баз слияния.) – torek

+0

Возможно, вы случайно добавили новую строку в конце или изменили окончание строки. Чтобы проверить, что было изменено для определенного файла в ветке 'xyz', вы можете использовать' git log -p develop..xyz - path/to/file'. В этом списке будут перечислены все коммиты из 'xyz' (но не' develop'), которые модифицировали 'путь/в/файл' и сам diff (' -p' для 'patch'). Попробуйте это в одном из файлов, которые, по вашему мнению, вы не изменили. – gucce

Смежные вопросы