Вопрос по git – Как найти общие файлы, измененные между ветками git?

5

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

Ваш Ответ

4   ответа
12
Listing changed files

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

Если вам интересно узнать, какие файлы были изменены при фиксации, я предлагаюgit-log:

git log [--pretty=<format>] --name-only <common-branch>..<local-branch>

Вы можете использовать--pretty возможность получить нужную информацию заголовка;<format> могут быть различные варианты, в том числе пользовательская строка с полями - см. справочную страницу для получения дополнительной информации.

--name-only вариант на самом деле передается вgit-diff, так что, если вам не нужны результаты за фиксацию, вы можете перейти непосредственно к источнику:

git diff --name-only <common-branch> <local-branch>

Обратите внимание, что ветви для разных команд указаны по-разному.

Вы также можете применить это к изменениям в верхнем течении, изменяя<local-branch> в<upstream-branch>и заканчиваются двумя списками файлов. Я оставлю на ваше усмотрение выяснить, как вы хотите их сравнить, хотя опция -f в grep может быть полезна ...

Manual merges

Самодержавие избило меня до этого. Если вы выполнили некоторую интеллектуальную обработку на основе выводаgit-log Вы могли редактировать только те коммиты, которые, как вы видели, имели перекрывающиеся изменения файла. Если вы объединяете, а не перебазируете, вы используете--no-commit вариант.

Смотрите также раздел конфигурацииgit-merge справочная страница. Возможно, вы захотите установить для merge.conflictstyle значение diff3, чтобы вы могли видеть исходный текст, а также изменения с обеих сторон.

Если вы действительно отчаянно пытаетесь подавить все попытки автоматического разрешения конфликтов, я полагаю, что вы могли бы подключить фиктивный инструмент mergetool (через merge.tool и mergetool.cmd), который ничего не делает и возвращает ошибку.

Сказав все это, я также должен сказать, что в своем опыте с git-слияниями я видел множество конфликтов, но не могу вспомнить ни одного неправильного автоматического слияния. Я лично доверяю его возможностям слияния. Проверки после этого должно быть достаточно.

Я доверяю слиянию git, но иногда было бы неплохо узнать, на каких вещах вам нужно сконцентрироваться при тестировании, если вы изменили несколько файлов. Mike Pape
4

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

git branch workBranch
git commit #throw your locals into your own branch for a brief moment
git branch testBranch
git rebase otherBranch
git diff workBranch

Вы могли бы также сойти с рук только с помощью "git diff origin / branchToMerge"

Для интерактивной части:

git rebase --interactive.

Установите для всех коммитов значение & quot; Редактировать & quot; и вы будете проходить через каждого из них по одному, что даст вам возможность увидеть все, что сделано для этого коммита, и отредактировать по своему усмотрению.

EDIT to answer comment

ОК, для строгого просмотра измененных файлов выполните:

git log a0a0a0..b1b1b1 --name-only --pretty=oneline | egrep -v '^[a-f0-9]{40} ' | sort | uniq > lista
git log a0a0a0..c2c2c2 --name-only --pretty=oneline | egrep -v '^[a-f0-9]{40} ' | sort | uniq > listb
cat lista listb | sort | uniq -d

Этот бит оболочки Kludgery покажет вам только файлы, которые изменились в обоих журналах. Для a0a0a0 используйте вашу общую точку. Замените струны b1 / c2 кончиками двух расходящихся ветвей.

вместо egrep попробуйте --pretty = & quot; формат: & quot; с --name-only это удалит все остальные вещи и просто оставит несколько пустых строк
В итоге я выполнил слияние в тестовой ветке и затем посмотрел на все «автоматически объединенные». Сообщения. Спасибо за сценарий, хотя, я могу использовать это в следующий раз. Mike Pape
Если я сравню свою перебазированную ветку с моей рабочей веткой, она не покажет все изменения в другой ветке, а не только набор файлов, измененных вboth рабочий филиал и др. филиал. Mike Pape
1

что это действительно старая тема, но мы обнаружили, что git diff --name-only возвращал слишком много ложно положительных измененных файлов, если две ветви слишком разные. Вот то, что мы используем на работе для выполнения проверки кода для фиксации новой ветки относительно нашей ветки функций (возможно, уже частично слитой в ветке функций).

находясь в нашей системе new_branch и под * nix, мы используем эту команду:

git show --name-only $( git cherry -v feature_branch | grep '^+' | awk '{ print($2) }' ) | egrep -v '^(commit |Author:|Date:|\s|$)' | sort -u

заменив feature_branch именем ветви, с которой вы хотите проверить измененные файлы.

Преимущества этого метода в том, что он действительно сортирует только файлы, модифицированные коммитами, которые принадлежат вашей ветке и которые еще не объединены в вашем feature_branch.

Если вы хотите проверить между двумя коммитами SHA1 и SHA2, вы также можете сделать:

git show --name-only $( git cherry -v SHA1 SHA2 | grep '^+' | awk '{ print($2) }' ) | egrep -v '^(commit |Author:|Date:|\s|$)' | sort -u
0

которые наиболее часто менялись

git log --pretty = формат: --name-only | сортировать | uniq -c | сортировать -rg | голова -20

Похожие вопросы