Избегайте захламления репозиториев и других действий, которые усложняют управление кодовой базой. Вместо этого используйте лучшие практики, которые помогут упростить работу.
Изучение исходников в репозитории позволяет оценить уровень безопасности приложений. Но если никто не смотрит на код, проблемы будут только расти. К счастью, у GitHub есть свои специалисты по безопасности, которые недавно обнаружили трояна в нескольких репозиториях Git. Его почему-то не заметили сами владельцы этих репозиториев. Хотя мы не можем диктовать другим людям, как управлять своими собственными хранилищами, мы можем учиться на их ошибках. В этой статье мы рассмотрим полезные приёмы работы с репозиториями.
Изучите свой репозиторий
Возможно, это самая важная рекомендация. Независимо от того, самостоятельно ли вы создали репозиторий или вам его передали, важно знать содержимое вашего хранилища. Как минимум, нужно знать основные компоненты кодовой базы, которой вы управляете. Если после нескольких десятков слияний появится случайный файл, вы сможете легко его обнаружить, потому что он вызовет у вас вопросы. Далее вы захотите проверить его, чтобы разобраться, и уже после этого решите его судьбу.
Старайтесь не добавлять бинарники
Git изначально заточен под текстовые файлы, будь то код на C, Python или Java, или JSON, YAML, XML, Markdown, HTML и так далее:
$ cat hello.txt
This is plain text.
It's readable by humans and machines alike.
Git knows how to version this.
$ git diff hello.txt
diff --git a/hello.txt b/hello.txt
index f227cc3..0d85b44 100644
--- a/hello.txt
+++ b/hello.txt
@@ -1,2 +1,3 @@
This is plain text.
+It's readable by humans and machines alike.
Git knows how to version this.Git «не любит» бинарные файлы:
$ git diff pixel.png
diff --git a/pixel.png b/pixel.png
index 563235a..7aab7bc 100644
Binary files a/pixel.png and b/pixel.png differ
$ cat pixel.png
�PNG
▒
IHDR7n�$gAMA��
�abKGD݊�tIME�
-2R��
IDA�c`�!�3%tEXtdate:create2020-06-11T11:45:04+12:00��r.%tEXtdate:modify2020-06-11T11:45:0Данные в двоичном файле не могут быть проанализированы таким же образом, как обычный текст, поэтому, если что-то изменится в двоичном файле, он должен быть перезаписан полностью.
Что ещё хуже, вы сами не можете проверить (прочитать и проанализировать) двоичные данные.
В дополнение к обычным инструментам POSIX вы можете найти двоичные файлы, используя git diff. Когда вы попытаетесь запустить команду diff с параметром --numstat, Git вернёт нулевой результат:
$ git diff --numstat /dev/null pixel.png | tee
- - /dev/null => pixel.png
$ git diff --numstat /dev/null file.txt | tee
5788 0 /dev/null => list.txtЕсли вы-таки рассматриваете возможность добавления бинарных файлов в свой репозиторий, остановитесь и подумайте. Если некий двоичный файл генерируется в процессе сборки, то зачем добавлять его в свой репо? Если вы всё же решите, что имеет смысл сделать это, убедитесь, что вы в файле README или аналогичном месте описали, почему храните бинарники и каков протокол их обновления. Обновления должны выполняться экономно, поскольку при каждом изменении, которое вы вносите в двоичный объект, пространство для его хранения удваивается.
Сторонние библиотеки должны оставаться сторонними
Хотя одним из многих преимуществ открытого исходного кода является то, что вы можете свободно использовать и распространять код, который вы не писали, есть много веских причин не размещать стороннюю библиотеку в своем собственном хранилище. Прежде всего, вам придётся самостоятельно проверять весь этот код и его дальнейшие обновления, чтобы убедиться в надёжности библиотеки. Во-вторых, когда вы копируете сторонние библиотеки в репозиторий Git, это смещает фокус с основного проекта.
Для управления внешними зависимостями используйте Git Submodule.
Не используйте git add «вслепую»
Если ваш проект успешно скомпилирован, не поддавайтесь желанию использовать команду git add. (где «.» — это текущий каталог например). Это особенно важно, если вы не компилируете свой проект вручную, а используете IDE для управления своим проектом. Может быть чрезвычайно сложно отследить, что было добавлено в ваш репозиторий, когда вашим проектом управляет IDE. Поэтому важно добавлять только то, что вы сами создали и подготовили для добавления, а не какой-либо новый объект, который загадочным образом появился в папке вашего проекта.
Так что, прежде чем запускать git add, просмотрите, что будет добавлено в репозиторий. Если вы видите незнакомый объект, выясните, откуда он и почему он всё ещё находится в каталоге вашего проекта после выполнения команды make clean (или эквивалентной команды).
Используйте Git ignore
Типичный каталог любого проекта содержит множество скрытых файлов, метаданных и ненужных артефактов. Вам лучше игнорировать эти объекты: чем больше их будет, тем больше вероятность того, что вам будет мешать этот «мусор» и вы пропустите что-то важное или опасное.
Файл gitignore даёт возможность отфильтровать лишнее. Github.com/github/gitignore предлагает несколько специально созданных шаблонов gitignore, которые вы можете загрузить и разместить в своём проекте. Gitlab.com, например, предлагал такие шаблоны ещё несколько лет назад.
Модерируйте изменения кодовой базы
Когда вы получаете запрос на слияние или pull-запрос, либо вам присылают патч по электронной почте, вам стоит убедиться, что там всё нормально. Ваша задача — изучить новый код, поступающий в вашу кодовую базу, и понять, что он делает. Если вы не согласны с его реализацией или, что ещё хуже, не понимаете эту реализацию, напишите отправителю сообщение и попросите разъяснений. Нет ничего зазорного в том, чтобы изучать новый код, который претендует на место в вашем проекте. Более того, вы делаете это на благо ваших пользователей: они в этом случае будут чётко понимать, какие изменения вы принимаете и почему.
Возьмите на себя ответственность
Обеспечение безопасности программного обеспечения с открытым исходным кодом — это работа сообщества. Изучайте кодовую базу, не поощряйте беспорядок и не игнорируйте потенциальные угрозы безопасности в клонированных вами репозиториях. Git — мощный инструмент, но это всего лишь компьютерная программа, так что ответственность за управление репозиториями в конечном счёте лежит на вас.
На правах рекламы
Эпичные серверы — это виртуальные серверы на Linux или Windows с мощными процессорами семейства AMD EPYC и очень быстрыми NVMe дисками Intel. Расходятся, как горячие пирожки!
Автор: Mikhail
