GitHub анонсировал хранилище для больших файлов (LFS)

    Недавно на GitHub появилась приятная новость об анонсе хранилища для больших файлов:

    «Мы рады представить Git Large File Storage (LFS) как более практичный путь работы с большими бинарными файлами, такими как аудифайлы, графика, видео и т.п. в Git.
    Git LFS — это новое расширение с открытым исходным кодом, которое заменяет большие файлы на текстовые ссылки в Git, в то время как содержимое файлов сохраняется на удаленных серверах как GitHub.com или GitHub Enterprise»
    GitHub.com


    image

    О проекте


    Проект Git LFS представляет собой набор фильтров и хуков которые обеспечивают работу с большими файлами вместо хранения в Git напрямую. LFS отслеживает Git-операции с большими файлами через фильтры clean и smudge, в результате файлы отправляются не на удаленный гит-репозиторий, а автоматически сохраняются на стороннем сервере с помощью LFS API, так же автоматически происходит загрузка файлов при загрузке ветки из удаленного git-репозитория.

    Подробнее прочитать о том, что из себя представляют фильтры clean и smudge можно в официальном руководстве по Git

    Как это работает


    1. Нужно скачать и установить расширение для Git отсюда.
    2. Выбрать тип файлов для хранения в LFS (или напрямую отредактировать .gitattributes):
          git lfs track "*.psd"
      
    3. Далее можно работать как и обычно в Git: сначала add, потом commit и push. Примерно так:
          git add file.psd
          git commit -m "Add design file"
          git push origin master
      


    Заключение


    В общем, это самое прекрасное, то что работа с LFS не отличается от работы с обычными текстовыми файлами в репозитории.

    Полная поддержка LFS в каждом репозитории на GitHub, если верить анонсу, появится в течение нескольих месяцев.

    Однако доступ можно получить уже сейчас через форму получения раннего доступа: Want to version large files with GitHub?

    Сайт проекта: Git LFS
    Считаете ли вы это нововведение полезным?

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 18
    • 0
      Не понял вопрос в опроснике: «Нет, хранить бинарные файлы надо отдельно от Git».
      Так ведь бинарные файлы итак будут храниться на отдельном сервере. Или я что-то перепутал?
      • 0
        Имелось ввиду что в отдельной папочке и передавать архивом, или что-то подобное.
      • 0
        Не пользуюсь ни Git, ни GitHub


        А где «Пользуюсь Git, не пользуюсь GitHub»? Сервер, же доступен и без Гитхаба.
        • +1
          Так есть же пункт «имею своё отличное мнение на этот счёт»)
        • +3
          В голосовалку можно еще добавить «Пользуюсь другим аналогичным расширением (git-fat, git-annex, ...)».
          • 0
            Так это не мешает ведь считать что LFS будет полезной фишкой для гитхаба? Просто опрос в виде или/или, поэтому я так его сформировал. Понятно что, есть сотни способов решить проблему large files. И git-fat и git-annex это тоже крутые решения.
            • 0
              Хорошо бы ещё добавить сравнение с git-annex…
              • +3
                Из моего опыта использования:

                У git-annex была проблема с git-submodules (не знаю как сейчас). Поэтому я выбрал git-fat, хотя git-annex тогда был более известным/популярным/стабильным.

                У git-annex много back-ends для хранения файлов, у git-fat фактически только куда может закачивать/скачивать rsync.

                git-fat написан на питоне, есть пакет в pip.

                git-annex написан на хаскеле, и на Windows тащит за собой хаскел-рантайм плюс часть MSYS (у меня были с ним какие-то трудности, но сейчас уже не помню в чём именно).
            • 0
              Ммм, мне одному показалось, или гитхаб начали косить под корпорацию зла?:)

              Upd.Ой, не увидел ссылку на сорцы.
              • +1
                Там будет версионирование, это очевидно, но вопрос в следующем. 1 ГБ места считается по последним версиям или же по всему репозитарию? Если по всему хранилищу, то это действительно мало.
                • 0
                  Every user and organization on GitHub.com with Git LFS enabled will begin with 1 GB of free file storage and a monthly bandwidth quota of 1 GB. If your workflow requires higher quotas, you can easily purchase more storage and bandwidth for your account.
                  • +2
                    Ну это я читал. Вопрос в том, как считается занимаемый размер.

                    Пример.
                    Есть один .psd файл размером 500 мегабайт (ну для примера). Я его залил в LFS. Потом поправил и у меня он теперь весит 600 мегабайт, который я тоже туда запушил. Теперь у меня в LFS две ревизии одного файла. Биллинг будет считать, что у меня 600 мегабайт занято или же попросит докупить еще места, т.к. теперь хранится 1100 Мб? Вот что интересно.

                    Вопрос актуальный, т.к. на проектах, в которых будет использоваться LFS, для часто меняющихся файлов, место закончится очень быстро.
                    • 0
                      Такие тонкости у них не освещены еще, к сожалению, но с учетом того что в месяц bandwidth составляет 1ГБ, то скорее всего и подсчет места они производят по тому же принципу — сумма размеров всех версий файлов.

                      Об этом косвенно свидетельствует и вот это
                      You can purchase additional data packs. Each pack costs $5 per month, and provides 50 GB of bandwidth and 50 GB for storage.
                      help.github.com/articles/purchasing-additional-storage-and-bandwidth-for-a-personal-account


                      Т.е. не просто так они сразу предлагают подкупить 50ГБ)

                      Но надо не забывать, что бы пользоваться github в коммерческих целях, приходится покупать платный аккаунт хотя бы за 7$ с 5 приватными репозиториями, так что не удивительно что за нормальный LFS они тоже потребуют определенную сумму.
                      • 0
                        С каких пор нельзя пользоваться github в коммерческих целях без платного акка? Где в ToS пункт об этом?
                        • +2
                          Я немного неправильно выразился. Конечно если публикация открытого кода соответсвует коммерческим целям проекта, то в таком случае нет никаких помех. Но публикуя код вы разрешаете его просмотр и копирование, об этом есть пункт в ToS.
                • 0
                  А как все это и ограничение на 1 гиг трафика увязано с гитхаб-страницами?
                  • 0
                    Судя по всему, в репозитории будут хранится только ссылки на файлы, в таком виде
                    version git-lfs.github.com/spec/v1
                    oid sha256:4d7a214614ab2935c943f9e0ff69d22eadbb8f32b1258daaa5e2ca24d17e2393
                    size 12345
                    (ending \n)


                    Так что, без каких-то хитрых манипуляций этот контент не будет доступен из веба.
                  • –1
                    Не хватает варианта «Нет, хранить бинарные файлы надо в Git».

                    Звучит конечно не для всех логично, но для некоторых проектов такое имеет смысл — для игр например.

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

                    Например в репозитории Unreal Engine 4 все бинарные файлы
                    Epic выкладывали архивом каждый раз для каждого релиза. Было крайне не удобно этим пользоваться — зачекаутил
                    новый комит и тебе нужно выкачать новый архив со всеми файлами и перезаписать все что есть в локальном репозитории (иначе не соберется).

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.