Структура в git с несколькими веб-сайтами

У меня есть веб-сайт, который я храню в git. Это веб-сайт asp.net webforms (но это, вероятно, не имеет значения для этого вопроса).

Веб-сайт используется нашим клиентом для 2 (в будущем 4) веб-сайтов. Большая часть функциональных возможностей используется совместно. Но некоторые вещи, такие как web.config и папка с css, уникальны для каждого веб-сайта.

Вот упрощенная версия кода

|--BackOffice
|  \--UI
|--BackOffice.UI
|  \--WebControls
|--BackOfficeTests
|--Deployment
|  \--db
|--BusinessLogicLayer
|  |--bin
|  |--obj
|  \--Properties
|--scripts
|--Website
|  |--admin
|  |--App_Browsers
|  |--App_Code
|  |--App_Data
|  |--Styles
|  |--web.config

Какова была бы хорошая структура для этого в Git?

Например, код BackOffice будет полностью разделен. Веб-сайт будет доступен, за исключением папки "Стили" и файла web.config.

Есть ли у вас хорошее предложение для структуры, которая не делает слияние и ветвление слишком длинным?

Я попытался создать такую ​​структуру:

Master
|--Site1
|--Site2

Но я предвижу слишком много черрипика при перемещении кода из одной ветки в другую Будет ли подмодуль в порядке или это усложнит ситуацию?

EDIT: Моя действительно большая проблема заключается в том, что я хочу развертывать непосредственно из своего репозитория git. И если я уйду в эти каталоги/файлы, они будут объединены во время слияния, если я не сделаю некоторые сложные вещи (тогда я не могу позволить всем в команде сделать это). Или мне придется игнорировать эти файлы и получать их откуда-то еще...

Ответы

Ответ 1

Предполагая, что ваша главная ветвь содержит весь ваш проект:

|--BackOffice
|  \--UI
|--BackOffice.UI
|  \--WebControls
|--BackOfficeTests
|--Deployment
|  \--db
|--BusinessLogicLayer
|  |--bin
|  |--obj
|  \--Properties
|--scripts
|--Website
|  |--admin
|  |--App_Browsers
|  |--App_Code
|  |--App_Data
|  |--Styles
|  |--web.config

Теперь любые изменения, которые являются общими для всех веб-сайтов, привязаны к этой ветке.

Сделайте отдельные ветки для разных сайтов. Пример:

От ведущей ветки

git checkout -b site1
git checkout -b site2
git checkout -b site3
git checkout -b site4

теперь, когда вы хотите изменить какие-либо файлы определенного сайта, то есть папку "Стили" или web.config, сделайте это в этих ветвях.

Теперь идет часть развертывания. Предположим, вы хотите развернуть сайт1, создать временную ветвь в локальной системе на основе мастера, объединить в нее ветвь site1 и развернуть ее. Наконец, удалите ветвь temp.

git checkout -b temp
git merge site1

tar или запишите свой код и разверните его. После этого

git checkout master
git branch -D temp

Вы даже можете сделать небольшую оболочку script, которая делает это, если вы не хотите раскрывать способ развертывания. Позволяет называть это script deploy.sh. Например:

#!/bin/bash

if [ ! $1 ]; then
        echo "Please pass in the name of the site you want to deploy."
        exit 1
fi

#Check if we are on master branch
git status | grep "On branch master"
if [ $? -ne 0 ]; then
        echo "You are not on master. Please execute 'git checkout master'"
        exit 1
fi

#Check if the entered site for deployment actually exists
git branch | grep $1 || { echo "No branch $1 exists for deployment."; exit 1; }

#Update from remote
git checkout -b temp
git merge $1
tar -cvf deploy-$1.tar ./deploy.sh *
[ $? -ne 0 ] && echo "Some problem archiving the files..." && exit 1
git checkout master
git branch -D temp

echo "Please use deploy-$1.tar file to deploy the site. Thanks."

exit 0

Теперь, когда вы говорите. /deploy.sh site2, этот script сделает всю грязную работу за кулисами и предоставит вам tar файл, который можно развернуть на рабочем сервере.

Надеюсь, это полезно...

Ответ 2

A submodule является хорошим решением для общего кода BackOffice, причем каждый сайт выступает в роли родительского репо.

Но это не касается файлов конфигурации.

Для них одна из возможностей - контент-фильтр, но это касается хранения и нажатия значений переменной для разных клиентов.

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

Ответ 3

Я могу сделать отдельные каталоги "Сайт" и "Общие", с "Общими", содержащими символические ссылки в стратегических точках и один или оба подмодуля, например:

 Project
 |==.git
 |--Site
 |  |--.git
 |  \--Website
 |     |--Styles
 |     \--web.config
 \--Common
    |--.git
    |--BackOffice
    |  \--UI
    |--BackOffice.UI
    |  \--WebControls
    |--BackOfficeTests
    |--Deployment
    |  \--db
    |--BusinessLogicLayer
    |  |--bin
    |  |--obj
    |  \--Properties
    |--scripts
    \--Website
       |--admin
       |--App_Browsers
       |--App_Code
       |--App_Data
       |--Styles -> ../../Site/Website/Styles
       \--web.config -> ../../Site/Website/web.config

Это не единственный макет, который будет служить - например, если будет легко иметь разные сайты, выбрать и выбрать, что будет изменено, вы можете сохранить свой текущий макет, добавив подпроект "Common" и символически связав все, что вы используете из он не изменился, так:

 Site
 |==.git
 |--BackOffice -> Common/BackOffice
 |--BackOffice.UI -> Common/BackOffice.UI
 |--BackOfficeTests -> Common/BackOfficeTests
 |  [...]
 |--Website
 |  |--admin -> ../Common/Website/admin
 |  |--App_Browsers -> ../Common/Website/App_Browsers
 |  [...]
 |  |--Styles
 |  \--web.config
 \--Common
    |--.git
    |--BackOffice
    |  \--UI
    |--BackOffice.UI
    |  \--WebControls
    |--BackOfficeTests
    |--Deployment
    |  \--db
    |--BusinessLogicLayer
    |  |--bin
    |  |--obj
    |  \--Properties
    |--scripts
    \--Website
       |--admin
       |--App_Browsers
       |--App_Code
       |--App_Data
       |--Styles.example
       \--web.config.example

Чем больше я смотрю на него, тем больше мне нравится, что последнее лучше.