Многоуровневый контроль версий?

#git #svn #version-control #layered

#git #svn #контроль версий #многоуровневый

Вопрос:

Я ищу систему контроля версий, которая имеет определенную функцию, которую я не уверен, что называть, кроме «многоуровневой». По сути, то, что я ищу, — это иметь «основной» проект «A». Допустим, у него такая структура каталогов:

 A/
|
 -config/
|
 -src/
|
 -data/
  

A — это то, где находится большая часть кода, но я не хочу его развертывать A , A это скорее шаблон для того, что я действительно хочу развернуть… Итак, я хочу иметь проект B , в котором есть содержимое A (должно быть доступно только для чтения), но наложенное на мои локальные данные, такие как конфигурации и данные, относящиеся к B .

Таким образом, я могу вносить изменения в A , затем «обновлять» в B , что внесло бы изменения в ядро, но не повлияло бы на конкретные настройки проекта.

Если бы config и data были пустыми, я мог бы просто исключить их из A и играть в игры с символическими ссылками и тому подобным, но я хочу, чтобы они также могли содержать некоторые основные конфигурационные файлы и файлы данных.

Существует ли система контроля версий, которая поддерживает подобные вещи? Если да, то как это работает?

Комментарии:

1. Это не то, что обычно делают системы контроля версий (или должны делать IMO). Однако вы можете сделать это на уровне своего кода. Довольно часто бывает иметь каталог материалов, которые затеняют основную функциональность / стили / и т.д.

2. Хотя, если вы просто ищете способ иметь разные конфигурации для разных развертываний одной и той же кодовой базы, по SO уже есть множество вопросов.

Ответ №1:

Похоже, вы ищете концепцию «ветки» с ветвями развертывания, где вы вносите изменения в конфигурацию, но не основные изменения. Затем вы можете время от времени объединять основные изменения в свои ветви развертывания.

Любая современная система контроля версий кода поддерживает ветви.

Комментарии:

1. Кажется, это работает отлично. В прошлом я не часто использовал ветки, думаю, пришло время начать 🙂