У меня есть некоторые проблемы с выбором подходящей схемы именования для репозиториев GitHub, принадлежащих одному и тому же проекту. Основной репозиторий пакетов зависит от дополнительных репозиториев для создания документации или запуска тестов. Во время разработки на локальном компьютере эти репозитории импортируют друг друга (находящиеся в одном корневом каталоге). Все эти репозитории размещаются на GitHub под крышей «учетной записи организации» для этого пакета, который содержит все репозитории.
Учитывая эту организацию, какое из следующих соглашений об именах является более практичным и эффективным:
Каждый подкаталог имеет префикс проекта (например, https://github.com/pandas-dev , https://github.com/gruntjs):
<project-name> # GitHub organization account
<project-name>
<project-name>-docs
<project-name>-tutorials # contains resources for unit tests
<project-name>-vignettes
Плюсы:
Минусы:
У репозиториев нет общего префикса (например, https://github.com/numpy, хотя несколько смешанные соглашения об именах):
<project-name> # GitHub organization account
<project-name>
docs
tutorials # contains resources for unit tests
vignettes
Плюсы:
Минусы:
Связанный: GitHub Organizations для проекта, охватывающего несколько репозиториев?
Соглашение об именовании каталогов: каталоги представляют собой иерархическую организацию: docs
в <project-name>
, в принципе, документы, связанные с этим проектом. Повторение префикса излишне, затрудняет переименование. Кроме того, это усложняет практическую жизнь с более длинными именами путей (в браузерах графических файлов конец более длинных имен иногда скрыт за ... и вам нужно навести на него курсор, чтобы увидеть полное имя)
Соглашение об именах репозиториев: Репозитории должны быть автономными частями, которые можно клонировать независимо. Здесь важно, чтобы название полностью и недвусмысленно относилось к их содержанию, т.е. <project-name>-docs
включая название проекта.
Логика репозитория в целом должна преобладать: отдельный репозиторий может быть клонирован независимо (например, технический писатель или переводчик может иметь множество разных папок проектной документации, клонированных на его/ее локальном компьютере). Поэтому вариант 1 - с префиксом - будет правильным (если только вы не будете работать с подмодулями или хотите дать дополнительные инструкции для ручной работы).