Отдельная фиксация для разрешения конфликта с помощью git merge

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

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

Вот что я делаю так:

git checkout master
git checkout -b merge-from-topic
git merge topic

Для записи файлов с конфликтами я использую временный файл:

git diff --name-only --diff-filter=U >conflicts.txt

Сначала я просто добавляю эти файлы с маркерами конфликтов в commit:

xargs git add <conflicts.txt
git commit

Затем я создаю другую ветку (для целей обзора), в которой я хотел бы разрешить конфликт:

git checkout -b resolve-merge-from-topic

Чтобы восстановить конфликты, я попробовал

xargs git reset HEAD^ -- <conflicts.txt

но затем git mergetool сказал, что ни один из файлов не нуждается в слиянии, хотя файлы в моем рабочем дереве имеют маркеры конфликтов.

Как восстановить файлы, перечисленные в файле conflicts.txt, чтобы я мог использовать git mergetool на них?

Я также открыт для других способов получения эффекта "отдельного фиксации для разрешения конфликтов".

ОТВЕТЫ

Ответ 1

git merge оставит маркеры конфликта.

Затем вы (обычно) вызываете git mergetool (с --tool вашего предпочтения) для разрешения конфликтов. В большинстве случаев это приведет к поэтапным изменениям. Это вы хотите изменить (например, используя git reset).

Теперь зафиксируйте "сырое" слияние в изоляции, а затем git add . && git commit -m 'resolutions' или git commit -am 'resolutions', чтобы добавить разрешения конфликтов.

Обратите внимание, что это оставляет вас с "сломанной" строкой при пересмотре границы слияния.

В шагах:

git checkout -b be_merged       # start a temp branch for the merge (safety)

git merge --no-commit diverge   # initiate merge from a diverged branch
git status                      # shows conflicts
git mergetool                   # resolve them as always
git status                      # shows resolutions as staged
git reset                       # unstage the changes
git status                      # shows unstaged changes (good!)
git commit -m 'merge, conflicts pending'   # commit the merge
git commit -am 'conflicts resolved'        # commit the resolutions

Ответ 2

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

Если вы хотите увидеть, как конфликт был разрешен, выполните diff в файле и просмотрите его историю.

Ответ 3

Если вы действительно настаиваете на получении истории слияния, то лучше всего использовать git -imerge

AFAIK git imerge дает вам выбор, если история слияния должна быть сохранена или нет

REF:

приложение из блога автора:

git merge боль

  • Вам нужно решить один большой конфликт, который смешивает много изменения по обе стороны слияния. (Устранение больших конфликтов сложно!)
  • Слияние - это все или ничего:
    • Невозможно сохранить частично выполненное слияние, поэтому
      • Вы не можете записать свой прогресс.
      • Вы не можете временно переключиться на другую ветку.
      • Если вы допустили ошибку, вы не можете вернуть только часть слияния.
      • Если вы не можете разрешить весь конфликт, вам нечего делать, кроме как начать.
    • Невозможно проверить частично выполненное слияние - код даже не будет создан до полного разрешения конфликта.
  • Трудно сотрудничать при слиянии с коллегой.

что может быть именно тем, почему вы требуете конфликтования в первую очередь.

С другой стороны, другая перспектива:

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

Теперь, если у вас есть фиксация, которая затрагивает все файлы на месте, это будет плохой материал, так как слияние, скорее всего, будет иметь конфликт (основной, возможно, конфликт, сделанный вами), поэтому у поддерживающего есть 2 варианта:

  • объединить его сам
  • отклонить слияние и позволить вам выполнять грязную работу.

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

Таким образом, вы будете тратить больше времени на разрешение конфликтов, чем на некоторую продуктивную работу.

ПРИМЕЧАНИЕ:

Вторая перспектива применима только тогда, когда у вас есть темы, имеющие простой диапазон. При слиянии тематических тем с большим диапазоном лучше использовать imerge и сохранять историю, таким образом, у вас будет меньше коммитов и rebase не будет болезненным.