Как группа разработчиков исправляет несколько ошибок в предыдущей версии с помощью Mercurial?

Question

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

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

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

Мы помечаем главную ветвь выпусками (5.1.0.102 и т. Д.).Мы занимаемся разработкой в ​​процессе разработки.

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

Или, как и прежде, вот что мне действительно нужно:

1. Обновление до точки, где мы выпустили (скажем, 6.1.1) таким образом, чтобы группа разработчиков моглаработать вместе
2. Эта группа разработчиков исправляет кучу ошибок.
3. Пометить полученное состояние кода как (6.1.2)
4. Выполнить сборку этого нового 6.1.2codebase.
5. Перенесите эти исправления в ветвь разработки
6. Сделайте это так, чтобы я мог вернуться к 6.1.2 и исправить там ошибки, если необходимо

Или мне нужно создать вспомогательный выпуск, основанный на предыдущем выпуске с работами различных разработчиков.

Как я могу это сделать?

Answer 1

Принятый ответ на вопрос, который вы ранее задавали, остается в силе, и способ, которым вы обрисовали его в этом вопросе ... ну ... правильный способ сделать это.

Так что в принципе я нене понимаю, что или почему вы спрашиваете.

Вот что вы должны сделать.

1. Один из разработчиков начинает работу, обновившись до фокуса последнего выпуска (т. е. набор изменений вашего выпуска 6.1.1)
2. Затем он вносит некоторые изменения, относящиеся к исправлениям, фиксирует и возвращает обратно в центральное хранилище.Обратите внимание, что это создаст другую голову.Это нормально (см. Ниже, если это не так)
3. Другие разработчики из его команды Tiger Team обновляются до этой новой главы и добавляют свой вклад в исправления ошибок, фиксируя и выдвигая / вытягивая при необходимости
4. В какой-то момент у вас есть новая версия, такая как 6.1.2, поэтому вы создаете тег для окончательного набора изменений
5. Затем вы обновляете предыдущую голову (ту, которая была у вас до начала)вся эта работа) и слияние в заголовке 6.1.2, это возвращает все эти исправления ошибок в основную ветку для будущих версий

Это будет выглядеть так:

R5 здесь будет коммит слияния, а R4 будет текущим заголовком, если вы проигнорируете все исправления ошибок, которые вошли в 6.1.2.

Затем, если вы хотите вернуться, чтобы исправитьеще немного, чтобы получить версию 6.1.3, это выглядело бы так (вы следуете тому же плану, что и выше):

Здесь R9 будет текущей главойследующая основная версия вашего проекта, и R10 будет бкоммит слияния, который вернул исправления, вошедшие в 6.1.3, в эту будущую версию.

Answer 2

Ваши шаги почти правильные. Мое предложение таково:

1. Использовать основной ствол как ветку разработки
2. Когда вам нужно отпустить, вы создаете новую ветку
3. Все исправления ошибок в новой ветке выполняются за 1-2 дня до стабильной работы
4. Вы делаете запуск

5. Вы объединяете релиз со стволом уровня

6. Если обнаружены критические ошибки, перейдите к шагу 1.

Answer 3

Для этого на стороне Git есть рабочий процесс, называемый Git Flow . Этот инструмент, по сути, автоматизирует большую часть утомительной работы (создайте ветку из вашей стабильной в работе ветки, совершите коммит, ветвь слияния туда, где находится ваша новая текущая работа).

Существует расширение Mercurial, которое дает вам точный рабочий процесс для Hg: Поток Hg . Я использовал его (хотя и не для большого приложения), и он мне действительно нравится - он автоматизирует шаги, вызываемые так же, как Git Flow, и переносит мудрость сообщества Git на Hg-land.