DVCS Repo Design - отделить dev от стабильного, используя ветки или отдельные репозитории?

Question

Я работаю над «планом действий» на своей работе по переносу нашего управления исходным кодом с SourceSafe 6.0 (тьфу) на DVCS, такой как git или Mercurial (предпочтительно git ATM). Сейчас я работаю над будущим дизайном репозитория, то есть разметкой веток и настройкой «центрального» / благословенного репо.

Теперь, поскольку я действительно использовал git только как средство для передачи хобби открытого исходного кода на GitHub и в последнее время для поддержания своего частного репо на работе, чтобы у меня был более детальный контроль над мои версии кода, чем позволяет SourceSafe. К сожалению, мне еще предстоит испытать широкий спектр сценариев ветвления / слияния или другого полусложного использования git в своих репозиториях, кроме использования простых функциональных веток. Другими словами, у меня нет большого опыта работы с DVCS ', поэтому я не думаю, что могу предсказать типичный рабочий процесс, который мы будем использовать здесь, и поэтому не могу самостоятельно создать соответствующий проект хранилища.

Поэтому вместо этого я потратил много времени на чтение рабочих процессов git других людей и стараюсь наилучшим образом применить эти стратегии к тому, как мы выпускаем код на моей работе. Я полагаю, что в любом случае это место для начала, и мы можем изменить его по ходу дела.

Теперь, после просмотра многих рабочих процессов git, мне действительно нравится конкретный , изложенный Винсентом Дриссеном , который, кажется, имеет очень чистый макет ветвления, который почти соответствует тому, как мы выполняем развертывания. на работе (или должен, во всяком случае):

Отделение Dev / Stable с использованием веток

---

Тем не менее, я признаюсь, что немного запутался, увидев немного другой пример на сайте Джоэла Спольски HgInit , который, кажется, больше фокусируется на отдельных репозиториях, чем на ветвях для разделения dev и стабильного кода:

Отдельное Dev / Stable с использованием Repos

---

Вопросы

---

Является ли этот разделенный на репозитории разделительный слой просто Mercurial, который мало используется с git? Если нет, то каковы преимущества / недостатки использования этого метода по сравнению с использованием ветвей для разделения кода dev / stable? Или я просто совершенно не понимаю, что здесь происходит? : -)

Любой вклад будет оценен; Я заранее прошу прощения, если этот вопрос - пустая трата времени из-за того, что я погружен в невежество.

Answer 1

В конце концов, все зависит от ваших предпочтений.Мне нравятся клоны в качестве модели ветвей, которые охватывает Джоэл, но они оба действительны.Вот отличная статья, которая охватывает несколько различных моделей ветвления как в Mercurial, так и в Git (несмотря на название):

http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

Мой самый большой совет - не переусердствовать.Я знаю, что вам нужно конкретное предложение, на которое руководство может согласиться, но если мой опыт повторится там, где вы находитесь, вы обнаружите, что люди относятся к децентрализованной части довольно серьезно.У вас будут импровизированные команды, которые будут прилагать небольшие усилия по работе с сетевыми ресурсами, у вас будет клонирование и перетаскивание между разработчиками и всякая специальная организация.Пока у вас есть несколько ключевых репозиториев с твердыми, четкими ожиданиями (например, «должен компилироваться» или «должен быть отправлен» или «должен иметь благословение Джима»), все будет в порядке.

Answer 2

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

Причина этого двоякая.Во-первых, когда у вас есть ошибка в ветви функции, вы хотите знать, что ошибка является результатом функции, а не из-за ошибки в коде.Во-вторых, когда вы хотите выпустить свою функцию, вы не хотите, чтобы происходили какие-либо изменения, которые на самом деле не имеют отношения к вашей функции.стратегия "кустарниковой ветки".

В основном есть ветки функций, релизов, исправлений и основных веток.Все ветви объектов должны иметь ревизию, помеченную в основной ветви на своей базе, и они не могут сливаться с другими ветвями объектов в любой точке.Однако они могут объединиться с будущими теговыми ревизиями в основной ветке.

Как только функция готова, она объединяется с веткой выпуска для тестирования.Как только это проверено, это идет в главную ветвь.Исправления обрабатываются так же, как вы изображаете их на диаграмме.

Наконец, у нас есть одноразовая ветвь «интеграции».Эта ветка в значительной степени автоматизирована объединением всех функций, которые могут быть выпущены в ближайшее время.Эта ветвь подвергается ежедневным тестам сборки, но не обязательно такой же уровень строгого тестирования, как ветвь релиза.Он должен выявлять ошибки взаимодействия функций на ранних этапах процесса.

Я - человек Mercurial.Так что я не вижу, чтобы действительно существовало различие между «веткой» и «хранилищем».На самом деле мне не очень нравятся несколько репозиториев веток для большинства вещей, поскольку это может сделать слишком простым объединение веток, с которыми вы на самом деле не хотите работать.Я бы предпочел просто не иметь ревизий в моем репо вообще.