Мне интересно, существует ли способ управления версиями дерева каталогов между несколькими (не менее 3) Git репозиториями.Одно рабочее дерево, совместно управляемое несколькими репозиториями?
Вот упрощенная версия моего дерева каталогов. В реальной жизни это веб-каталог для сайта Drupal или Joomla.
root/
index.php # code, managed by application repository
configuration.php # secrets, e.g. database password
uploads/ # contains user-supplied data
temp/ # directory of temporary files, not archived
attack.php # attack code or data, unwanted, should be detected
index.php представляет код моего веб-приложения. Только разработчики вносят свой вклад в это. Мы хотим, чтобы он контролировался версиями. Мы хотим полагаться на Git для развертывания на промежуточных и производственных серверах.
configuration.php представляет собой конфигурацию веб-приложения в развернутом виде. Он содержит значения, которые различаются между промежуточными и тестовыми версиями приложения, например. имя базы данных, которую должно использовать приложение. Он также содержит значения, которые являются секретными, например. пароль к базе данных. Мне не нужны эти секреты в репозитории приложений. Вместо этого в репозитории приложений есть копия этого файла с безвредными значениями. Я думаю, что для управления этим файлом мне нужен второй репозиторий, размещенный на сервере, но с ограниченным дистрибутивом.
uploads/ представляет файлы и деревья каталогов, содержащие данные, предоставленные пользователем: их сообщения в блогах, их изображения, их общие файлы. Эти файлы должны быть добавлены в репозиторий приложений не. Тем не менее, я могу захотеть иметь отдельный репозиторий данных, предоставленных пользователем, для их отслеживания. Я мог бы поддержать их, я мог бы использовать репозиторий, чтобы переместить их на другой сервер. Я хочу заметить, добавляет ли злоумышленник файлы, например. с неожиданными расширениями имен файлов, в этот каталог.
tmp/ представляет собой каталог временных файлов, сгенерированных приложением, поскольку он обрабатывает активность пользователя. Это может быть кеш. Я не хочу, чтобы эти файлы находились в любом управлении версиями. Тем не менее, я хочу заметить, добавляет ли злоумышленник файлы, например. с неожиданными расширениями имен файлов, в этот каталог.
attack.php представляет собой новые файлы и изменения в файлах приложений, которые добавляются злоумышленником. Я хочу понять, что они появились. git status отлично подходит для этого, если в репозитории имеется правильный контент.
Мне легко понять, как управлять этим деревом каталогов с помощью одного репозитория приложений. настройте это дерево каталогов с помощью git-dir в другом месте. Я могу посыпать «.gitignore» вокруг, скажем, игнорировать содержимое uploads/ и tmp/. Я могу оставить в репозитории приложений configuration.php.
Я не вижу, как настроить второй репозиторий для управления configuration.php и перезаписать безобидные значения в копии репозитория приложения. Я не вижу, как настроить .gitignore s, который скажет репозиторию приложений посмотреть index.php и проигнорировать uploads/, сообщая репозиторию пользовательских данных, чтобы сделать обратное.
Основополагающее препятствие, по-видимому, состоит в том, что Git предполагает, что рабочее дерево принадлежит только одному репозиторию, и я пытаюсь получить несколько репозиториев для его совместного использования. Итак, есть ли способ поделиться этим, практически, с Гит?
Вопрос Multiple repositories in one directory аналогичен. Я думаю, кто-то утверждает, что это можно сделать с помощью Subversion. Я не вижу ни одного из ответов, говорящих, что это можно сделать с Git.В частности, ответ, который указывает на то, что вы можете указать параметры --git-dir и --working-tree многим командам Git, не говорит о том, как обращаться с различными .gitignore потребностями.
Вопрос Is it possible to manage multiple repositories coherently? есть ответ, который упоминает Repo, который, в свою очередь, упоминает Gerrit. Это интересно, но кто-нибудь использовал их для создания такой структуры, как я?
Альтернативой окроплению .gitignore файлов по рабочему дереву является список путей в файле $GIT-DIR/info/exclude для каждого репозитория. Это позволяет каждому репозиторию игнорировать то, что он хочет игнорировать. Но я обеспокоен тем, что содержимое этих файлов exclude само по себе не будет контролироваться версиями и может не передаваться разработчикам, которые работают над приложением в своих собственных хранилищах.
Какой подход вы рекомендуете?