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

Question

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

Answer 1

Список измененных файлов

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

Если вам интересно узнать, какие файлы были изменены, я бы предложил 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 может быть полезна ...

Ручное слияние

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

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

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

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

Answer 2

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

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.

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

РЕДАКТИРОВАТЬ, чтобы ответить на комментарий

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

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 кончиками двух расходящихся ветвей.

Answer 3

Я знаю, что это действительно старая тема, но мы обнаружили, что 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

Answer 4

в этом списке будут перечислены 20 файлов вашей ветки, которые наиболее часто менялись

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