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

Question

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

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

Answer 1

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

Подрывная деятельность включает отслеживание слияния начиная с версии 1.5, поэтому вы гарантируете, что один и тот же набор изменений не будет объединен дважды, что приведет к глупым конфликтам.Существуют и другие системы (например, Мерзавец, Переменчивый, Аккурев, Волей - неволей), которые позволяют вам создавать запросы типа "какие изменения в ветке A не были объединены в ветку B?" и переносить необходимые исправления в ветку разработчиков.

Answer 2

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

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

Answer 3

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

Answer 4

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

Что касается нашего основного продукта, то у нас есть необходимость одновременной разработки более чем в 2 версиях одновременно.

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

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

Когда я совершаю коммит, я обязательно всегда комментирую коммит чем-то вроде

объединенный 1.1 rev 5656-5690

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

Answer 5

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

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

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

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

Answer 6

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

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

Answer 7

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

Answer 8

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