Какой контроль версий поддерживает слияние в нескольких выпусках?

Question

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

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

Если у вас есть ответ, я хотел бы услышать, насколько масштабным был проект, в котором вы его применили, и какой у вас был опыт. Я ищу систему, которая явно поддерживает слияние разработчиком - решения со скриптами, применяемыми менеджеры по сборке и т.д. нам не помогут. (Слишком опасно; слияние должно быть сделано разработчиком немедленно, так как он / она знает лучше, что делать.) Большое спасибо!

Answer 1

Я думаю, что большинство, если не все, современные СКМ могут сделать это. Не обязательно автоматически, хотя некоторые сценарии могут справиться с этим совершенно безболезненно.

На работе мы используем Perforce и выполняем интеграцию вручную (помогает сценарий Perl для копирования информации из списка изменений). Мы тщательно выбираем, какие списки изменений будут выпущены (например, мы можем отказаться от рискованных).
Для большинства распределенных VCS (Mercurial, Bazaar, возможно Git и т. Д.) Работа с несколькими ветвями (или клонами) является естественным рабочим процессом.

Answer 2

По моему опыту, слияние с Subversion работает, но довольно болезненно (хотя я слышал, что новые версии лучше в этом отношении). Git и Mercurial правильно сливаются без проблем.

Answer 3

Ответ на этот вопрос один из первых процессов и второй цепочки инструментов.

Вам необходимо решить, как вы хотите получить доступ к известным версиям (например, «что в работе?»), Как вы хотите внести изменения в них и как вы хотите распространять изменения в других версиях.

Большинство систем VCS, которые являются Subversion-Or-Better, будут поддерживать общие рабочие процессы. Вот тот, который является общим:

1. Разработка идет по стволу
2. Когда придет время выпуска, пометьте ствол, например, 1.3.0
3. Создайте ответвление от ствола на теге, который вы сделали, например. 1.3.x
4. Освободить код на основе тега (например, 1.3.0)
5. Возобновить разработку новых функций на стволе
6. Если вам нужно исправить ошибку в работе, проверьте ветку и исправьте ее. Отпустите это как обычно, создав новый тег (например, 1.3.1).
7. Слияние изменений из вашей ветви обратно в ствол по мере необходимости
8. Повторяйте шаги 6 и 7 по мере необходимости до следующего выпуска.

Вот еще одна распространенная практика:

1. Разработка идет по стволу
2. Когда наступит время релиза, пометьте ствол
3. Выпуск в производство на основе тега (например, 1.3.0)
4. Если обнаружена ошибка, создайте ветку, чтобы исправить эту ошибку с тегом
5. Фиксация в новой ветви и повторная пометка (например, 1.3.1)
6. Слить эту ветвь обратно в ствол
7. Повторите шаги 4, 5 и 6 каждый раз, когда вы обнаружите ошибку

Они очень распространены и просты в реализации / понимании; они легко поддерживаются большинством систем контроля версий. Если вы получаете более сложные процессы, вы уменьшите доступный набор инструментов, но, возможно, будете иметь больше возможностей.

Answer 4

Если вы действительно хотите работать с несколькими выпусками, но не испытываете боли Clearcase, вам следует попробовать что-то вроде Accurev или PlasticSCM .

Accurev очень силен, имея дело со своими потоками, к ним нужно привыкнуть, но как только вы это сделаете, он очень, очень мощный.

Пластик является более мощным с точки зрения обработки неограниченного количества ветвей (и их соответствующих слияний), что легче сказать, чем сделать. У вас есть все гибкость, упомянутая для хорошего старого CC, но без тайных команд или странных конфигураций.

Здесь у вас есть менеджер веток, который отслеживает несколько веток

Answer 5

Team Foundation Server поддерживает любое количество веток с объединением. Это довольно хорошо, но функции версии 2010 делают ветвление еще более привлекательным. См. 10-4 Эпизод 4: Больше нет боли при параллельном развитии .

Answer 6

Clearcase будет обрабатывать несколько веток и ревизий, а также объединять любые / все из них. Вы можете определить ветви по желанию, помеченные как вы хотите, и объединить их. Излишне говорить, что это может усложнить чрезвычайно , и IBM предоставит вам менеджер слияния , чтобы помочь вам. Вы можете отобразить ветви графически (если это поможет).

Clearcase невероятно мощный, но, соответственно, сложный и трудоемкий в управлении.

Answer 7

Можно настроить Telelogic CM Synergy / CM для поддержки такой настройки.

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

Недостатки в том, что он действительно большой и медленный, требует много времени для компоновщика, а интеграция с Eclipse практически непригодна. Вам, вероятно, понадобится полный менеджер сборки каждые 5 или 10 разработчиков.