Каковы различия между GIT и SVN, когда речь идет о слиянии конфликтов

Я продолжаю слышать, что ветвление в git намного проще, чем в SVN, потому что проще объединить ветку обратно в магистраль/мастер. Я прочитал несколько руководств, но они охватывали только основные конфликты слияния ( "Алиса изменила строку 8 кода .cpp и в то же время Боб изменил строку 8 кода .cpp..." ), и нет никаких различий между SVN и все другие системы управления распределенными источниками.

Можете ли вы привести примеры изменений в ветке, которые могут вызвать проблемы в репозитории SVN, но будут обработаны изящно git?

Ответ 1

У меня наконец-то было время, чтобы возиться с ветвями/слиянием с git и svn и нашел случай, который убивает svn, но отлично работает с git:

Предположим, что проект состоит из этих файлов:

/main.cpp
/sub1/sub1.cpp
/sub1/sub1.h

Создать ветку
В trunk, переместите sub1. * в корневой каталог, удалите подкаталог sub1.
В ветке внести некоторые изменения в /sub 1/sub1.cpp
В trunk внести некоторые изменения в /sub 1.cpp
Объединить ветку и соединительную линию.

SVN теряет все изменения, сделанные в ветке в точке 3, аналогичные изменения в git отлично сливаются. Этого достаточно для того, чтобы я отклонил SVN как систему контроля версий для любого проекта, который требует разветвления.

Ответ 2

hgInit.com относится к Mercurial, но даст вам очень хороший обзор разницы между DVCS и SVN для слияния конфликтов.

Причина, по которой Subversion имеет проблемы слияние связано с тем, как это происходит хранит историю версий. диверсия любит думать об изменениях. ревизия - это то, что весь файл система выглядела как момент времени. В Mercurial вы думаете о наборах изменений. Набор изменений - это краткий перечень изменений между одна ревизия и следующая ревизия.

Итак, Subversion сравнивает целые файлы при слиянии, в то время как Mercurial (или Git) сравнивает каждый набор изменений по отдельности. Конфликты встречаются гораздо реже при работе с наборами изменений.