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

Question

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

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

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

Является ли филиал хорошим способом справиться с этим делом?

Что касается файла настроек, как бы вы поступили дальше?Не могли бы вы .gitignore указать файл настроек для конкретного клиента и добавить файл settings.xml.sample, например, для репозитория?

Кроме того, есть ли какой-либо способ предотвратить объединение некоторых файлов в master ?(но передан в филиал заказчика).Например, я хотел бы сохранить некоторые данные клиента в филиале customer, но не могу передать их в master.

Зависит ли файл .gitignore от конкретной ветви? ДА

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

Джу.

Answer 1

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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