Каковы различия между GIT и SVN, когда дело доходит до решения конфликтов слияния - PullRequest
4 голосов
/ 30 марта 2010

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

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

Ответы [ 2 ]

3 голосов
/ 19 апреля 2010

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

Допустим, проект состоит из этих файлов:

/main.cpp
/sub1/sub1.cpp
/sub1/sub1.h
  1. Создать ветку
  2. В транке переместите sub1. * В корневой каталог, удалите подкаталог sub1.
  3. В ветке внести некоторые изменения в /sub1/sub1.cpp
  4. В транке внести некоторые изменения в /sub1.cpp
  5. Слияние ветки и ствола.

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

2 голосов
/ 30 марта 2010

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

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

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

...