Один проект, несколько клиентов с git?

Я новичок в GIT и еще не знаю, сколько он будет соответствовать моим потребностям, но он выглядит впечатляюще.

У меня есть один webapp, который я использую для разных клиентов (django + javascript)

Я планирую использовать GIT для обработки этих версий клиентов-клиентов как ветки. Каждый клиент может иметь пользовательские файлы, папки и настройки, улучшенные версии... но они должны иметь одно и то же "ядро". Мы небольшая команда и судим счет github.

Является ли ветка хорошим способом справиться с этим случаем?

О файле настроек, как вы продолжите? Будете ли вы .gitignore конкретным файлом настроек клиента и добавить файл settings.xml.sample, например, это repo?

Также есть ли способ предотвратить объединение некоторых файлов в master? (но поручено филиалу клиента). Например, id хотел бы сохранить некоторые данные клиента в ветке клиента, но не допустить, чтобы они были совершены для управления.

Является ли спецификация ветки .gitignore? Да

ИЗМЕНИТЬ Прочитав все ваши ответы (спасибо!), Я решил сначала реорганизовать мою проектную структуру django, чтобы изолировать ядро и мои приложения differents в подпапках приложений. Это делает более чистый проект, и настройка файла .gitignore упрощает использование ветвей GIT для управления разными клиентами и настройками!

Ju.

Ответ 1

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

Ответ 2

Я бы не использовал ветки для выполнения того, что вы пытаетесь сделать.

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

Выплаты (или клоны, в случае Git) могут лучше соответствовать тому, что вы пытаетесь сделать. Вы создадите репо, содержащее все базовые файлы проекта (и файлы .sample, если хотите), и клонирование репо во все различные места, где вы хотите развернуть код. Затем вручную создайте файлы конфигурации и настройки в каждом развертывании (не берегите add их в репо). Всякий раз, когда вы обновляете код в репо, запустите pull в каждом развертывании, чтобы обновить код. Viola!

Ответ 3

Мэтью Талберт прав, вам действительно нужно отделить пользовательские вещи от нестандартных материалов. Если вы можете реорганизовать весь основной код, который должен содержаться в одном каталоге, ваши клиенты могут использовать его в качестве подмодуля только для чтения git. Дополнительным преимуществом является то, что вы блокируете их в явную версию основного кода. Это означает, что им придется сознательно обновлять до более новой версии, что и требуется для производственного кода.

Ответ 4

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

Я использую hg, а не git, но все мои проекты Django клонируются из одного и того же базового "шаблона проекта", который имеет служебные скрипты, базовый общий набор INSTALLED_APPS и т.д. Это означает, что когда я вношу изменения в этот шаблон проекта, я могу легко объединить эти общие обновления в существующие проекты. Это не совсем то же самое, что вы планируете, но похоже. Иногда вам приходится иметь дело с конфликтами слияния, если вы изменяете ту же область кода в ядре, что вы уже настроили для конкретного клиента.

Ответ 5

После прочтения всех ваших ответов (спасибо!), я решил сначала реорганизовать мою проектную структуру django, чтобы изолировать ядро и мои приложения differents в подпапках приложений. Это делает более чистый проект и настраивает .gitignore в файле разнородных ветвей, что упрощает использование ветвей git для управления разными клиентами и настройками!