Обновление 2019:
В наши дни вопрос будет рассматриваться в контексте использования Git, и 10 лет использования этого распределенного рабочего процесса разработки (в основном через GitHub ) демонстрируют общие рекомендации:
masterготова ли ветвь к развертыванию в рабочей среде в любое время: следующий выпуск с выбранным набором ветвей функций master.dev(или ветвь интеграции, или ' next') - это та, в которой ветвь функций, выбранная для следующего выпуска, тестируется вместе.maintenance(или hot-fix) ветвь - это ветка для текущей версии / исправлений ошибок, с возможными слияниями к devи илиmaster
Такой рабочий процесс (где вы не сливаются devс master, но где вы сливаете только функцию ветвь dev, а затем , если выбран, чтобы для masterтого, чтобы иметь возможность легко уронить имеют филиалы не готовы к следующему выпуску) реализуется в Git сам репо с gitworkflow (одно слово, показанное здесь ).
Смотрите больше на rocketraman/gitworkflow. История этого против разработки на основе магистралей отмечена в комментариях и обсуждениях этой статьи Адама Димитрука .
(источник: Gitworkflow : учебник для начинающих )
Примечание: в этом распределенном рабочем процессе вы можете фиксировать в любое время и передавать в персональную ветку некоторые WIP (Work In Progress) без проблем: вы сможете реорганизовать (git rebase) ваши коммиты, прежде чем сделать их частью ветви функций.
Оригинальный ответ (октябрь 2008 г., 10+ лет назад)
Все зависит от последовательности вашего управления выпуском
Во-первых, все ли в твоем багажнике действительно для следующего релиза ? Вы можете обнаружить, что некоторые из разработанных в настоящее время функций:
- слишком сложный и все еще нуждается в уточнении
- не готов вовремя
- интересно, но не для этого следующего выпуска
В этом случае транк должен содержать любые текущие усилия по разработке, но ветвь выпуска, определенная ранее до следующего выпуска, может служить в качестве ветви консолидации, в которой объединяется только соответствующий код (проверенный для следующего выпуска), а затем фиксируется на этапе омологации, и, наконец, заморожен, когда он идет в производство.
Когда дело доходит до производственного кода, вам также необходимо управлять ветвями патча , помня, что:
- первый набор исправлений может начаться раньше, чем первый выпуск в производство (это означает, что вы знаете, что перейдете в производство с некоторыми ошибками, которые вы не сможете вовремя исправить, но вы можете начать работу с этими ошибками в отдельной ветке)
- другие ветки патчей будут иметь роскошь начинать с четко определенной производственной этикетки
Когда дело доходит до ветки dev, у вас может быть один ствол, если только у вас нет других усилий по разработке, которые вы должны выполнять параллельно :
- массивный рефакторинг
- тестирование новой технической библиотеки, которая может изменить то, как вы называете вещи в других классах
- начало нового цикла выпуска, где необходимо внести важные архитектурные изменения.
Теперь, если ваш цикл разработки-выпуска очень последовательный, вы можете просто пойти так, как предлагают другие ответы: одна ветка и несколько веток выпуска. Это работает для небольших проектов, где вся разработка обязательно войдет в следующий выпуск, и может быть просто заморожена и служить отправной точкой для ветки релиза, где могут происходить исправления. Это номинальный процесс, но как только у вас есть более сложный проект ... его уже недостаточно.
Чтобы ответить на комментарий Вилле М.:
- имейте в виду, что ветка dev не означает «одна ветвь на разработчика» (что вызовет «безумие слияния», поскольку каждый разработчик должен будет объединить работу других, чтобы увидеть / получить свою работу), но одна ветка dev на разработку усилия.
- Когда эти усилия необходимо объединить обратно в транк (или любую другую «основную» или ветвь релиза, которую вы определяете), это работа разработчика, а не - повторяю, НЕ - менеджера SC (который не знает, как решить любое конфликтующее слияние). Руководитель проекта может контролировать слияние, то есть убедиться, что оно начинается / заканчивается вовремя.
- кого бы вы ни выбрали для слияния, наиболее важным является:
- иметь модульные тесты и / или среду сборки, в которой вы можете развернуть / протестировать результат слияния.
- определить тег до начала слияния, чтобы иметь возможность вернуться к предыдущему состоянию, если указанное слияние оказывается слишком сложным или достаточно длинным для разрешения.
