Ветвящиеся Шаблоны / Политики

Question

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

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

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

Спасибо

Answer 1

Это зависит от того, какое программное обеспечение вы разрабатываете.

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

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

Если проект включает в себя большую реструктуризацию базы кода, мы обычно создаем тег на последней ревизии перед объединением изменений ветви.

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

Для записи мы используем Subversion .

Answer 2

Посмотрите на шаблоны ветвления:

http://www.cmcrossroads.com/bradapp/acme/branching/

В нем описан ряд шаблонов для работы с шаблонами. Я обычно работал двумя способами:

• Стабильная приемная линия - все разработки выполняются в ветвях и объединяются в магистраль только при необходимости. Это означает, что у вас всегда есть одна стабильная точка выпуска.

• Основная линия разработки - все работы выполняются в багажнике. Когда дело доходит до релиза, вы берете тег релиза и используете его. Если требуется серьезная экспериментальная доработка, она выполняется в ответвлении и при стабильном объединении возвращается в ствол.

Answer 3

3 вещи при рассмотрении ветвления.

Во-первых: ветвление в порядке, если вы собираетесь объединить вещи позже. Конечно, у вас всегда может быть ветка с определенным патчем для одного из ваших клиентов с определенной проблемой. Но в конце концов вы хотите объединить большинство патчей обратно в основной ствол

Второе: отстаивайте свои потребности. Я видел дерево всех размеров в зависимости от размера отдела, количества клиентов и т.д ...

В-третьих: проверьте, насколько хорош ваш источник управления для ветвления и слияния. Например, CVS, как известно, очень плохой для такого рода операций. SVN, "CVS сделано правильно", как они утверждают, несколько лучше. Но Линус Торвальдс, который создал Git (который особенно хорош для такого рода операций), скажет вам, что CVS не может быть сделано правильно (он сказал это в очень интересной презентации по Git). Так что если у вас есть реальная потребность в ветвлении и слиянии, по крайней мере, получите SVN, а не CVS.

Answer 4

Книга подрывных данных описывает некоторые часто используемые шаблоны ветвления (например, ветки релиза, ветви функций и т. Д.).

Answer 5

Так мы делаем, и у нас это хорошо работает ...

Project
   |
   +--01-Development
   |  |
   |  +--Release1.0
   |  |  |
   |  |  +--Solution Files
   |  |   
   |  +--Release2.0
   |     |
   |     +--Solution Files
   |
   +--02-Integration
   |  |
   |  +--Release1.0
   |  |  |
   |  |  +--Solution Files
   |  |   
   |  +--Release2.0
   |     |
   |     +--Solution Files
   |
   +--03-Staging
   |
   +--04-Production

ну, вы поняли ...

ПРИМЕЧАНИЕ: Это структура каталогов в Team Foundation Server. Ветви существуют только между 01-Development / Release1.0 и 02-Integration / Release1.0, 02-Интеграция / Выпуск 1.0 и 03-Подготовка / Выпуск 1.0, 03-Staging / Release1.0 и 04-Production / Release1.0

Другими словами, вы не сможете объединить 03-Staging / Release1.0 с 04-Production / Release2.0 и т. Д. ...

Для нас это то, что у нас есть 4 отдельные среды: Разработка, Интеграция (альфа-сервер), Стадия (бета-сервер), Производство.

Код начинается с разработки, начинается с разработки, а затем продвигается по мере тестирования QA (интеграция / альфа) и пользователями (этап / бета) и, наконец, в производство.

Функции / изменения собираются и группируются в выпуски, которые происходят каждые несколько месяцев.

Но предположим, что вы находитесь в разработке для Release2.0, и у вас возникла производственная проблема в Release1.0 ... Я легко могу получить последнюю версию Release1.0 и исправить проблему и продвинуть ее, не оказав никакого влияния на то, что я работали над выпуском 2.0

Не говорю, что это будет работать для всех в любой ситуации, но это работает очень хорошо для нас.