Git vs SVN с нетекстовыми файлами / большими проектами

Question

Я изучал Git последние недели или около того, и мне действительно нравится, как он работает по сравнению с SVN.Основная причина, по которой я стремлюсь полностью перейти на это, заключается в том, что слияние, по-видимому, намного проще с небольшим количеством конфликтов, и тот факт, что я могу совершать локально.Это способствует использованию многих веток (например, ветка за тикет / вопрос / задание / и т. Д.), А также продвигает много коммитов.Я использую ветки только в том случае, если мне нужно в SVN (поскольку слияния часто вызывают конфликты), и я фиксирую только тогда, когда уверен на 100%, что проблема устранена (вместо добавочных коммитов, что было бы лучше).

Теперьодна проблема, которую я имею о git, поскольку я читал его, касается не текстовых файлов / больших проектов.Например, я работаю над игровым проектом, который в настоящее время контролируется в SVN.Теперь в игровом проекте будет много нетекстовых файлов, таких как art, sound и другие двоичные файлы, и некоторые из них могут стать довольно большими.Насколько хорошо Git обрабатывает нетекстовые файлы / большие двоичные файлы?Какие соображения я должен иметь в виду, если я хочу перенести такой проект на git?

Answer 1

Одно из больших отличий в том, как Git хранит данные по сравнению с другими системами контроля версий, заключается в том, что Git сохраняет содержимое файла полностью как один объект. Это означает, что каждая версия каждого файла существует как полный файл в вашем хранилище (хотя он очень сжат). Таким образом, в то время как другие VCS хранят различия / дельты между двумя версиями, и, как таковые, обрабатывают двоичные и текстовые файлы по-разному (поскольку двоичные файлы не так трудно различимы), Git просто обрабатывает их все одинаково.

Таким образом, работа с двоичными файлами в Git ничем не отличается от использования любого другого типа файлов. Вам просто нужно иметь в виду, что управление версиями очень больших файлов значительно увеличит размер вашего хранилища (поскольку каждая отдельная версия этого большого файла сохраняется, как есть, даже если фактическое двоичное изменение было небольшим). Однако сжатие Git творит чудеса и обычно не замечает этого. Особенно, если вы говорите только об активах программы, у вас, вероятно, не будет никаких трудностей.

Answer 2

Добавление ответа @ poke

В настоящее время я заядлый пользователь Git, но, работая над огромным проектом, в котором нужно было обработать множество бинарных файлов, в основном zip-файлов, я обнаружил, что SVN болееэффективнее, чем Git.Размер репозитория Git быстро раздулся, а размер аналогичного репозитория SVN не сильно изменился.Клонирование такого огромного репозитория Git, особенно в географически распределенных местах, было кошмаром.Git также не имеет функции частичного клонирования, что мы постоянно делаем в SVN - извлечение только определенной папки.В git есть частичная проверка, но вам все равно придется клонировать весь репозиторий.

Обратите внимание, что то, является ли файл двоичным или нет, не влияет на объем пространства хранилища, используемого для хранения изменений в этом файле.и не влияет на объем трафика между клиентом и сервером.В целях хранения и передачи Subversion использует метод сравнения, который одинаково хорошо работает с двоичными и текстовыми файлами;это совершенно не связано с методом сравнения, используемым командой 'svn diff'.

http://subversion.apache.org/faq.html#binary-files

Учитывая развитые инструменты SVN администратора sys (Git также улучшился за эти годы,но я чувствую, что SVN все еще имеет преимущество в этом аспекте) Я думаю, что было бы разумно иметь сервер SVN с, вероятно, git-svn repo для локальной разработки.

Есть что-то, что называется git-bigfiles - этовилка из мерзавцаНе уверен, насколько он зрелый.Вы можете оценить это.Но тот факт, что он существует, показывает, что Git не обязательно хорош в обработке больших файлов.

Answer 3

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

Answer 4

git отлично обрабатывает двоичные файлы. Вам просто нужно помнить, что все версии двоичного файла хранятся локально. Если двоичный файл (скажем, изображение) часто меняется, вы в конечном итоге будете заполнять локальное пространство всей версией изображения.