Что такое хороший рабочий процесс для git-приложения?

Question

Наша команда разработчиков использует git для контроля версий и использует git-annex для хранения больших двоичных файлов (двоичные данные, изображения, тестовые двоичные файлы и т. Д.). Хотя мы смогли его настроить и использовать, у нас были свои проблемы.

Общее действие, которое мы часто выполняем и доставляет нам неприятности:

1. Разработчик 1 добавляет несколько тестов для новой функции и добавляет соответствующие данные для тестов, используя git-annex.

   git add <test-file>
   git annex add <data-file>
   git annex copy <data-file> --to=<remote location(we use s3 if that is relevant)>
   git commit -m 'Tests with data'
   git push
   git annex sync
   

2. Работа проверяется и объединяется (мы используем Github для хостинга и следуем модели разветвления, когда вся работа выполняется разработчиком на своей вилке и объединяется с основным репозиторием посредством запросов Pull)

3. Разработчик 2 выбирает / сливается с апстримом и пытается запустить тесты на своем компьютере.

   git fetch upstream
   git merge upstream/<branch>
   git annex sync
   git annex get
   

Мы часто получаем тестовые данные, которые либо не отслеживаются в git, либо не могут быть загружены из удаленного местоположения.

Что такое хороший способ использовать git-annex в нашем рабочем процессе?

Кроме того, какие еще варианты могут сделать такой рабочий процесс лучше / проще в управлении?

Answer 1

Хорошо, здесь мы идем:

Использование git в приложении v6 вручную:

Сервер1 и Сервер2:

mkdir testdata
cd testdata
git init
git annex init "LocationNameIdentifyer"
git annex upgrade
git remote add OtherServerLocationNameIdentifyer ssh://otherserver.com/thedir

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

git annex sync --content

в обоих местах, если есть файлы в обоих местах, вам нужно сделать

git add --all 

в обоих местах отслеживать текущие файлы как так называемые разблокированные файлы

после

git annex sync --content 

в обоих местах бегом скажем 3 раза

все объединено, и вы можете теперь синхронизировать приложение cron git --content в обоих местах, и оба имеют одинаковые файлы в рабочем дереве, если вы хотите отслеживать новые файлы, которые вы помещали в место, которое вы делаете git add, а не git приложение add git приложение add добавит файлы как так называемые заблокированные файлы, которые делают весь другой рабочий процесс

Answer 2

Это позволит вам иметь репозиторий git "myrepo" с соответствующим ведром S3, в котором хранятся все большие файлы, которые вам на самом деле не нужны в вашем репозитории git.

Настроить репо:

# Clone your repo "myrepo"
git clone [e-mail]:me/myrepo.git
cd myrepo

# Initialize it to work with git-annex.  
# This creates .git/annex directory in the repo, 
# and a `git-annex` metadata branch the tools use behind the scenes.
git annex init                  

# The first time you use the repo with git-annex someone must link it to S3.
# Be sure to have AWS_* env vars set.
# Select a name that is fitting to be a top-level bucket name.
# This creates the bucket s3://myrepo-annexfiles-SOME_UUID.
git annex initremote myrepo-annexfiles type=S3  

# Save the repo updates related to attaching your git annex remote.
# Warning: this does a commit and push to origin of this branch plus git-annex.
# It will ALSO grab other things so make sure you have committed
# or stashed those to keep them out of the commit.
git annex sync    

Добавьте в приложение несколько файлов:

# These examples are small for demo.
mkdir mybigfiles
cd mybigfiles
echo 123 > file1
echo 456 > file2

# This is the alternative to `git add`
# It replaces the files with symlinks into .git/annex/.../SOME_SHA256.
# It also does `git add` on the symlinks, but not the targets.
git annex add file*             

# Look at the symlinks with wonder.
ls -l mybigfiles/file*    

# This puts the content into S3 by SHA256 under the attached to your "special remote":
git annex move file* --to myrepo-annexfiles 

# Again, this will do a lot of committing and pushing so be prepared.
git annex sync                  

С git-annex в репозитории git будут просто мертвые символические ссылки, которые содержат значение SHA256 для реального содержимого файла, а инструменты будут сбрасывать большие файлы.

Позже, когда кто-то другой клонирует репо и хочет файлы:

git clone myrepo
cd myrepo

# Enable access to the S3 annex files.
# NOTE: This will put out a warning about ssh because the origin above is ssh.
# This is ONLY telling you that it can't push the big annex files there.
# In this example we are using git-annex specifically to ensure that.
# It is good that it has configured your origin to NOT participate here.
git annex enableremote myrepo-annexfiles

# Get all of the file content from S3:
git annex get mybigfiles/*

Когда закончите с файлами, верните место на диске:

git annex drop mybigfiles/*

Проверьте, где все на самом деле живет, а что где скачивается:

git annex whereis mybigfiles/file*

Обратите внимание, что git-application - очень гибкий инструмент. Я обнаружил, что получение более простого рецепта для общего случая требует небольшого изучения документации. Надеюсь, это поможет другим.