В чем разница между SVN и Git для слияния? - PullRequest
24 голосов
/ 22 апреля 2010

Как следует из названия, мне любопытно, почему так много людей рекламируют Git как превосходную альтернативу ветвлению / слиянию по SVN.Мне в первую очередь любопытно, потому что слияние SVN - отстой, и я хотел бы найти альтернативное решение.

Как Git лучше обрабатывает слияние?Как это работает?

Например, в SVN, если у меня есть следующая строка:

Hello World!

Затем user1 меняет его на:

Hello World! 1

, затем user2 изменяет его на:

Hello World! 12

Затем user2 фиксирует, затем user1 фиксирует, SVN вызовет конфликт.Может ли Git разрешить что-то простое, как это?

Ответы [ 2 ]

28 голосов
/ 22 апреля 2010

Это вызывается при слиянии с конфликтом, и никакие VCS никогда не решат это за вас.
Вам придется самостоятельно решить слияние самостоятельно.

Как упомянуто в Почему слияние в git лучше, чем SVN , фактическая разница в истории записи коммитов:

Это позволяет Git запоминать то, что уже слилось, значительно уменьшая возникновение конфликтов.

DAG

Итак, когда приходит время выполнить слияние с 5b на ветку (a), мы можем использовать информацию в DAG, чтобы знать, что 3b и 2b уже выполнены


Так что это рабочий процесс слияния , который Git будет обрабатывать гораздо более изящно, чем SVN:
См. Слияние Git против SVN для конкретных примеров.

18 голосов
/ 22 апреля 2010

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

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

Преимущество Git в слиянии заключается в том, что это часть истории. Коммит слияния - это коммит с двумя родителями. Модель истории Git (ориентированный ациклический граф) ожидает, что такие коммиты будут такими. Это означает, что дальнейшие слияния в будущем будут работать именно так, как они должны. Всегда. (Да, иногда возникают конфликты, но это реальные конфликты, а не неспособность справиться со слиянием.)

С другой стороны, SVN просто пытается отследить, где произошло слияние, но его модель по-прежнему линейна. История по-прежнему содержит единственную строку коммитов, а информация отслеживания слияний предоставляет дополнительную помощь. Из того, что я слышал, SVN не всегда может правильно обрабатывать более сложные шаблоны слияния. (Одним из примеров является рефлексивное слияние - слияние A в B, а затем B в A).

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