Comments 20
А у нас на проекте структура не такая. Все разбито по релизам и патчам.
Не понятно на самом деле как организована работа с кодом. Слить кусок функционала — это как по вашему? Каждый разработчик на основе какой ветки он начинает разработку? Схема не помешала бы.
Суть в том, что если разработчики непрерывно шарят свой код друг с другом, то ИХ функционал содержит, возможно, не отестированный функционал других.
Если же у всего функционала общий предок, скажем релиз ветка и код не шарится постоянно — тогда понятнее, но все же большое количество веток настораживает и говорит о том, что возможны некоторые ошибки, которые повлекут вливание не оттестированого кода.
И как ксати с bookmarks, вы их не используете? Кадеться, что для feature веток, они бы подошли.
Суть в том, что если разработчики непрерывно шарят свой код друг с другом, то ИХ функционал содержит, возможно, не отестированный функционал других.
Если же у всего функционала общий предок, скажем релиз ветка и код не шарится постоянно — тогда понятнее, но все же большое количество веток настораживает и говорит о том, что возможны некоторые ошибки, которые повлекут вливание не оттестированого кода.
И как ксати с bookmarks, вы их не используете? Кадеться, что для feature веток, они бы подошли.
в ветке default ошибки могут быть, которые перекочуют, если незамечены, в testing, но на продакшт должен попадать оттестированный код, из ветки testing. Смысл в такой организации предполагает фиксирование определенного набора функций в ветке testing. Пока одни разработчи фиксят баги найденные в testing, остальные разработчики (идеальные), занимаются новым функционалом, параллельно, заливая код в ветку default.
Функционал. Функционал это по сути кусок кода. Как вы обмениваетесь именно этими кусками, при этом не обмениваетесь не нужными кусками, попавщие к вам от других участников?
У всех ваших фиче-веток, общий предок? Тогда я понимаю, как можно обмениваться именно куском функционала. В других случаях — нет. Но при этом организация репо должна быть строго иерархической и должны быть правила синхронизации. Вот этот вопрос меня интересует.
Сложно все это на словах, схему надо. Но это важно и интересно.
У всех ваших фиче-веток, общий предок? Тогда я понимаю, как можно обмениваться именно куском функционала. В других случаях — нет. Но при этом организация репо должна быть строго иерархической и должны быть правила синхронизации. Вот этот вопрос меня интересует.
Сложно все это на словах, схему надо. Но это важно и интересно.
>«Если баг, действительно является мелким, то допускается правка непосредственно в ветке Release»
Никогда, ни при каких условиях :) Уже обжигались с этим.
Никогда, ни при каких условиях :) Уже обжигались с этим.
Это же все про mercurial? :-) Мы вот обходимся release + default + личные бранчи. Правда, команда небольшая — пять человек. И специфика — web.
Личные бранчи мержатся периодически от default-а. Правка багов в release допускается, причем бэкпорт в default делается паралельно руками.
Личные бранчи мержатся периодически от default-а. Правка багов в release допускается, причем бэкпорт в default делается паралельно руками.
Я правильно понимаю, что вы смешали две концепции в одно: стабильный транк / нестабильные бранчи и нестабильный транк / стабильные бранчи?
Спасибо за статью.
Наш проект в стадии разработки, ходил вынашивал идеи где и что хранить, и как лучше.
Думаю возьмем за основу или в целом предложенную вами структуру.
Наш проект в стадии разработки, ходил вынашивал идеи где и что хранить, и как лучше.
Думаю возьмем за основу или в целом предложенную вами структуру.
/branches/work-username — рабочие ветки каждого девелопера
/branches/test-v1.2.3-hotfix-75 — тестовые ветки, хотфиксы и т.д.
/tags/release-v.1.2.3 — тегированные релизы (никогда и ни при каких условиях не правятся)
/trunc — текущий stable с атомарно закрытыми тикетами, подтягиваемыми из бренчей
/branches/test-v1.2.3-hotfix-75 — тестовые ветки, хотфиксы и т.д.
/tags/release-v.1.2.3 — тегированные релизы (никогда и ни при каких условиях не правятся)
/trunc — текущий stable с атомарно закрытыми тикетами, подтягиваемыми из бренчей
Десять раз уже пережевано где только можно, включая TFS Branching Guide (и там, что характерно, написано лучше, и не забыты важные мелочи типа того, что все фиксы из релиза должны немедленно откочевывать в транк, а из него — во все девелоперские ветки, чтобы уменьшить время мерджа).
А еще книжки про Continuous Integration/Delivery (а именно так называется ваше «непрерывного внедрение») сильно предостерегают против порождения кучи веток, и считаю, что в половине случае достаточно одного транка, а в остальной половине — транка + релиза.
Удивительно, да?
А еще книжки про Continuous Integration/Delivery (а именно так называется ваше «непрерывного внедрение») сильно предостерегают против порождения кучи веток, и считаю, что в половине случае достаточно одного транка, а в остальной половине — транка + релиза.
Удивительно, да?
Sign up to leave a comment.
Организация работы с репозиториями