Яка версія файлу git буде нарешті використана: LOCAL, BASE або REMOTE?


174

Коли протягом колись колись колись git merge, я відкриваю mergetool під назвою Meld . Він відкриває три файли LOCAL, BASE та REMOTE. Як я читав LOCAL - це моя місцева гілка, BASE є загальним предком, а REMOTE - гілка, яку потрібно об'єднати.

Тепер до мого питання: яка версія файлу буде нарешті використана? Це ВИДАЛЕНО? Якщо так, чи можу я редагувати його так, як я хочу, незалежно від того, що, наприклад, у відділенні BASE?

Відповіді:


142

Це один в середині: BASE.

Насправді BASEце не спільний пращур, а напівфабрикатне злиття, де конфлікти позначені >>>>і <<<<.

Імена файлів можна побачити у верхній частині вікна редагування форми.

Дивіться скріншот тут

основа основи

Ви можете редагувати BASEфайл за бажанням за допомогою команд meld або без них.
Ви також можете позбутися meld і просто відредагувати файл улюбленим текстовим редактором.

  • Код між <<<< HEADта =====маркерами є вашим локальним файлом до об'єднання.
  • Код між ====та >>>> <branch name>є одним із віддалених файлів.

3
Деякі люди краще розуміють конфліктуючі фрагменти у файлі, який не вдався до автоматичного об'єднання, якщо їм встановлено параметр merge.conflictstyleконфігурації diff3замість типового merge.
kostix

3
Я фактично не бачу ГОЛОВИ, <<< і === співає. У випадку, якщо ви вказали, середнє вікно буде порожнім. Але це лише примітка для інших, thx для вашої відповіді.
цусанка

Якщо ви не бачите HEAD, <<<<<і =====ознаки, то це означає , що не існує ніякого конфлікту взагалі. У цьому випадку середнє вікно не буде порожнім, воно покаже результат злиття, але "червоної" частини не буде
Fabien Quatravaux

10
Коли я роблю злиття з Meld, я не бачу ані маркерів <<<<<<, ======ані >>>>>>маркерів на середній панелі (тобто версії BASE); а іноді, середня панель буде порожньою, як повідомлялося з aGr. Можливо, ця різниця пов’язана з різними налаштуваннями. Коли я починаю інструмент зливатися, такі файли будуть існувати, якщо припустити , що ім'я файлу в сховище є X.java: X.java, X.java.orig, X.java.BACKUP.#, X.java.BASE.#, X.java.LOCAL.#, X.java.REMOTE.#, де #певна кількість. Викликати результат злиття версія BASE є заплутаною; МЕРГЕДЕ б краще.
Teemu Leisti

3
BASE насправді є загальним предком, MERGED - це ім'я файлу з частковою інформацією про злиття в ньому. Будь ласка, дивіться моє запитання та відповідь Налаштування та використання Meld як вашої git difftool та mergetool, яка пояснює, як саме це працює. HTH.
матст

107

У Meld є прихована функція тристороннього злиття, активована при переході в четвертий параметр:

meld $LOCAL $BASE $REMOTE $MERGED

Права і ліва панелі відкриваються в режимі лише для читання, тому ви не можете випадково об'єднати неправильний шлях. Середня панель показує результат злиття. Для конфліктів він показує базову версію, щоб ви могли бачити всі важливі біти: оригінальний текст посередині та суперечливі модифікації з обох сторін. Нарешті, при натисканні кнопки "Зберегти" записується файл $ MERGED - точно так, як очікується git.

Файл ~ / .gitconfig, який я використовую, містить такі налаштування:

[merge]
tool = mymeld
conflictstyle = diff3
[mergetool "mymeld"]
cmd = meld --diff $BASE $LOCAL --diff $BASE $REMOTE --diff $LOCAL $BASE $REMOTE $MERGED

це відкриває поле з 3 вкладками, 1-а та 2-а вкладки, що містять прості розрізки, які я намагаюся об'єднати, а 3-я вкладку, відкриту за замовчуванням, показує 3-х напрямок злиття.

