Форум программистов » Программирование
В чем преимущество и недостатки использования бренчев в системах контроля версий
(11 posts)-
Возникла дилемма. Ситуация следущая: Есть 2 команды, одна в Украине, а вторая в другой стране. Используется TFS source control. В целом над проектом работает окколо 20 человек. После комитов некоторых личностей, все перестает работать (кто-то поверх свои изменения залил и тп). Несколько человек в команде предлагают сделать 2 бренча (для украинцев и иностранцев), чтобы избежать подобных ситуаций. Остальная часть колектива против, аргументируя это тем, что лучше мержить по немногу, чем потом бранчи.
Уважаемые разработчики, как по Вашему мнению, какие преимущества и недостатки бренчев? Возможно у Вас есть опыт работы с бренчами, поделитесь пожалуйста.
С уважением,
Алекс. -
А потом дойдет до ветки на каждого сотрудника.
1. Заставлять всех проверять код перед своим комитом
2. Создать ветку для стабильной версии и разрешить мержить туда только опытным разработчикам. -
Имхо остальная часть коллектива права, а даже если не так, то их ведь больше :-)...
Скв (система контроля версий) удобна, когда нужно, чтобы разработчики не мешали друг другу. А за косяки нужно бить по рукам. Или сначала просвещать, а бить по рукам потом :-) . Или заставлять исправлять все проблемы самостоятельно... В общем, тут нужны административные меры, а не технические.
Почитайте еще http://www.gnuman.ru/stuff/svn_strateg/ на эту тему...PS. Удобно каждую фичу выделять в бранч. Тогда в бранче можно делать промежуточные коммиты, которые никому не мешают, а уже готовый результат мержить в trunk...
Удачи :-)
-
с бренчами работаю редко, только если есть острая необходимость - большой кусок работы и нужно сабмитить. С технической точки, можно еще попробовать подключить в процесс разработки билд-сервер(например, TeamCity или CruiseControl) - при каждом сабмите собирает проект, "прогоняет" тесты и многое другое еще можно ему поручить. Если вдруг чето падает(билд не собирается, тесты обвалились) сразу "званит в колокол" - шлет письма и тому подобное. Также согласен с предыдущим комментарием насчет админ.мер, нужно вовремя присекать.
Успехов! -
1. Посвятить всех разработчиков, что перед коммитом нужно делать update и прогонять все тесты.
2. Настроить continues integration server как писал Denis Osetrov на билд и запуск тестов после каждого коммита + рассылку писем всем разработчикам о результатах билда (тогда сразу будет видно кто завалил билд и к кому применять админ меры) -
И плюс к предидущим советам - внедрите код ревью. Это сильно улучшит качество кода и будет способствовать обмену опытом в команде. Благо с ТФС это сделать как два пальца...
-
Сделать отдельный branch - это пожалуй худшее, что вы вообще можете сделать в такой ситуации. Правильный вариант - исправлять код - писать письма с разъяснениями, почему так, а не иначе, причем лучше еще до комита - те делать code review.
-
У меня вопрос: а транк - это работающий продакшин проект, или девелопмент?
Если ламается рабочий проект - то нужно вести две ветки и в продакшин ветку мерджить одному ответственному за это человеку. Смерджил, прогнал тестами и отдал QAна тестинг. Все работает - выложил на сервер. А девелоперская ветка может ломаться - это нормально. Решать это можно к примеру откатами глючных комитов и изучением причин, почему баги полезли. Не всегда виноват конкртено один человек - может быть просто стечение обстоятельств по изменению структуры, линков, апи...
-
А локально, чтобы откаты не были так болезненны - каждому девелоперу свои комиты делать исключительно в свои ветки и после некоторого времени либо руками, либо автоматом удалять старые ветки.
-
Каждый +1 бранч, если он не "тупиковый", это сразу + n-ный обьем работы по мержу.
А это означает, что нужно проинформировать всех сотрудников, что еще и "вот сюда" нужно спустить свои изменения. Нужно и вот здесь их проверить.
Вобщем "личный" бранч врядли спасет продукт от дестабилизации.Могу рассказать как у нас. Жизненный цикл продукта следующий:
1. Новые фичи разрабатываются в транке. На этом этапе транк не стабилен.
Об этом еженочно мигает Cruise Control.2. Стабилизируем транк.
Вот здесь есть вероятность того, что необходимо паралельно вести разработку новых фич - а это вынуждает бренчевать хед.3. После вывода QA "trunk - боле-мене стабилен", бранчуем транк. Вот так получаем боле-мене новый стабильный бранч. И этим самым открываем полигон(транк) для новых разработок.
Если на предедущем шаге было необходимо бранчевание, мержим брачн в транк и продолжаем девелопмент в транке.
4. Продолжаем стабилизацию бранча. На этом этапе происходит только исправление ошибок со спуском, никакой разработки. Именно поэтому обьем работы по синхронизации стабильного бранча и транка минимален.
5. Выпускаем продукт - ставим таг. Возможно это Вам и не понадобится. Тагом помечаем в свн исходники конкретного экземпляра продукта. У нас их порядка 10, и все они на одном движке.
-
Ребята, какие транки, бранчи?..
Это же TFS! Там есть замечательная вещь - shelve. Сохраняешь изменения в шелв, потом тебе делают ревью, гоняют тесты и т.д. Если все норм - тогда делаешь чек-ин (коммит по svn-овски).После TFS мне кажется что svn какая-то ущербная система контроля версий. Я даже не представляю как в svn сделать код ревью без коммита - бранчи каждый раз создавать?.. Подскажите если кто знает. Предидущий проект был на TFS - текущий на svn =(
