Организация работы с репозиториями

[@sadyjka]

А у нас на проекте структура не такая. Все разбито по релизам и патчам.

[@Zada]

Не понятно на самом деле как организована работа с кодом. Слить кусок функционала — это как по вашему? Каждый разработчик на основе какой ветки он начинает разработку? Схема не помешала бы.

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

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

И как ксати с bookmarks, вы их не используете? Кадеться, что для feature веток, они бы подошли.

[@dizews]

в ветке default ошибки могут быть, которые перекочуют, если незамечены, в testing, но на продакшт должен попадать оттестированный код, из ветки testing. Смысл в такой организации предполагает фиксирование определенного набора функций в ветке testing. Пока одни разработчи фиксят баги найденные в testing, остальные разработчики (идеальные), занимаются новым функционалом, параллельно, заливая код в ветку default.

[@Zada]

Функционал. Функционал это по сути кусок кода. Как вы обмениваетесь именно этими кусками, при этом не обмениваетесь не нужными кусками, попавщие к вам от других участников?

У всех ваших фиче-веток, общий предок? Тогда я понимаю, как можно обмениваться именно куском функционала. В других случаях — нет. Но при этом организация репо должна быть строго иерархической и должны быть правила синхронизации. Вот этот вопрос меня интересует.

Сложно все это на словах, схему надо. Но это важно и интересно.

[@Mozzi]

>«Если баг, действительно является мелким, то допускается правка непосредственно в ветке Release»

Никогда, ни при каких условиях :) Уже обжигались с этим.

[@dizews]

писал эту строчку с большой опаской, надеясь что это будет применяться крайне редко

[@Mozzi]

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

[@slik]

nvie.com/git-model? :)

[@dizews]

о, спасибо за ссылку, значит я не одинок.

[@Vii]

У меня первая иллюстрация распечатана и висит на мониторе перед глазами — эдакий мотиватор, как плакаты со Шварценеггером в спортзалах =)

[@dmiceman]

Это же все про mercurial? :-) Мы вот обходимся release + default + личные бранчи. Правда, команда небольшая — пять человек. И специфика — web.

Личные бранчи мержатся периодически от default-а. Правка багов в release допускается, причем бэкпорт в default делается паралельно руками.

[@dizews]

да, статья была написана применительно к mercurial

[@max7]

Здрасти, я ваша тётя Ася

[@piumosso]

Я правильно понимаю, что вы смешали две концепции в одно: стабильный транк / нестабильные бранчи и нестабильный транк / стабильные бранчи?

[@ivann]

Мне тоже непонятно как фиксить баг в старом релизе с такой архитектурой. Заставлять пользователя апдейтиться?

[@piumosso]

Думаю, надо Release совместить с Hotfixes (стабильный транк / нестабильные бранчи). Зачем нужен Release, если туда не коммитить (если изменение существенное — тогда бранч)?

[@ScREW]

Можно ссылку на определение концепций?
Я сейчас изучаю разные концепции работы с системами контроля версий в поисках подходящей. Особенность работы моей компании — ежедневные релизы.

[@elfin]

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

[@pcmaniac]

/branches/work-username — рабочие ветки каждого девелопера
/branches/test-v1.2.3-hotfix-75 — тестовые ветки, хотфиксы и т.д.
/tags/release-v.1.2.3 — тегированные релизы (никогда и ни при каких условиях не правятся)
/trunc — текущий stable с атомарно закрытыми тикетами, подтягиваемыми из бренчей

[@lair]

Десять раз уже пережевано где только можно, включая TFS Branching Guide (и там, что характерно, написано лучше, и не забыты важные мелочи типа того, что все фиксы из релиза должны немедленно откочевывать в транк, а из него — во все девелоперские ветки, чтобы уменьшить время мерджа).

А еще книжки про Continuous Integration/Delivery (а именно так называется ваше «непрерывного внедрение») сильно предостерегают против порождения кучи веток, и считаю, что в половине случае достаточно одного транка, а в остальной половине — транка + релиза.

Удивительно, да?