Какой инструмент контроля версий лучше всего подходит для рефлексивного или циклического объединения? SVN, Git?

Question

Отражающее / Циклическое Объединение

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

Более подробную информацию см. В статье о реинтеграции Subversion merge по номеру http://blogs.open.collab.net/svn/2008/07/subversion-merg.html Вы также можете обратиться к http://jugalps.wordpress.com/2009/07/31/svn-branching-and-merging-in-scrum/, чтобы получить представление о типичном отражающем процессе слияния. Мой личный опыт работы с SVN недостаточно хорош при работе с такими сценариями.

Есть ли у кого-нибудь опыт работы с любым другим инструментом контроля версий, кроме SVN, для отражения слияния?

Answer 1

Git всегда разрабатывался с учетом этой способности. Это был мой первый VCS, и для меня этот тип рабочего процесса является полностью рутинным. Как правило, объединение (push или запрашиваемое pull) обратно в начало координат («trunk») тривиально, поскольку, регулярно объединяясь из origin, вы гарантируете, что ваш HEAD (наконечник ветви) имеет HEAD источника в своем прошлом, поэтому при объединяет вашу работу, она просто должна двигаться вперед по истории, а не фактически выполнять слияние (git называет это «быстрой перемоткой вперед»).

Способность Git к перебазировке также может быть использована, чтобы сделать историю еще красивее. Если вы примете этот рабочий процесс, вы всегда можете перебазировать свою работу поверх того, что вы извлекаете из источника, а не объединять их. (Это переписывает историю, поэтому вы должны быть уверены, что не будете делать это с тем, что уже опубликовано). Таким образом, все ваши слияния из источника быстро продвигаются вперед, и ваша работа - это просто последовательность коммитов поверх HEAD исходного происхождения. Это делает историю более прямой - возможно, прямой линией, а не серией слияний.

Answer 2

Я недавно перевел все свои новые проекты с SVN на git. Все, что я могу сказать, это ветвление и слияние намного проще.

Ветви настолько просты в создании и управлении, что практически каждый день разработки получают новую ветку, где я фиксирую свою локальную ветвь, а затем объединяюсь, когда я закончу. Я работаю с небольшой группой, и у нас не было проблем с такой работой.

Answer 3

Продукт IBM Rational ClearCase имеет основную поддержку именно этого режима работы - это стандартный способ работы с ветвями разработки, и объединение происходит в значительной степени автоматически в обоих направлениях (если, конечно, нет противоречивых изменений). Однако остальная часть инфраструктуры, необходимой для ClearCase, вероятно, означает, что вы будете использовать ее только в том случае, если ваша компания примет важное инвестиционное решение.

Answer 4

Как вы сказали, рефлексивное слияние с SVN раньше было кошмаром, но в последней версии серии svn 1.6.x эта функция широко поддерживается (теперь слияния сохраняют метаданные, относящиеся к слиянию в истории, что помогает при объединении изменений).

В настоящее время я использую Bazaar в качестве системы VC (это распределенная VCS, как Git), и я могу сказать, что она имеет больше поддержки для ветвления и повторного образования / слияния ответвлений в основную линию. Также Git поддерживает это (rebase), оба разработаны с учетом ветвления / слияния.

Answer 5

Subversion, более или менее значительный багфикс для CVS, имеет те же проблемы с объединением, что и CVS. Оба были разработаны для действительно простых случаев слияния, а не того, что мы используем сегодня (сотни людей работают над одной и той же кодовой базой, каждая из которых имеет немного отличную версию).

Git и другие современные DVCS были разработаны для решения этой проблемы (плюс часть распределенной VCS). Git поставляется с множеством различных алгоритмов слияния, и легко создать новый. Но я думаю, что было бы трудно придумать сценарий, которого разработчики ядра Linux еще не видели;)

Из моего личного опыта, Git - хороший инструмент, если вы забываете больше всего, что вы знаете о SVN. В противном случае, вы попытаетесь применить свои знания SVN / CVS, и это просто не будет работать. Сядьте, поработайте над учебниками и по-настоящему начните работать так, как будто вы никогда раньше не видели VCS. Например, я попытался поместить несколько проектов в один репозиторий.