Ответ 1
Хорошо, поэтому я действительно придумал лучшее решение этой проблемы. Мое предыдущее решение, в котором участвовал второй репозиторий git, быстро стал проблематичным из-за размера файлов sqlite, с которыми я работал; git не может обрабатывать большие файлы. Я исследовал различные способы улучшения git способности обрабатывать файлы (например, git-bigfiles, git-annex), но ничего, казалось, не справлялось с моей ситуацией.
Ответ: символические ссылки.
N.B. Это решение довольно специфично для Unix, но вы, вероятно, сможете переработать его для не-Unix-систем.
Проблема №1: убедитесь, что данные никогда не отправлены в удаленный репозиторий.
Это было легко. Как и в моем предыдущем решении, я храню данные вне репозитория.
Root-Directory/
My-Project/
.git/
Source-Code-and-Stuff/
My-Project-Data/
A-Big-Sqlite-File.sqlite
Поскольку файлы данных не находятся в репозитории, нет необходимости беспокоиться о том, что они индексируются с помощью git.
Проблема №2: Различные ветки должны ссылаться на разные версии данных.
Здесь появляются символические ссылки. Симлинная ссылка - это ярлык для файла, поэтому идея заключается в размещении символической ссылки на файл данных внутри репозитория. Символы индексируются git (и они очень малы), поэтому разные ветки могут иметь разные символические ссылки.
Чтобы объяснить это, давайте возьмем примерный проект, который имеет текущую версию (1.1) в ветке master; и новую версию (1.2) в ветке версия-1.2. Для простоты этот проект имеет только один файл данных: Data.sqlite.
Файл данных хранится в каталоге My-Project-Data, упомянутом выше, и версируется в файловой системе следующим образом:
My-Project-Data/
v1.1/
Data.sqlite
v1.2/
Data.sqlite
Файл данных добавляется в репозиторий с помощью символической ссылки:
My-Project/
.git/
Source-Code-and-Stuff/
Data-Symlink.sqlite
В ветке master Data-Symlink.sqlite
../../My-Project-Data/v1.1/Data.sqlite
а в ветки версия-1.2 -
../../My-Project-Data/v1.2/Data.sqlite
Итак, когда начинается разработка версии 1.3, следующий bash script будет устанавливать все:
# Get to the root directory
cd path/to/Root-Directory
# Enter the data directory
cd My-Project-Data
# Make a directory for the new version and enter it
mkdir v1.3
cd v1.3
# Copy the new sqlite file into it
cp ~/path/to/data/file.sqlite Data.sqlite
# Move to the project directory
cd ../../My-Project
# Create a new branch
git checkout -b version-1.3
# Move to the source code directory and delete the current symlink
cd Source-Code-and-Stuff
rm Data-Symlink.sqlite
# Create a symlink to the new data file
ln -s ../../Project-Data/v1.3/Data.sqlite Data-Symlink.sqlite
# Commit the change
cd ../
git add Source-Code-and-Stuff/Data-Symlink.sqlite
git commit -m "Update the symlink"
Заключение
Очевидно, это не идеальное решение. Если вы работаете с командой, всем в команде должны быть одинаковые относительные каталоги - символические ссылки - относительные пути, поэтому абсолютный путь к Root-Directory может измениться, но My-Project и My-Project-Data must. Но мое личное мнение заключается в том, что выгоды перевешивают это незначительное оговорку. В фактическом проекте я использую эту технику, у меня есть файл sqlite размером 800 МБ для данных и возможность переключаться между ветвями в реальном времени и развитием, и мой проект автоматически обновляет файл данных бесценным.