Тепер, причина, яка є прихованою, полягає в тому, що вона ще недостатньо відшліфована. Це дуже корисно, як зараз, але Кай Вілладсен, автор форми, вказала на кілька зморшок, які потребують прасування. Наприклад, немає графічного інтерфейсу для запуску тристороннього режиму злиття, синтаксис командного рядка є трохи прихованим, і таке. Якщо ви говорите пітон і маєте трохи часу на руках - знаєте, що робити.

Редагувати: У нових версіях Meld синакс незначно змінився. Це було в коментарях, але це належить до відповіді.

Команда meld тепер використовує параметр --output, тому останній рядок із фрагмента, наведеного вище, повинен бути:

cmd = meld --diff $BASE $LOCAL --diff $BASE $REMOTE --diff $LOCAL $BASE $REMOTE --output $MERGED

7
@Jesse, @lumbric, виявляється, що новіші версії meld використовують прапор --outputдля результату $ MERGED. Я виявив це, дивлячись на сценарій запуску meld, який постачався з моєю версією git: github.com/git/git/blob/master/mergetools/meld
Йоганн

1
@lumbric Я вважаю, що це робить для Meld 1.7.x + з --output option. Дивіться цей рядок у сценарії запуску:"$merge_tool_path" --output "$MERGED" "$LOCAL" "$BASE" "$REMOTE"
Йоганн

12
В останньому meld (версія> 1.8.4) ми повинні використовувати --auto-merge option. cmd = meld --diff $ BASE $ LOCAL --diff $ BASE $ REMOTE --auto-merge $ LOCAL $ BASE $ REMOTE --output $
MERGED

7
У мене була така ж проблема, як і @pingpongboss за допомогою Meld 1.8.4: Meld відкривав речі на окремій панелі, а не на 3-й вкладці. Команда остаточно працював штраф: cmd = meld $LOCAL $BASE $REMOTE --auto-merge --output $MERGED. Отже, це відкриває 3 вкладки (старий добрий спосіб), автоматично об'єднує безконфліктні злиття в середину, де середина - $ MERGED, і буде використовуватися як вихідний спосіб вирішення конфлікту.
farmir

2
Синтаксис для виводу може бути --output=<file>або -o <file>, див.meld --help
levsa

57

Задіяно 4 файли:

  1. $LOCALФайл на гілці, де ви зливаєтеся; недоторканий процесом злиття, коли вам показано

  2. $REMOTEФайл на гілці, з якої ви зливаєтеся; недоторканий процесом злиття, коли вам показано

  3. $BASEСпільний пращур $ LOCAL і $ REMOTE, тобто. точка, коли дві гілки почали переадресовувати розглянутий файл; недоторканий процесом злиття, коли вам показано

  4. $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файлом.


Я просто хотів, щоб були інструменти (наприклад, поза порівнянням), які показують усі 4 файли
yoniLavi

@yoniYalovitsky: так, або p4merge
користувач1284631

Раніше я використовував інструмент злиття з пакету ClearCase
mishmashru

@yoniLavi - ну ці інструменти показують 4 панелей , але не обов'язково всі чотири файли , як описано в цій відповіді. Зокрема, ви можете налаштувати ці 4-панель інструментів , щоб показати вам $LOCAL, $REMOTE, $BASEа вихід спочатку складе $BASE, але відрізняються від $MERGEDтих , що він не спробував GIT, щоб об'єднати файли і маркер конфліктів і так далі. Насправді це був би спосіб використання цих інструментів, найбільш схожий на 3-панельний підхід LOCAL / REMOTE / BASE + OUTPUT, який не відображається об'єднаним. 4-та панель просто дозволяє відокремити базу від виводу.
BeeOnRope

16

Рішення Cosmin працює, але файл $ BASE оновлюється - не $ MERGED . Це оновить файл $ MERGED :

Meld: v1.8.4

[merge]
  conflictstyle = diff3
  tool = mymeld
[mergetool "mymeld"]
  cmd = meld --auto-merge --output $MERGED $LOCAL $BASE $REMOTE --diff $BASE $LOCAL --diff $BASE $REMOTE

Я можу це підтвердити. Рішення Saad працює для мене на Ubuntu. Що стосується початкового запитання, це справжня правильна відповідь.
космон

