Организация репозитория

У Eric есть превосходный ряд статей об использовании Управления исходным кодом и организационных лучших практиках. Глава 7 имеет дело с ответвлениями (и да, она рекомендует/trunk/и/branches/каталоги, которые Вы предлагаете).

Я использовал По необходимости в течение долгого времени, и таким образом, мои комментарии могут быть немного По необходимости центральными, но основные принципы относятся к любому программному обеспечению SCM, которое имеет половину достойного ветвления. Я очень твердо уверенный в использовании разветвленных методов разработки. У меня есть "основное" (иначе "магистраль"), который представляет кодовую базу с этого времени вечности. Цель состоит в том, что это, большую часть времени, стабильно и, если бы нажатие прибыло в толчок, то Вы могли бы сократить выпуск каждый раз, когда это отразило бы текущую функциональность системы. Те противные парни продаж продолжают спрашивать....

Разработки происходят в ответвлениях, которые переходятся от ОСНОВНОГО (обычно - иногда можно хотеть перейти от существующего ответвления dev). Интегрируйтесь от ОСНОВНОГО до Ваших ответвлений dev так часто, как Вы можете, для остановки вещей, отличающихся слишком много - или можно просто планировать для больший период интеграции спустя. Только интегрируйте свою задницу, ударив новую возможность к ОСНОВНОМУ, когда Вы уверены, что она выйдет в предстоящем выпуске.

Наконец, у Вас есть строка ВЫПУСКА, который опция различных ответвлений для различных выпусков. Существуют некоторые варианты в зависимости от поддержки маркировки Вашего программного обеспечения SCM, и как различные главные/незначительные изменения, вероятно, будут. Таким образом, можно выбрать, например, для ответвления выпуска для каждой доработанной версии, или только для главного числа версии. Ваш пробег может варьироваться.

Обычно ответвление от ОСНОВНОГО для выпуска уже в возможном. Bugfixes и последние изменения могут или пойти прямо в ВЫПУСК для более поздней интеграции с ОСНОВНЫМ, или в ОСНОВНОЙ для непосредственной интеграции создают резервную копию. Нет никакого жесткого правила - делают что работы лучше всего. Если, однако, у Вас есть изменения, которые могут быть отправлены ОСНОВНОМУ (например, от ответвления dev, или "небольших тонких настроек" кем-то на ОСНОВНОМ), то сделайте первого. Это зависит от того, как Ваша команда работает, что Ваши циклы выпуска и т.д.

Например, у Меня было бы что-то вроде этого:

//MYPROJECT/MAIN/... - the top level folder for a complete build of all the product in main.
//MYPROJECT/DEV/ArseKickingFeature/... - a branch from MAIN where developers work.
//MYPROJECT/RELEASE/1.0/...
//MYPROJECT/RELEASE/2.0/...

Нетривиальный проект будет, вероятно, иметь много ответвлений DEV активными сразу. Когда разработка была интегрирована в ОСНОВНОЙ так, чтобы это была теперь часть базового проекта, избавьтесь от старого ответвления DEV, как только Вы можете. Многие инженеры будут рассматривать ответвление DEV как свое собственное личное пространство и снова использовать его для различных функций со временем. Препятствуйте этому.

Если после выпуска необходимо исправить ошибку, то сделайте это в соответствующем ответвлении выпуска. Если ошибка была ранее исправлена в ОСНОВНОМ, то интегрируется через, если код не изменился так в ОСНОВНОМ, фиксация отличается.

Что действительно дифференцируется, строки кода политики, которые Вы используете для управления ими. Например, какие тесты запущены, кто рассматривает пред/сообщение изменение, какое действие происходит, если сборка повреждается. Обычно политики - и поэтому наверху - являются самыми сильными в ответвлениях выпуска и самыми слабыми в DEV. Существует статья здесь, которая проходит некоторые сценарии и связывается с другими полезными вещами.

Наконец, я рекомендую идти с простой структурой для начала, и только представляю дополнительный dev и выпускаю по мере необходимости.

Надежда, которая помогает и не указывает-bleedin '-obvious слишком много.

Что я делаю и обычно вижу, как стандарт:

Соединительная линия должна содержать Вашу основную строку разработки, Вашу нестабильную версию. Необходимо создать ответвления выпуска для выпусков.

Что-то как:

/ соединительная линия (здесь Ваш разрабатывают версию 2.0),/branches/RB-1.0 (это - ответвление выпуска для 1,0),/branches/RB-1.5

При нахождении ошибки в 1,5 Вы фиксируете ее в ответвлении RB и затем объединяетесь с соединительной линией.

Я также рекомендую эту книгу.