Как мне одновременно работать над версией 1.1 и версией 2.0?

Question

Ситуация: мы вышли из бета-версии, и версия 1.0 была выпущена для нескольких сайтов клиентов. Команда A уже занята работой над версией 1.1, в которой будут добавляться исправления ошибок и улучшения юзабилити, в то время как другая команда работает над версией 2.0 с крупномасштабными изменениями, когда ядро ​​продукта могло быть полностью переработано. Теперь, большинство изменений, внесенных в 1.1, в какой-то момент должны будут перейти в 2.0, а некоторые исправления ошибок, сделанные в ветке 2.0, на самом деле, возможно, придется запланировать на более ранний выпуск. Проблема в том, что, поскольку 2.0 имеет принципиальные отличия, никакие изменения из 1.1 не могут быть объединены без ручного преобразования или наоборот.

Мой вопрос: Каковы наилучшие методы контроля версий, чтобы минимизировать конфликты слияний и дублировать работу в такой ситуации? Как я могу гарантировать, что мои команды будут тратить как можно меньше времени и усилий на решение проблем с контролем версий, при этом предоставляя клиентам регулярные исправления?

Answer 1

Один хороший способ - исправить каждую ошибку в стабильной ветке и объединить стабильную ветку с веткой разработки. Это шаблон Parallel Maintenance / Development Lines , и ключом является раннее и частое слияние. Редкое и позднее объединение означает, что ветка разработки не распознаваема по сравнению со стабильной, или ошибка не может повторяться таким же образом.

Subversion включает отслеживание слияния начиная с версии 1.5, поэтому вы гарантируете, что один и тот же набор изменений не будет объединен дважды, что приведет к глупым конфликтам. Существуют и другие системы (например, Git , Mercurial , Accurev , Perforce ), которые позволяют создавать запросы типа "что меняется на ветке" А не были объединены в филиал Б? и выберите нужные исправления в ветке разработчика.

Answer 2

В статье здесь (изо дня в день с Subversion) упоминается, что одним из способов является постоянное обновление версии 2 данными из сборки версии 1.1. В статье парень говорит делать это каждый день.

Часть, которую вы хотите прочитать, называется «Официант, в моем сундуке ошибка!». Это примерно на полпути, хотя статья.

Answer 3

В значительной степени то, что говорили все остальные, но я подумал, что могу поделиться своим опытом работы с разработками в нескольких ветках с использованием SVN

.

С нашим основным продуктом нам нужно одновременно разрабатывать в 2+ версиях одновременно.

Первоначально я использовал основной ствол в качестве версии "основной разработки", с тегами, используемыми для каждого фактического выпуска. Ветви были использованы для значительных усилий по разработке нового набора функций. Позже, когда мы начали работать над 2, 3 и 4 выпусками одновременно, я начал использовать ветку для каждой ревизии.

Поскольку я поддерживаю репозиторий, а также обрабатываю push-сборки QA, я каждое утро проверяю, что происходит «свертка», которая состоит из объединения изменений в дереве, начиная с самой низкой в ​​настоящее время активной ветви. Таким образом, я получаю слияние изменений с 1.1 на 1.2, который слился в 1.3 с любыми другими изменениями с 1.2 с момента последнего слияния и т. Д.

Когда я фиксирую, я всегда комментирую коммит что-то вроде

объединено 1,1 рев 5656-5690

Это может быть немного болезненно, но это работает :)

Answer 4

Я бы, вероятно, полагался на систему отслеживания проблем для этой цели, и удостоверился бы в том, чтобы пометить каждое изменение, которое необходимо перенести в код соединительной линии. Затем вы можете убедиться, что комментарии для каждого изменения ссылаются на соответствующую проблему и четко выражают цель изменения кода, чтобы его можно было легко понять при попытке повторной реализации в транке.

Answer 5

Чтобы ответить на этот конкретный вопрос, многие разработчики переключились с Subversion на Git. Оформить заказ github.com.

Answer 6

Одна ключевая точка зафиксирована в на этом снимке из Построенного Доктора: объединить только одно направление.

Answer 7

То, как мы справляемся с этим в моей работе, - это сохранить ветвь ствола как самый передовой код (т. Е. 2.0 в данном случае). Вы создаете ветку для кода 1.x и вносите в нее все свои исправления. Любые изменения в 1.x должны быть объединены (вручную, если необходимо) с веткой trunk (2.0).

Затем я бы настаивал на том, чтобы разработчики 1.x отмечали как номер редакции для коммита 1.x, так и номер ревизии для слияния 2.0 в заявке на эту ошибку. Таким образом, будет легче заметить, если кто-то забудет объединить свои изменения, и тот факт, что они должны отслеживать это, поможет им вспомнить.

Answer 8

Слияние рано, слияние часто, и убедитесь, что QA на магистрали знает и регрессирует / проверяет дефекты, исправленные в каждом патче выпусков обслуживания.

Действительно легко позволить что-то ускользнуть и «исправить» ошибку в следующем выпуске, и позвольте мне сказать вам, что клиенты не заботятся о том, насколько сложным может быть управление несколькими филиалами - это ваша работа

Убедитесь, что вы используете систему управления исходным кодом, которая поддерживает ветвление и слияние (у меня был опыт работы с Perforce и SVN, и хотя Perforce лучше, SVN бесплатен).

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