Когда слияние не удастся? - PullRequest
0 голосов
/ 24 июня 2011

Я уже некоторое время использую SCM (SVN, Git), и их надежность слияния всегда была загадочной. Иногда автоматические слияния работают, а иногда нет. Существуют ли общие правила относительно того, что будет автоматически объединяться, а что нет?

Ответы [ 3 ]

1 голос
/ 24 июня 2011

По существу, слияние завершится неудачей, когда редактируется строка, которая была также отредактирована кем-то другим, или они редактировали смежную строку.Git немного лучше, чем Subversion для разрешения конфликтов слияния.Чтобы избежать конфликтов, фиксируйте как можно чаще (для каждого атомарного изменения, которое вы вносите в источник, идеально).

Также см. Разрешение конфликта слияния

1 голос
/ 24 июня 2011

В целом, слияние будет автоматически выполнено, если SCM сам сможет выяснить, как создать новую версию, содержащую все изменения из всех веток, которые вы объединяете, или, по крайней мере, если он думает, что может это понять.out.

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

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

Итак, что насчет текстовых файлов?Здесь у СКМ есть алгоритмы объединения изменений.Они обычно рассматривают линии как основные рабочие единицы.Говоря немного упрощенно, слияние будет успешным, если строки изменились в первой, а вторая ветвь не перекрывается.Он потерпит неудачу, если они это сделают, то есть, если в обеих ветвях были изменены одинаковые строки (или смежные строки)Как я уже сказал, правда немного сложнее, но это нужно сделать, чтобы получить общее представление.

Наконец, вы также должны знать, что автоматическое объединение может быть неправильным, даже если оно успешно выполнено без проблем.Например, рассмотрим предложение «Git can merge» как данные в вашем хранилище.Теперь ветвь A меняет его на «Git can bisect», а ветвь B меняет его на «CVS can merge».Эти два изменения находятся в разных местах, так что вы можете теоретически объединить их автоматически.Как я сказал выше, большинство SCM не будут, потому что это в одной строке, но это только пример :).Таким образом, объединение двух ветвей приведет к «CVS может разделить», что, очевидно, неправильно.Подобного рода проблемы возникают не очень часто.

1 голос
/ 24 июня 2011

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...