Mercurail (и не только) — как работаете с локальными ветвями/репозитариями или как избежать лишних ветвлений в центральном репозитарии?
Работаем с Mercurial. Есть несколько небольших проектов. Над каждым работает несколько человек. Есть центральный репозитарий и в нём основные ветки: релизные, пре-релизные, тестовые и текущая — всё примерно, как у всех.
Но работа ведётся интенсивно и нужно часто обмениваться кодом. Каждый разработчик делает локальные комиты для себя (по нескольку в день). Плюс, для обмена кодом делаются комиты в текущую ветвь (один-два раза в день — по мере появления у разработчиков сколько-либо стабильного кода о котором должны знать другие участники). Соответственно, текущая ветвь запросто может не собираться и практически всегда содержит ошибки, а стабилизация производиться в пре-релизах — но это к делу не относится.
Это лирика, чтобы примерно было понятно о чём речь.
Вопрос — комитов много, но реально поток разработки один, и загрязнять центральный репозитарий лишними комитами и особенно ветками не хочется. Даже ветвления от текущей ветки — редко когда нужны. Вопрос — как вы у себя это решаете?
Всё вываливать в центральный репозитарий? Там будет ад и ужас. Особенно в текущей ветке с которой идёт основная работа. И в пре-релизах тоже не намного лучше, так как стабилизация кода идёт там и там тоже довольно много комитов от разных разработчиков.
Делать клоны репозитариев, работать в них, потом копировать нужные ревизии в копию центрального репозитария в нужную общую ветвь и пушить его? Лишних ветвлений не будет, но не удобно и теряется информация о связи локальных комитов (ветвей) с основными ветвями. В большинстве мануалов именно так рекомендуется делать, но на практике метод довольно кривой. И, как я уже сказал, самое главное — разработчик не видит какие из его локальных веток/комитов, как соотносятся с общими ветками в центральным репозитарии. Это может быть работает, если разработчик делает комиты относительно редко — взял, фичу, реализовал, закомитил, но специфика такая, что нужные частые комиты и обмен текущим кодом.
Сейчас вроде бы сошлись на том, что в центральном репозитарии хранятся есть только общие основные ветки (релиз, пре-релиз, текущая разработка, плюс по-необхомости, баг-фиксы, фичи т.п.). А каждый раработчик имеет один репозитарий в котором заводит собственные локальные ветки и ведёт текущую работу в них. В этот репозитарий регулярно затягиваются все изменения из центрального и если, нужно, то локальные ветки мёрджатся с общими… В центральный же репозиторий заталкиваются только общие ветки. Желающие могут заводить локальные репозитарии на группу и делать двух-уровневую систему. Когда нужно сделать комит в общую ветку, то переходим в эту ветку (update в её голову). Потом делаем revert в нужную ревизию локальной ветки (получаем состояние локальной ветки в рабочей папке, но без изменения текущей ревизии — остаёмся в голове общей ветки). Делаем комит (в общую ветку). Пушим только общие ветки. В результате в центральный репозитарий локальные ветки не попадают. Для обозначения связи локальных и общих веток, на каких-то знаковых этапах (когда разработчик считает это нужным — хоть каждый раз) разработчик после комита в общую ветку делает её мёрдж в локальную ветку. В результате на графе в своём репозитарии он видит связь между своими локальными ветками и общими, но при этом в центральный репозитарий локальные ветки не попадают.
В целом это работает. Но как-то тоже странно и кривовато.
Может быть у кого-то есть какие-то полезные практики идеи на эту тему? И вообще, интересно послушать про иерархию и организацию репозитариев в свете активной разработки и загрязнения центрального репозитария ветвлениями.
Простой
Простой
