Ветвление шаблонов/политик

Question

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

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

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

Благодаря

Answer 1

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

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

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

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

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

Для справки, мы используем .

Answer 2

The subversion book описаны некоторые часто используемые шаблоны ветвления (например, высвобождением ветви, художественные ветви и т.д.).

Answer 3

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

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 Филиалы серверов существуют только между 01-Development/Release1.0 и 02-Integration/Release1.0, 02-Integration/Release1.0 и 03-Staging/Release1.0, 03-Staging/Release1.0 и 04-Production /Release1.0

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

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

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

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

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

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

Answer 4

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

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

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

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

Answer 5

Посмотрите ветвящиеся модели:

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

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

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

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