git-annex существует уже довольно долгое время, но никогда не набирал оборотов. Git LFS довольно молод и уже поддерживается GitHub, Bitbucket и GitLab.
Оба инструмента обрабатывают двоичные файлы в репозиториях git. С другой стороны, GitLab, похоже, заменил git -annex Git LFS в течение одного год.
Они решают одну и ту же проблему.
Позвольте мне начать с pro/con, тогда я перейду в технические различия.
git -annex работает, создавая символическую ссылку в вашем репо, которая будет совершена. Фактические данные сохраняются в отдельный бэкэнд (S3, rsync и MANY другие). Это написано в haskell. Поскольку он использует символические ссылки, пользователи Windows вынуждены использовать приложение совершенно по-другому, что делает кривую обучения выше.
Пишутся файлы указателя. A git -lfs api используется для записи BLOB в lfs. Из-за этого требуется специальный сервер LFS. Git lfs использует фильтры, поэтому вам нужно только настроить lfs один раз и снова, когда вы хотите указать, какие типы файлов вы хотите нажимать на lfs.
Основным преимуществом приложения git является то, что вы можете выбрать, какой файл вы хотите загрузить.
Вы все еще знаете, какие файлы доступны благодаря символическим ссылкам.
Например, предположим, что у вас есть каталог, полный файлов ISO. Вы можете перечислить файлы, а затем решить, какой из них вы хотите загрузить, набрав: git annex get my_file.
Другим преимуществом является то, что файлы не дублируются в вашем контроле. В LFS файлы lfs представлены как объекты git как в .git/lfs/objects, так и в вашем рабочем репозитории. Итак, если у вас есть 20 ГБ файлов LFS, вам нужно 40 ГБ на вашем диске. Хотя с приложением git файлы имеют символическую привязку, поэтому в этом случае требуется только 20 ГБ.