Никто здесь не сможет дать вам «лучший» способ с такой ограниченной информацией.
Как и в случае многих других распределенных систем управления версиями, решение о том, как вы собираетесь публиковать свои проекты (много веток в одном репозитории или несколько репозиториев с одним / несколькими ветвями в каждом), в значительной степени независимо. из наиболее важных вопросов общего управления историей (как вы будете обрабатывать историю, которую записывает Git).
Я бы начал с определения того, какие биты данных и истории должны быть общими для всех проектов. Заглядывая вперед, история повлечет за собой не только то, что произошло в прошлом, но и то, что вы ожидаете в будущем.
Звучит так, как будто вы можете захотеть иметь базовый набор файлов, который является общим для всех ваших проектов, а затем иметь некоторые файлы / изменения для каждого проекта, расположенные поверх базового набора файлов. Как диаграмма истории это может выглядеть так:
a1--a2--a3 customer-a
/
o--o--o base
\
b1 customer-b
В дальнейшем, возможно, будет достаточно внести изменения на «основе» и просто объединить их с филиалами клиентов:
a1--a2--a3--a4------a5 customer-a
/ / /
o--o--o--o--o--o--o--o----o base
\ \ \
b1----------b2--b3--b4 customer-b
Или, может быть, вы хотите «плавать» специфичные для клиента изменения поверх базовых изменений с помощью чего-то вроде git rebase:
Rebase customer changes on top of four new base changes:
a1--a2--a3
/ a1'--a2'--a3' customer-a
/ /
o--o--o--o--o--o--o base
\ \
\ b1' customer-b
b1
Another change for B, and two more changes in base:
a1'--a2'--a3'
/
/ a1''--a2''-a3'' customer-a
/ /
o--o--o--o--o--o--o--o--o base
\ \
\ b1''--b2' customer-b
\
b1'--b2
Вы можете интерпретировать каждую из вышеперечисленных меток (base, customer-a, customer-b) как ветки, но вы также можете легко опубликовать каждую из них как отдельную ветку в отдельных репозиториях без потери функциональности (хотя вы можете хочу разработать и протестировать с рабочим репозиторием, у которого есть вся история).
В зависимости от характера установок проекта / клиента, данные, специфичные для проекта, могут даже не иметь отношения к базовому коду / данным. Если проекты не требуют изменений в базовых файлах (например, все настройки выполняются в файлах конфигурации, которых нет в самой базе), то вы можете сохранить простые линейные истории (ветви) для конфигурации каждого проекта вместе со всеми история, которую вы любите (ветви / теги) для базовых файлов. Затем для каждой установки вы можете проверить базовую и специфическую для проекта конфигурацию и настроить ее на выполнение.
Возможно, вы даже решите сохранить историю каждого проекта полностью независимой и просто применять исправления по мере необходимости для различных проектов (но на самом деле это означает, что вы теряете большую часть преимуществ от использования мощной системы контроля версий). Вы все еще можете публиковать такой набор «несвязанных» веток в одном репозитории (как вы действительно публикуете, не зависит от того, как вы управляете историей).
Какой путь вы выберете, зависит от того, как вы хотите управлять историей.
- Вы хотите, чтобы отдельные, отличающиеся от клиентов изменения были на кончиках истории?
- Будет ли несколько человек иметь доступ к репозиториям?
- Переписывание истории (например, с rebase) может быть болезненным для нескольких пользователей или даже для нескольких рабочих репозиториев одного пользователя.
- Насколько взаимосвязаны специфичные для проекта изменения и базовый код / данные?
- Связаны ли некоторые проекты с другими проектами (поделиться большинством изменений)?
- Существует ли инструмент (StGit, TopGit, Guilt и т. Д.), Который может помочь в управлении историей каждого проекта удобным способом?
Помимо простого управления историей, вам также необходимо учитывать возможности вашего поставщика услуг Git (например, GitHub, git.or.cz, пользовательская установка gitorious / gitosis /… и т. Д.). Если у вас есть несколько разработчиков и вы хотите ограничить их работу над определенными проектами / клиентами, вам, возможно, придется публиковать их в нескольких репозиториях (если используемая вами служба Git не разрешает разрешения для каждой ветви). Но управление историей - это та часть, которую лучше всего понять правильно. Вы всегда можете изменить способ публикации своей истории, гораздо труднее переписать опубликованную историю.
Мой советчитать как можно больше документации и принимать самостоятельные решения. Руководство пользователя Git - хорошее место для начала. Мне особенно понравились Git для компьютерных ученых и Git снизу вверх для понимания Git изнутри. Твердое владение внутренностями Git действительно помогает вам понять как (концептуально) простое ( git merge ), так и более сложное ( git cherry-pick , git rebase [-i] ) Команды Git.