Как получить общего предка конфликтующего файла с помощью git

Я объединил 2 ветки и получил конфликты. Один из них просто беспорядок, потому что он был сильно рефакторен на одной ветке (B1). Однако я ожидаю, что другая ветвь (B2) будет содержать простое изменение, которое, к сожалению, затронуло многие строки.

Поэтому я думаю, что самый простой способ выполнить слияние — сохранить B1 и повторно внести изменения, сделанные в B2. Но я хочу быть уверенным в том, что это за изменения на B2, прежде чем начинать, чтобы быть уверенным, что ничего не забуду.

To do so,

  • Я хочу знать последнюю фиксацию общего предка для этого файла между двумя ветвями.
  • в идеале я хотел бы сделать это в моей текущей ситуации «конфликтующего слияния» без необходимости проверки

git git-merge-conflict
person Juh_    schedule 22.05.2018    source источник

Ответы (2)


arrow_upward
4
arrow_downward

Обратите внимание, что пока вы выполняете ручное слияние конфликтующего файла file.ext, все три версии этого файла хранятся в индексной / промежуточной области в трех слотах, зарезервированных для этого случая. Они пронумерованы:

  • слот 1 содержит базовую версию;
  • слот 2 содержит версию --ours из коммита HEAD;
  • слот 3 содержит версию --theirs из другого коммита.

В то время как git checkout имеет --ours и --theirs для извлечения этих двух версий, отсутствует опция для базовой версии. Однако git show можно использовать для извлечения всех трех версий:

git show :1:file.ext > file.ext.base
git show :2:file.ext > file.ext.ours
git show :3:file.ext > file.ext.theirs

например.

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

person torek    schedule 22.05.2018
comment
интересно, спс за информацию. Однако здесь мне действительно нужно сравнить theirs с base (желательно во всем файле), потому что изменения не могут быть применены к рефакторингу ours. - person Juh_; 22.05.2018
comment
Если вы извлечете все три, как в приведенных выше командах git show, вы можете сравнить варианты .base и .ours (с git diff, если хотите; добавьте --no-index, если вы поместили оба файла за пределы рабочего дерева, например, в /tmp ). - person torek; 22.05.2018
comment
изучая эту систему слотов, я нашел еще один ваш ответ, который дает более подробную информацию. Я делюсь им с другими заинтересованными людьми: stackoverflow.com/a/21311271/1206998 - person Juh_; 25.05.2018
comment
ты спасатель жизни братан. никогда не получалось получить БАЗУ без этого - person Amin; 09.10.2018
comment
@Amin: рассмотрите возможность установки merge.conflictstyle на diff3: Git включит строки из базы слияния в конфликтующую версию рабочего дерева. - person torek; 09.10.2018

arrow_upward
0
arrow_downward

Я просто вспомнил это:

git merge-base B1 B2

дайте общего предка ветвей B1 и B2. Это для целых веток. Но никакие последующие изменения не применяются ни к одному файлу в обеих ветвях.

Затем, чтобы увидеть разницу, просто

git diff common_ancestor..B2 path/to/the/file

где common_ancestor — коммит, полученный с помощью git merge-base

person Juh_    schedule 22.05.2018