Pull to refresh

Comments 14

Забавно, что в качестве примера к "старайтесь не добавлять бинарники" выбран png.

Старайтесь не добавлять бинарники

Для решения этого вопроса уже давно существует Git LFS

Обновления должны выполняться экономно, поскольку при каждом изменении, которое вы вносите в двоичный объект, пространство для его хранения удваивается.

Насколько я помню, это не так. Если в бинарнике изменилась небольшая часть, то в паках git не будет сохранять обе версии целиком, будет храниться только diff. А без паков дублируются не только бинарные объекты, но и текстовые тоже.


Хранить в репозитории бинарники — плохая идея, но не по соображениям занимаемого места.

> Хранить в репозитории бинарники — плохая идея, но не по соображениям занимаемого места.

Отчасти и по соображениям занимаемого места (скорее — времени клонирования, место сейчас дешевое), это зависит от типа бинарника — например, если в картинке поменять один пиксель, новый PNG файл может иметь очень мало общего со старым (из-за встроенной компрессии), и никакой diff не поможет. Но, полностью согласен, место — далеко не самое важное.
Для управления внешними зависимостями используйте Git Submodule.

Довольно сомнительный совет, который сильно усложнит работу с репо для всех.


В качестве альтернативы я бы порекомендовал https://github.com/ingydotnet/git-subrepo — тоже не идеал, но проблем с ним намного меньше.

Данные в двоичном файле не могут быть проанализированы таким же образом, как обычный текст, поэтому, если что-то изменится в двоичном файле, он должен быть перезаписан полностью.

В гите тестовые файлы тоже перезаписываются полностью.

Честно говоря, статья выглядит перепечаткой человека, который сам с гитом мало работал.

Нужно ли в репозиторий добавлять gitignor?

Скорее да, к тому же есть готовые шаблоны для разных языков. А вот надо ли добавлять в гитигнор служебный каталог IDE — это уже весьма дискусионный вопрос

Конечно же, надо. Просто не в .gitignore конкретного репо, а в ~/.gitignore, путь к которому надо задать через git config --global core.excludesFile.

Одно другому не мешает.
Глобальный gitignore делается самим разработчиком и зависит от ide и других личных привычек.
Проектный gitignore зависит от структуры проекта и его специфики.

Я бы необходимость использовать .gitignore вынес на первое место.

И самое главное о чем автор не упомянул — это всякие секреты (пароли и другие реквизиты доступа). Их нужно было отдельно упомянуть и четко прописать работу сними (и да — все это должны быть добавлено в .gitignore)

Я бы сказал так: «для управления внешними зависимостями используйте пакетные менеджеры, и только в крайнем случае — git submodules».

Sign up to leave a comment.