Как найти общие файлы, измененные между ветками git?
У меня есть вышестоящий репозиторий с некоторыми изменениями. У меня есть локальные изменения, которые я хочу перебазировать в вышестоящие изменения. Я хочу знать, какие файлы, которые я изменил локально, также изменились в апстриме, чтобы я мог проверить любое автоматическое слияние. В качестве альтернативы, я бы хотел сделать любые слияния вручную во время ребазинга.
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.
Установите для всех коммитов значение "Редактировать", и вы будете проходить каждый из них по одному, давая вам возможность увидеть все, что было сделано для этого коммита, и отредактировать по своему усмотрению.
РЕДАКТИРОВАТЬ, чтобы ответить на комментарий
ОК, для строгого просмотра измененных файлов выполните:
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 кончиками двух расходящихся ветвей.
Список измененных файлов
Поскольку перебазировка / слияние может занимать много времени, лучше избегать ненужного. Существует множество способов узнать, что изменилось, в зависимости от того, какая информация вам нужна.
Если вам интересно узнать, какие файлы были изменены, я бы предложил 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 я видел множество конфликтов, но не могу вспомнить ни одного неправильного автоматического слияния. Я лично верю, что это возможности слияния. Проверка на это после должно быть действительно много.
Я знаю, что это действительно старая тема, но мы обнаружили, что 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
В нем будут перечислены 20 лучших файлов вашей ветки, которые наиболее часто менялись
git log --pretty= формат: --name-only | сортировать | uniq -c | сортировать -rg | голова -20