3
У моїй версії meld - 3.11, ця команда чудово працює:cmd = meld --auto-merge --output $MERGED $LOCAL $BASE $REMOTE
MartinM

навіщо вам потрібно --diff $BASE $LOCAL --diff $BASE $REMOTEв кінці? для мене на 1.8.4 це добре працює (наскільки я бачу):cmd = meld --auto-merge --output $MERGED $LOCAL $BASE $REMOTE
farmir

1
@farmir: Це не потрібно. Він відкриває ще два вкладки в meld, щоб ви могли бачити LOCAL і REMOTE порівняно з BASE окремо.
Сем Кауффман

1
Незалежно від того, який порядок я намагаюся з цими аргументами, тристороння вкладка - це завжди третя вкладка, тоді як перша вкладка завжди вибрана за замовчуванням. Чи є спосіб зробити тристоронній вкладку вибраною за замовчуванням?
Сем Кауффман

13

З Meld 1.7 рішення Томека Бері вже не працює.

Налаштування за замовчуванням мене не задовольнили:

Налаштування за замовчуванням

Замість Meld> = 1.7 я пропоную одне з двох інших рішень.

Перше рішення :

 meld $LOCAL $BASE $REMOTE --auto-merge

перше рішення

Друге рішення :

 meld $LOCAL $MERGED $REMOTE

друге рішення

.gitconfig

Скопіюйте та вставте це у свій .gitconfigфайл, щоб отримати рішення, як описано вище:

[merge]
    tool = meld16
[mergetool "meld17"]
    # use this for Meld >=1.7
    # see http://stackoverflow.com/a/22911793/859591
    # second solution:
    cmd = meld $LOCAL $MERGED $REMOTE
    # first solution:
    #cmd = meld $LOCAL $BASE $REMOTE --auto-merge
[mergetool "meld16"]
    cmd = meld --diff $BASE $LOCAL --diff $BASE $REMOTE --diff $LOCAL $BASE $REMOTE --output $MERGED

[include]
    # requires git v1.7.10+
    path = .gitconfig.local

Скопіюйте та вставте це у .gitconfig.localфайл, щоб встановити meld17 або meld16 лише для цієї машини, якщо ви використовуєте .gitconfig на кількох машинах:

# This is a host specific config file!
# Note that git 1.7.10+ is needed
# http://stackoverflow.com/a/9733277/859591
[merge]
    tool = meld17

Це не працює на Meld 1.8.4. Якщо запустити cmd = meld $LOCAL $BASE $REMOTE --auto-merge, середньою панеллю буде $ BASE, а не $ MERGE, який фактично використовується як результат вирішення конфлікту.
farmir

1
@farmir Ви вибрали $ BASE як другу вкладку.
Alex78191

11

Я виявив, що жоден із показаних файлів за замовчуванням не зберігається. meld показував $LOCAL, $REMOTEі $BASEза замовчуванням. Для того, щоб це працювало, мені потрібно було зробити мельд-шоу $MERGEDзамість $BASE. Помістивши це в мій ~/.gitconfigвиправлений для мене:

[merge]
        tool = mymeld
[mergetool "mymeld"]
        cmd = meld "$LOCAL" "$MERGED" "$REMOTE"

Я використовую Arch, з:

$ git --version
git version 1.8.2
$ meld --version
meld 1.7.1

Вибачте, чи сумісна ця конфігурація inux?
MadMad666

2

Чомусь новітні версії meld не відображають маркерні лінії, додані для конфліктів (<<<<<<<, =======, >>>>>>>). Якщо ви хочете побачити ці рядки, вам слід встановити meld v 1.3.3 або попередній.


Я знайшов корисний відповідь на @lumbric stackoverflow.com/a/22911793/641892
wnasich

2

Для правильної відповіді див. Відповідь Саада.

З моментом 1.8.1 на Ubuntu я отримував

неправильна кількість аргументів, наданих --diff

і додавши вихід - до того, як $ MERGED зафіксував його для мене:

[mergetool "mymeld"]
cmd = meld --diff $BASE $LOCAL --diff $BASE $REMOTE --diff $LOCAL $BASE $REMOTE --output $MERGED
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.