Каковы преимущества Mercurial или Git над SVN для ветвления / слияния?

Question

Я слышал, например, что объединение веток с помощью git или mercurial проще, чем с svn.

Читая последнюю запись Джоэла в блоге о программном обеспечении, я не понял, почему. Не могли бы вы предоставить конкретный пример , где слияние с git / mercurial приводит к меньшему количеству конфликтов слияния по сравнению с svn, пожалуйста?

Answer 1

Один простой пример - git может автоматически конвертировать слияние в «ускоренную перемотку вперед». Например, допустим, у меня есть ветка, которая выглядит так:

Мастер:

A ---> B ---> C

И я создаю ветку объектов на основе Master с новыми коммитами D и E.

Характеристика:

A --- > B ---> C
                \
                 D ---> E

В svn, когда вы объединяете ветвь функций обратно в master, вы должны создать совершенно новый коммит, который применяет изменения D и E в Master. Итак, это выглядит так:

Master:
    A ---> B ---> C -----------------> F
Feature:           \                  /
                    ---> D ---> E -->

В git у нас есть выбор, как включить функцию ветвления в master. Если мы сделаем

git rebase feature

git автоматически распознает, что это тривиальное слияние, и выполнит ускоренное слияние, которое добавит новые коммиты в основную ветвь. Результат перебазирования:

Мастер:

A ---> B ---> C ---> D ---> E

Голова Мастера и Особенность указывают на коммит E (другими словами, они выглядят совершенно одинаково). Быстрое слияние аналогично тому, что происходит при обновлении в SVN.

Кроме того, у вас есть возможность заставить git создать коммит слияния. Если вместо этого мы делаем:

git merge feature

git создаст коммит слияния. Результат слияния:

Master:
    A ---> B ---> C -----------------> F
Feature:           \                  /
                    ---> D ---> E -->

Commit F - это комбинация D и E.

Answer 2

Check HGINIT out. Это статья / учебник Джоэла Спольски (не его последняя запись в блоге) на эту тему. Вы можете найти особенно интересной часть Subversion Re-Education .

Answer 3

Subversion удобно реализует только одну концепцию - ветви страха. Это означает, что одна ветвь всегда равна parent, а другая - feature. Функция может извлекать обновления у родителя с течением времени (слияние), но родитель может извлекать изменения функции только один раз (слияние - реинтегрировать), и тогда дочерний элемент должен быть закрыт. Этого достаточно во многих случаях, но не всегда. Не все ветви являются функциональными. У меня есть пара примеров.

1. Во-первых. Хороший пример - release branch. Предположим, вы готовите релиз на основе тщательно протестированной версии ствола. Вы делаете ветку релиза из желаемой версии ствола. Теперь на вас не влияют никакие последующие модификации ствола. Но вы можете захотеть зафиксировать исправления в ветке релиза, и вы можете захотеть перенести их в магистраль, не закрывая ветку релиза. Это не может быть реализовано с помощью ветвей функций svn. С svn вам придется подождать, пока ветка релиза больше не понадобится, а затем реинтегрировать ее. Или вручную скопировать исправления.
2. Во-вторых. Отраслевые или разработчики. У вас нет готового примера того, когда они действительно полезны, но вам точно не понравится их в SVN. Синхронизировать такие ветви будет больно.