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