Я управляю магазином разработки, состоящим из 5 разработчиков. Мы используем SVN следующим образом для нашего сайта:
- Разработчики фиксируют все улучшения или исправления ошибок в нашей ветке 'dev', прежде чем отмечать работу как завершенную.
- Задания тестируются на промежуточном ящике с последним кодом в ветке dev.
- Как только задание проходит тестирование, редакции этого задания объединяются с нашей внешней ветвью.
- На наших живых веб-серверах работает магистральная ветка. Периодически они обновляются с помощью сценария публикации, который обновляет SVN на живых серверах, а также выполняет некоторые другие функции (например, запутывает и минимизирует CSS и JavaScript).
Это позволяет небольшим ошибкам быстро проходить через конвейер, а более крупные задания занимают столько времени, сколько им нужно для разработки и тестирования.
Поскольку каждый разработчик отвечает за слияние своих рабочих мест и каждое слияние состоит из небольшого набора изменений кода, они проходят довольно гладко. Это гораздо менее беспокойно, чем старый шаблон, в котором менеджер слияний создает главную ветвь улучшений для набора улучшений. Поскольку другие разработчики, как правило, работают вместе над набором улучшений, вы в конечном итоге получите менеджер слияния, который слил код, который они не написали, что особенно расстраивает, когда возникают конфликты слияний.
Фактически, этот метод отражает методы, которые системы версионирования, такие как Git и Mercurial, пытаются продвигать путем структурирования своих репозиториев. В этих системах управления версиями у каждого разработчика есть свой «локальный» репозиторий. Когда они хотят изменений из другого «хранилища», они должны объединить их со своим локальным кодом, а затем зафиксировать действительную «объединенную» версию.
Вы также можете использовать пометки, как Энди упоминал в своем ответе на этот вопрос. Это может сработать для вас, но я предпочитаю возложить ответственность за слияние на разработчиков, которые пишут код, а не на центрального старшего разработчика или менеджера публикации. Как правило, они идут более гладко.