Можно ли пересмотреть разрешение конфликта слияния в git? - PullRequest
Новая
       97

Можно ли пересмотреть разрешение конфликта слияния в git?

0 голосов
/ 14 февраля 2020

Я работаю над файлом tex вместе с соавтором, используя git (используя gitkraken). Мы работаем над одной и той же веткой, и в какой-то момент возникли конфликты слияния, когда один из нас перенес нашу последнюю работу в эту ветку. С тех пор мы продолжили работу над этим файлом, но мы поняли, что хотели бы «повторить» разрешение конфликтов слияния из пары коммитов назад.

Есть ли чистый способ сделать это?

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

Этот последний параметр лучшее, что я мог придумать. Есть ли лучший способ?

1 Ответ

3 голосов
/ 15 февраля 2020

Каждый коммит, включая коммиты слияния, просто хранит полный и полный снимок всех ваших файлов.

Когда вы сотрудничаете с другими людьми, это обычно не стоит много усилия для go возврата и «исправления» предыдущих коммитов. На самом деле это технически невозможно: вы не можете изменить какие-либо существующие коммиты. То, что вы в конечном итоге делаете, - это предоставление новых и улучшенных альтернативных коммитов вместо оригиналов. Например, предположим: 

...--I--J
         \
          M--N--O   <-- branch (HEAD)
         /
...--K--L

- это текущая ситуация, то есть существующие коммиты до J и до L объединены в M, и вы и они с тех пор построили N и O поверх M. Теперь вы обнаруживаете, что есть «ошибка» в снимке, сохраненном в коммите слияния M из-за неправильного разрешения конфликтов.

Единственный способ сделать исправленную версию M - это сделать новый коммит слияния, M'. (Есть несколько способов сделать это.) Результат: 

...--I--J__
        |  \
        |   M--N--O   <-- branch
         \ /
          x
         / \
...--K--L---M'  <-- newbranch (HEAD)

То есть, плохое слияние M все еще существует , даже если вы сделали новые и улучшенные объединить M' в этой новой ветви замены newbranch. Теперь вам нужно также скопировать N и O в новые и улучшенные N' и O': 

...--I--J__
        |  \
        |   M--N--O   <-- branch
         \ /
          x
         / \
...--K--L---M'-N'-O'  <-- newbranch (HEAD)

Теперь вам нужно, чтобы все - вы и все остальные - прекратите использовать старую цепочку M-N-O, найденную по имени branch, и начните использовать вместо нее new цепочку M'-N'-O'. В your Git вы можете стереть имя branch и переименовать newbranch в branch. В их Git им придется делать то же самое. Каждый должен переодеться одновременно. Это, как правило, много работы.

Обычно лучше просто признать, что в прошлом есть ошибка. Сделайте новый коммит поверх O, который решит проблему: 

...--I--J
         \
          M--N--O--P   <-- branch (HEAD)
         /
...--K--L

Каждый может получить новый коммит P как обычно и просто продолжать работать как обычно. Конечно, коммиты M-N-O имеют плохие снимки ... ну и что? Плохие вещи случаются постоянно; управление версиями - это не предотвращение плохих вещей, а скорее разрешение вам исправить это Вы исправили это.

...