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

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

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

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

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

Ответ 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 МБ для данных и возможность переключаться между ветвями в реальном времени и развитием, и мой проект автоматически обновляет файл данных бесценным.

Ответ 2

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

Ты не можешь, правда.

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

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

Ответ 3

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

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

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