GIT объединяет существующий файл как «новый»

Question

У меня есть две ветви: master и DevMaster.

Допустим, у нас есть файл в master со ссылкой: src/AppFiles/Submissions/CompleteSubmission.java

Этот же файл существуетв DevMaster.

При выполнении слияния из мастера в DevMaster он обнаруживает указанный выше файл как новый файл, даже если он существует идентично файлу в мастере.Это не имеет никакого смысла ни для меня, ни для моей команды.

Редактировать: Кроме того, я выполняю слияние в этой ветви, и ВСЕ ЕЩЕ обнаруживается как новое, даже после того, как я только что слил его.

Answer 1

Все операции слияния выполняются с базы слияния .База слияния - это «лучший» коммит общего предка из двух ¹ коммитов, которые должны быть объединены.Я думаю, что проще всего понять это визуально.Извлеките два коммитов-подсказок вместе с именами ветвей, которые их идентифицируют (или используйте git log --decorate --oneline --graph branch1 branch2, чтобы заставить Git делать это вертикально):

     J  <-- branch1



     L  <-- branch2

Follow J (что означает несколько большихуродливый хеш коммита) обратно к его родителю I и то же самое с L к его родителю K:

  I--J  <-- branch1



  K--L  <-- branch2

Повторяйте, пока не найдете коммит, который находится на оба branch:

  I--J  <-- branch1
 /
H
 \
  K--L  <-- branch2

Найденный вами коммит является базой слияния.(Не все базы слияния будут отображаться так аккуратно и просто, как это! Большинство графиков ужасно запутаны.)

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

git merge-base --all branch1 branch2

скажетВы, что такое база слияния, пока вы ее запускаете до запуска git merge.(Впоследствии одно из двух имен веток указывает на новый коммит слияния , а база слияния - это просто другая ветка / коммит.) Используйте необработанные хэши коммитов после слияния, если вы хотите увидеть, чтобаза слияния была .

Когда у вас есть сама база слияния, процесс слияния становится понятным.Git запускает две git diff команды: одна сравнивает базовый коммит слияния с наконечником branch1, а другая сравнивает (тот же) базовый коммит слияния с наконечником branch2.Эти различия помогают Git объединять каждый набор изменений в каждом файле.

Если в фиксации базы слияния нет какого-либо файла, который существует в обеих подсказках ветви, то этот файл имеетКонфликт add/add: он абсолютно новый в обеих ветках, и Git не знает, как объединить два файла, если они не совпадают точно.

Результат автоматического объединения по умолчанию (одно без параметров и без остановки доредактировать результат) полностью определяется тремя входными коммитами.Вы не можете просто сравнить два коммита с ветвлением и друг с другом! Вы должны сравнить каждый коммит с ветвью и (общую) базу слияния.

---

¹ В случае слияния осьминога - слияния более двух коммитов - база слияния вычисляется немного по-другому.

Answer 2

Так что с удаленной версией филиала происходило забавное дело.Я сделал слияние локально с помощью предложений @Angelo Mendes и @Marek R (почему теги не работают на этой странице?), И слияние в моем локальном файле обнаружило только одно изменение файла, что мы и ожидали.Чтобы это исправить, я перетянул все файлы из моей удаленной ветки в локальную, удалил удаленную, а затем передал локальную в удаленную.Теперь новые PR не читают все уже существующие файлы.

Answer 3

@ marcel сначала проверьте, передается ли файл на удаленный компьютер. Проверьте это на клиентском браузере bitbucket.