Использование веток git для вариаций проекта - PullRequest
Новая
       7

Использование веток git для вариаций проекта

3 голосов
/ 15 апреля 2010

Я использую функцию ветвления в git для управления 5 вариантами небольшого веб-сайта. Есть 5 версий, которые все будут жить в разных подкаталогах на производстве. Мой подход к проверке различных веток в их соответствующих папках заключался в следующем: 

mkdir foo && cd foo
git init
git remote add origin git@...:project.git
git fetch origin foo:foo

Где "foo" - это имя данной ветви. Это было хорошо, за исключением того, что оно вытянуло все мои репозитории (проекты, исходники as3 и т. Д.) В эти папки ветвей, а не просто в публичную папку www, что является единственным, что мне действительно нужно в работе.

Есть ли более чистый способ справиться с этим? Git не может клонировать подкаталоги, верно?

Ответы [ 3 ]

2 голосов
/ 15 апреля 2010

Способ работы DVCS (толкание / вытягивание все репо) заставляет вас рассуждать в терминах компонента (связный набор файлов , с их собственный коммит жизненного цикла)

Ваша папка www должна быть в вашем случае субмодулем (Git) или subRepo (Mercurial) .
Таким образом, вы сможете вытащить все.

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

Последнее решение, которое я забыл упомянуть, доступно начиная с Git1.7:

редкая проверка

Как только репозиторий клонирован, трюк дерева чтения ограничивает ваш "просмотр" репозитория только теми файлами или каталогами, которые находятся в .git/info/sparse-checkout файле .

В вашем случае вы могли бы просто создать один .git/info/sparse-checkout с соответствующим каталогом, и когда вы обновляете свое рабочее дерево, появится только этот каталог (например, foo).
Это еще одно решение, которое:

  • позволяет сохранить хранилище без изменений
  • избегайте любых работ по техническому обслуживанию до поставки.
1 голос
/ 15 апреля 2010

Не смешивайте вещи, которые вы хотите оставить приватными, в свой выпускаемый продукт.

Я бы посоветовал хранить ваши продукты (html, php, js, img и т. Д.) Отдельно от источников. Храните источники в проекте или проектах и ​​храните продукты отдельно в другом проекте. Или даже просто динамически создавать продукты по требованию с помощью сценария сборки, который копирует / генерирует / и т.д. выходные данные из источников. Таким образом, легко указать, какие источники генерировали какой выход.

0 голосов
/ 15 апреля 2010

В настоящее время (AFAIK) git будет клонировать только весь репозиторий. Можно использовать отдельный репозиторий для развертывания. Учитывая гибкость git, я не удивлюсь, если вы сможете перенести / вытащить из основного репозитория разработки и просто перенести одну ветку во второй репозиторий развертывания, все из одного и того же локального репозитория. Но я никогда не пробовал это.

...