Мне интересно услышать, как "ветвление" используется в распределенной среде SC.
Мы только начали использовать Mercurial для командной среды, и я надеюсь извлечь уроки из опыта других людей - какие есть хорошие способы «организовать» практики ветвления (надеюсь, я обойду боль и время, когда буду делать это глупо). .)
Из того, что я прочитал, основная магистраль должна содержать код текущей разработки, одна ветвь может быть "стабильным" выпуском, а другие могут быть экспериментами или функциями ... которые объединяются в магистраль ...
Однако - где мне становится немного неясно о таких вещах, как исправление ошибок и QA ... большая часть того, что я прочитал, говорит о ветвлении отдельно для QA (когда закончите, объедините ствол с ветвью, затем нажмите ветка к стволу - это кажется громоздким и без объяснений)
Я также читал, что вы исправляете ошибки в своей стабильной ветке (или ветке выпуска), а затем объединяетесь со стволом ... это кажется интуитивно понятным - так как вы могли бы сломать "стабильную" ветку по мере исправления ошибки ... Я ожидаю, что стабильная ветвь будет "стабильной" и недоступной для версии # ...
Я вижу, что ветвление необходимо, но помогите мне понять некоторые практики, которые существуют. Мы работаем с веб-приложениями на интерпретируемых языках (не соблюдаются), поэтому очень легко что-то менять и ломать.
спасибо.
=======================
Роджер, что Алекс - и спасибо - это имеет смысл -
ОДНАКО у меня сейчас «маленькая» точка преткновения при «объединении» распределенной модели с централизованным ... где многие пишут там предлагают центральное хранилище - «водопой» (если вы будет), где каждый идет, чтобы «поделиться» или «вытащить» последние.
так что теперь я нахожу распределенную модель, которую вы рекомендуете - ломается (по крайней мере, на мой взгляд) ... Я не хочу оставлять 5+ транков (основной, исправление, развертывание / контроль качества, разработка, функция-n) и пусть люди тянут / толкают с каждым - так что кажется, что разработчики ЛОКАЛЬНО будут извлекать из Develop - и они могут ЛОКАЛЬНО разветвляться для функций. или оперативные исправления ... тогда НЕКОТОРЫЙ АДМИНИСТРАТОР объединит центральный РАЗРАБОТЧИК с ЦЕНТРАЛЬНЫМ РЕЛИЗОМ ... команда разработчиков "может" иметь ЛОКАЛЬНЫЙ ОТДЕЛ РЕЛИЗОВ, чтобы исправить то, что группа QA передает обратно ... если они НАЖМИТЕ на РЕЛИЗ и позволить ADMIN слиться с DEV? Затем вытащить свои изменения обратно из Центрального DEV в свои локальные ??? Или они должны слиться локально - и просто нажать RELEASE обратно на центральный?
В соответствии с этим - я не вижу необходимости или желания, чтобы команда разработчиков имела локальную копию MAIN ...
похоже, что поддержание (рекомендуемый) 3-х магистрального центрального хранилища (MAIN, QA, DEV) действительно сбивает с толку рабочий процесс распределенной модели. НО, кажется, желательно иметь центральную ГЛАВНУЮ - которая доставляется в ваши производственные боксы - и центральный контроль качества, который дает толчок к блоку контроля качества и получает контроль качества отдельной командой ... (таким образом, логически не может быть у каждого разработчика коробка локально)
Ничего себе - управление большими рабочими процессами запутано - ДОЛЖНА быть некоторая литература по управлению этими вещами - различные идеи рабочих процессов и т. Д. Сами по себе ИНСТРУМЕНТЫ НЕ МОГУТ хорошо описывать, «как» их использовать ... ( как дрель не идет с инструкцией о том, как построить шкаф !!! lol)
еще раз спасибо