веб-интерфейс github с неправильными «файлами chnanged», о которых сообщалось при создании PR-слияния из выпуска в мастер

Question

В нашем проекте мы проделывали это много раз. Но на этот раз это странно. При попытке создать PR для объединения ветки релиза с главной для развертывания, вместо того, чтобы сообщать об изменении менее 100 файлов, веб-интерфейс github считает, что изменилось 500 файлов. И многие из файловых различий неверны.

основная ветвь используется в качестве сборки ветки для производственного развертывания. ветвь релиза используется для сборки QA.

Например, файл foo. java не менялся месяцами и существует с одинаковой историей в обеих ветвях. Но пиар думает, что у мастера нет файла, и попробуйте добавить его. Даже незнакомец, если я делаю обратный пиар, от мастера к выпуску. Теперь измененные файлы github считают, что в выпуске нет файла.

Есть идеи, что может быть не так?

Answer 1

Не до конца понимаю, почему github это делает, но у меня есть обходной путь. Обходной путь - создать промежуточную ветвь из ветки релиза и использовать ее для объединения сначала с мастером, а затем создать PR с мастером в качестве базы.

git checkout release
git pull
git checkout -b test/master-to-release
git merge --no-commit master
git commit -m'test/master-to-release created branch from release. merge with master. use master for beam files. use release for the rest'
git push

На этом этапе создайте PR для теста / master-to -свободить с maser в качестве базы, тогда PR показывает только файлы, измененные в релизе правильно. Для той же ветви, когда создается PR с выпуском в качестве базы, он показывает только файлы, измененные с master. Таким образом, test / master-to-release - это промежуточная ветвь, используемая для разрешения конфликтов и обеспечения чистой базы веток для слияния с master или release.

Answer 2

Если вы проверите различие между двумя ветвями локально, вы можете определить, что изменилось:

• , либо регистр файла (верхний / нижний регистр)
• или разрешение (755 вместо 644)
• или символы eol (конец строк, когда для кого-то еще git config core.autocrlf было установлено значение true при фиксации)

Если это проблема перекрестного слияния , лучший вариант:

• выборка из исходного репозитория "upstream" для обновления ветки master upstream: upstream/master
• перебазирование вашей ветви PR поверх upstream / мастер
• git push --force указанная пиар ветка (перебазированная)