Когда происходит столкновение git merge
, я открываю mergetool под названием Meld . Открываются три файла LOCAL, BASE и REMOTE. Поскольку я читал, LOCAL - это моя локальная ветвь, BASE - это общий предок, а REMOTE - ветвь, которую нужно объединить.
Теперь на мой вопрос: какая версия файла будет окончательно использована? Это удаленно? Если да, могу ли я редактировать его так, как я хочу, независимо от того, что находится, например, в ветке BASE?
merge.conflictstyle
установлен параметр конфигурацииdiff3
вместо значения по умолчаниюmerge
.HEAD
,<<<<<
и=====
признаки, то это означает , что не существует никакого конфликта вообще. В этом случае среднее окно не будет пустым, оно покажет результат слияния, но не будет «красной» части<<<<<<
,======
ни>>>>>>
маркеры в средней панели (т.е. версии базовой) либо; и иногда средняя панель будет пустой, как сообщает aGr. Возможно, это различие связано с разными настройками. Когда я начинаю инструмент сливаться, следующие файлы будут существовать, если предположить , что имя файла в хранилище являетсяX.java
:X.java
,X.java.orig
,X.java.BACKUP.#
,X.java.BASE.#
,X.java.LOCAL.#
,X.java.REMOTE.#
, где#
некоторое число. Называя результат слияния, BASE-версия сбивает с толку; MERGED будет лучше.У Meld есть скрытая функция трехстороннего слияния, активируемая передачей 4-го параметра:
Правая и левая панели открываются в режиме «только для чтения», поэтому вы не можете случайно слить их неправильно. Средняя панель показывает результат слияния. Для конфликтов он показывает базовую версию, чтобы вы могли видеть все важные биты: оригинальный текст посередине и конфликтующие модификации с обеих сторон. Наконец, когда вы нажимаете кнопку «Сохранить», файл $ MERGED записывается - в точности так, как ожидал git.
Файл ~ / .gitconfig, который я использую, содержит следующие настройки:
это открывает объединение с 3 вкладками, 1-я и 2-я вкладка, содержащая простые различия, которые я пытаюсь объединить, и 3-я вкладка, открытая по умолчанию, показывает трехстороннее представление слияния.
Теперь, причина, по которой функция скрыта, заключается в том, что она еще недостаточно отшлифована. Это очень полезно, как и сейчас, но Кай Вилладсен, автор слияния, указал на несколько морщин, которые нужно сгладить. Например, нет графического интерфейса для запуска режима трехстороннего слияния, синтаксис командной строки немного загадочный и тому подобное. Если вы говорите на питоне и у вас есть немного времени - вы знаете, что делать.
Изменить: В более новых версиях Мелд, Синакс немного изменился. Это было в комментариях, но это относится к ответу.
Команда meld теперь использует параметр --output, поэтому последняя строка из приведенного выше фрагмента должна быть:
источник
--output
для результата $ MERGED. Я обнаружил это, глядя на скрипт запуска meld, который шел с моей версией git: github.com/git/git/blob/master/mergetools/meld--output option
. Смотрите эту строку в сценарии запуска:"$merge_tool_path" --output "$MERGED" "$LOCAL" "$BASE" "$REMOTE"
cmd = meld $LOCAL $BASE $REMOTE --auto-merge --output $MERGED
. Таким образом, это открывает 3 вкладки (старый добрый способ), автоматическое слияние неконфликтных слияний в середину, где середина - $ MERGED, и будет использоваться в качестве вывода разрешения конфликта.--output=<file>
или-o <file>
, см.meld --help
Включено 4 файла:
$LOCAL
Файл в ветке, где вы объединяете; не тронут процесс слияния при показе вам$REMOTE
Файл на ветке, из которой вы сливаетесь; не тронут процесс слияния при показе вам$BASE
Общий предок $ LOCAL и $ REMOTE, т.е. точка, в которой две ветви начали отклонять рассматриваемый файл; не тронут процесс слияния при показе вам$MERGED
Частично объединенный файл с конфликтами; это единственный файл, затронутый процессом слияния и, фактически, никогда не показанный вам вmeld
$MERGED
Файл является тот , который содержит<<<<<<
,>>>>>>
,=====
(и, может быть,||||||
) маркер (которые отграничивают конфликты). Это файл, который вы редактируете вручную, чтобы исправить конфликты.Ручное редактирование конфликтов и визуальное редактирование конфликтов выполняются для разных файлов и содержат различную информацию.
При использовании mergetool (предположим
meld
), файлы, которые видят в нем являются:$LOCAL
,$BASE
,$REMOTE
. Обратите внимание, что вы не видите$MERGED
файл, хотя он передается как скрытый параметр,meld
чтобы записать в него результат редактирования.Другими словами,
meld
вы редактируете файл посередине,$BASE
файл и выбираете все изменения слева или справа вручную . Это чистый файл, не затронутый процессом слияния. Единственный сбой в том, что при сохранении вы сохраняете не$BASE
файл, а четвертый скрытый параметрmeld
-$MERGED
файл (который вы даже не видите).$BASE
Файла не не содержит каких - либо конфликтов или частичное успешных слияний , потому что это не$MERGED
файл .При визуальном редактировании при представлении вам
$BASE
файл (а не$MERGED
файл) вgit
основном отбрасывает все его попытки выполнить слияние (эти попытки видны, если хотите, в файле $ MERGED) и позволяет вам полностью выполнить слияние с нуля .Суть в том, что при конфликтах с ручным и визуальным слиянием вы не смотрите на одни и те же файлы, но конечный результат записывается в одном и том же файле (то есть
$MERGED
файле).Ручная коррекция конфликтов делается на
$MERGED
потому , чтоgit
не имеет среднего представить вам три файла, поэтому он давит информацию из трех файлов ($LOCAL
,$BASE
,$REMOTE
) в этом$MERGED
файле.Но визуальные инструменты имеют средства , чтобы показать вам три файла: они показывают вам
$LOCAL
,$BASE
,$REMOTE
файлы. Вы выбираете изменения от$LOCAL
и$REMOTE
файлов , и вы приносите те в$BASE
файл, полностью заново строить и даже перезапись неудачной попытки слияния , что является$MERGED
файлом.источник
$LOCAL
,$REMOTE
,$BASE
а выход первоначально составит$BASE
, но отличаются от$MERGED
тем , что он не попытался GIT, чтобы объединить файлы и маркер конфликтов и так далее. Фактически, это был бы способ использовать эти инструменты, который наиболее похож на трехпанельный подход LOCAL / REMOTE / BASE + OUTPUT, который не показывает объединение. 4-я панель позволяет вам отделить базу от выходных данных.Решение Cosmin работает, но файл $ BASE обновляется, а не $ MERGED . Это обновит файл $ MERGED :
Meld:
v1.8.4
источник
cmd = meld --auto-merge --output $MERGED $LOCAL $BASE $REMOTE
--diff $BASE $LOCAL --diff $BASE $REMOTE
в конце? для меня на 1.8.4 это нормально работает (насколько я вижу):cmd = meld --auto-merge --output $MERGED $LOCAL $BASE $REMOTE
С Meld 1.7 решение Томека Бери больше не работает.
Настройки по умолчанию меня не удовлетворяли:
Вместо Meld> = 1,7 я предлагаю одно из двух других решений.
Первое решение :
Второе решение :
.gitconfig
Скопируйте и вставьте это в свой
.gitconfig
файл, чтобы получить решения, как описано выше:Скопируйте и вставьте это в
.gitconfig.local
файл, чтобы установить meld17 или meld16 только для этой машины, если вы используете .gitconfig на нескольких машинах:источник
cmd = meld $LOCAL $BASE $REMOTE --auto-merge
, средней панелью будет $ BASE, а не $ MERGE, который фактически используется в качестве результата разрешения конфликта.Я обнаружил, что ни один из файлов по умолчанию не был сохранен. MELD показывал
$LOCAL
,$REMOTE
и$BASE
по умолчанию. Чтобы это сработало, мне нужно было сделать$MERGED
вместо этого шоу-шоу$BASE
. Положив это в моем~/.gitconfig
исправил это для меня:Я использую Arch, с:
источник
По какой-то причине в последних версиях meld не отображаются строки маркеров, добавленные для конфликтов (<<<<<<<, =======, >>>>>>>). Если вы хотите увидеть эти строки, вам следует установить meld v 1.3.3 или более раннюю версию.
источник
Пожалуйста, смотрите ответ Саада для правильного ответа.
С Meld 1.8.1 на Ubuntu я получал
и добавив --output до того, как $ MERGED исправил это для меня:
источник