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

Question

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

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

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

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

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

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

Является ли файл .gitignore специфичным для ветви? YES

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

Ju.

Answer 1

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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