Распределенный контроль версий. - Git & Mercurial ... несколько сайтов - PullRequest
3 голосов
/ 08 сентября 2011

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

Если IA) создать единый репозиторийпапка wwwroot (перехват всех изменений на всех сайтах) B) сделать каждую папку сидений отдельным репозиторием

эта проблема заключается в том, что каждому сайту нужен отдельный физический каталог из-за указателя vhost для разработки и текущей необходимости«какой-то» физический файл различий между сайтами.

Какова лучшая практика здесь?Я склоняюсь к отдельным репозиториям для каждого каталога.который сделает отслеживание любого ветвления и слияния для этого ОДНОГО очистителя сайта ....

Ответы [ 2 ]

1 голос
/ 08 сентября 2011

Это зависит от того, как структурировано ваше программное обеспечение и насколько независимы разные сайты. Наилучшая ситуация, когда вы можете использовать свой основной код как библиотеку, которая находится в своем собственном каталоге, и на разных сайтах нет необходимости изменять даже один файл ядра. Тогда у вас есть свободный выбор, если вы хотите разработать ядро ​​вместе с различными сайтами в одном репо или отделить ядро ​​от сайтов. Когда ядро ​​и разные сайты зависят друг от друга, вам, скорее всего, придется иметь дело со всеми из них в репозитории Sigle.

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

Следующий момент - как разрабатываются разные сайты. Если они разделяют много кода, они могут быть разработаны как разные ветви. Но у этой схемы есть два недостатка:

  • разные сайты обычно не видны разработчику, поскольку обычно есть только один извлеченный
  • Разработчик должен позаботиться о том, где создавать изменения, чтобы в другие ветви входили только нужные изменения, а не что-то особенное только для одной ветви

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

Другая ситуация, если все они не имеют ничего общего, с тех пор все намного лучше. Затем вам нужно решить, хотите ли вы, чтобы они находились в разных репозиториях или как разные каталоги в одном репо. Когда эти разные сайты каким-то образом связаны друг с другом (скажем, что они все одной и той же компании), то может быть лучше поместить их в общий репозиторий, как разные подкаталоги. Когда они не связаны друг с другом (каждый сайт принадлежит другому клиенту, а изменения на этих сайтах не создаются синхронно друг с другом), лучше использовать один репо на сайт.

Если у вас есть подход по одному репо на сайт, было бы неплохо, если бы вы сначала создали сайт-шаблон, включающий основной компонент и базовую конфигурацию, и извлекли репозитории вашего сайта как клоны из этого шаблона. Затем, когда вы меняете что-то в ядре, что также влияет на сайты, вы вносите эти изменения в шаблон и затем объединяете эти изменения в репозитории сайтов (вам нужно только позаботиться, чтобы НЕ сделать это изменение в одном из репозиториев сайта). , поскольку при слиянии сайтов с шаблоном вы можете получить материал из определенного сайта в шаблон, который вы не хотите включать в шаблон).

Так что я предлагаю

  • разработка ядра как единого независимого продукта
  • выберите правильную модель разработки для ваших сайтов

    • все в одном репо с филиалами, когда между разными сайтами происходит обмен кодами

    • но лучше рефакторинг сайтов, чтобы не делиться кодом, так как подход ветвей имеет недостатки

    • все в одном репо, без веток, но с разными папками, если нет обмена кодами между разными сайтами

    • по одному репо для каждого сайта, если они полностью независимы.
0 голосов
/ 25 сентября 2011

Я думаю, вы должны попробовать Mercurial Queues с одним репо. * 1003 то есть *

  • вы храните "базовый" сайт в репозитории
  • все специфичные для сайта изменения, разделенные на набор MQ-патчей (по одному патчу на сайт)
  • вы можете создавать на сайтах репо «только для push», добавлять их в раздел «paths» «рабочего» репо и выдвигать изменения или использовать технику экспорта-копирования

и после применения патча сайта к базе кода вы будете готовы использовать код для каждого сайта

...