Ответ 1
Лучшая практика для хранения файлов .jar в VCS (SVN, Git,...): do not.
Это может иметь смысл в CVCS (централизованный VCS), такой как SVN, который может обрабатывать миллионы файлов независимо от их размера.
Это не в DVCS, особенно в стиле Git (и его пределы):
- Двоичные файлы не соответствуют требованиям VCS.
- По умолчанию клонирование репо DVCS даст вам всю историю, со всеми версиями jar.
Это будет медленным и займет много дискового пространства, неважно, насколько хорошо сжаты эти банки.
Вы можете попытаться сыграть с мелким клонированием, но это очень непрактично.
Используйте второй репозиторий, например Nexus, для хранения этих банок и только ссылку a txt (или файл pom.xml для Maven), чтобы получить правильную банку версии.
Репозиторий артефакта более адаптирован для целей управления распространением и выпуском.
Все, что сказано, если вы должны хранить jar в репозитории Git, я бы сначала рекомендовал хранить их в сжатом формате (который является стандартным форматом для jar: см. Создание файла JAR)
Как сжатый, так и несжатый формат будут обрабатываться как двоичные с помощью Git, но, по крайней мере, в сжатом формате клонирование и проверка займет меньше времени.
Однако многие потоки упоминают возможность хранить банку в несжатом формате:
Я использую некоторые репозитории, которые вносят в них обычные картотеки размером 50 МБ.
Я убедил их не сжимать tarballs, а Git делает довольно приличную работу по дельта-сжатию между ними (хотя для этого требуется довольно много ОЗУ).
У вас есть еще дефинированный объект на Git здесь:
- Это не имеет значения, если вы имеете дело с двоичным или текстовым текстом;
- Дельта не обязательно относится к одному и тому же пути в предыдущей редакции, поэтому даже новый файл, добавленный в историю, может храниться в изолированной форме;
- Когда используется объект, хранящийся в дефинированном представлении, он будет стоить больше, чем использование одного и того же объекта в сжатом базовом представлении. Механизм деления включает компромисс, учитывающий эту стоимость, а также эффективность использования пространства.
Итак, если клоны и проверки не являются обычными операциями, которые вы должны выполнять каждые 5 минут, сохранение jar в несжатом формате в Git имеет смысл, потому что:
- Git будет сжать/вычислить дельта для этих файлов
- В вашем рабочем каталоге вы получите несжатую банку, которая может быть затем загружена быстрее.
Рекомендация: несжатый.