Отслеживайте файлы локально, но никогда не позволяйте их отправлять в удаленный репозиторий - PullRequest
20 голосов
/ 04 марта 2012

Я работаю над проектом, который предполагает использование очень чувствительных данных, и мне было поручено передавать эти данные только онлайн через пользовательскую систему передачи файлов. Сам проект находится под контролем исходного кода git и включает файл sqlite, содержащий конфиденциальные данные.

До этого момента я просто игнорировал файл sqlite через файл gitignore, что предотвращает его передачу в удаленный репозиторий. Однако сейчас я достиг точки в проекте, где у нас есть как живая версия, так и версия для разработки, и тот факт, что данные не отслеживаются локально, очень затрудняет использование ветвей.

Итак, мой вопрос: есть ли способ для меня локально отслеживать файл sqlite, чтобы я мог иметь разные версии данных в разных ветвях, но никогда не отправлять их в удаленный репозиторий?

После прочтения этого вопроса я подумал о том, чтобы иметь только локальные development ветви, которые используют разные gitignore файлы, но тот факт, что git merge в удаленно используемых ветвях также слияние изменений в файле gitignore быстро станет громоздким.

Ответы [ 3 ]

7 голосов
/ 08 мая 2012

Хорошо, так что я действительно нашел лучшее решение этой проблемы. Мое предыдущее решение , которое включало второй репозиторий git, быстро стало проблематичным из-за размера файлов sqlite, с которыми я работал;git не может обрабатывать большие файлы.Я исследовал различные способы улучшения способности git обрабатывать файлы (например, git-bigfiles , git-annex ), но, похоже, ничто не могло справиться с моей ситуацией элегантно.

ответ: символические ссылки.

NB Это решение довольно специфично для 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) для мастер филиал;и новая версия (1.2) в ветке version-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

, а в version-1.2 -

../../My-Project-Data/v1.2/Data.sqlite

Так что при разработке по версии1.3 начинается, следующий скрипт bash установит все:

# 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-Проект и My-Project-Data должен существовать в нем.Но мое личное мнение заключается в том, что преимущества перевешивают эту незначительную оговорку.В настоящем проекте я использую эту технику, у меня есть файл sqlite объемом 800 МБ для данных, и я могу переключаться между оперативной ветвью и ветвями разработки, и мой проект автоматически обновляет файл данных. Это бесценно.

3 голосов
/ 04 марта 2012

Отслеживание файлов локально, но никогда не позволяйте их отправлять в удаленный репозиторий

Вы не можете, на самом деле.

Git отслеживает снимки вашего хранилища .Вот эти снимки git pushed и git pulled - если файл находится в снимке, он (как правило) будет включен в git push и т. Д.

Ваш лучший вариант - использовать git submoduleдержать конфиденциальные данные. Этот вопрос входит в это решение в некоторых деталях.

0 голосов
/ 05 марта 2012

Я хотел потратить секунду, чтобы объяснить свое решение этой проблемы:

Я создал корневой каталог для своего проекта: MyRootDirectory. Внутри MyRootDirectory у меня есть две директории с именами MyProject и MyProjectData. И MyProject, и MyProjectData являются репозиториями git, где MyProject имеет удаленный аналог на github, а MyProjectData - локальный репозиторий. В моем файле проекта (я использую XCode) у меня есть ссылки на файлы данных, используя следующий путь: ../MyProjectData/MyDatabase.sqlite.

Этот результат позволяет мне иметь ветки разработки и master как для данных, так и для проекта; данные включены в построенный продукт, потому что они существуют в индексе проекта, но они никогда не передаются в удаленный репозиторий, поскольку в его локальный репозиторий включается только его путь. Магия.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...