Как организовать и классифицировать небольшие проекты в GitHub?

Question

Я новичок в разработке и пытаюсь загрузить небольшие проекты, над которыми работал мой профиль GitHub. Эти проекты не зависят друг от друга.

Моя проблема в том, что некоторые из них представляют собой небольшие проекты с одним файлом. Похоже на мини-проблемы, которые я решил. Поэтому я собираюсь объединить их вместе в одном репо под названием «Программирование на Python», например.

Это хорошая практика?

• Если да, то как я должен идти об этом в Git, и как я могу все еще есть README файл с указанием для каждого мини-проекта.

• Если нет, что бы вы посоветовали сделать?

Answer 1

GitHub будет отображать файл README для каждой папки, которую вы посещаете, поэтому при использовании только одного репозитория одним из решений будет создание одной подпапки для каждого «подпроекта», который может иметь свой собственный файл README.

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

Некоторые вещи, чтобы рассмотреть для этого решения:

• Если проекты не зависят от другого, они все еще относятся к другому? Например, являются ли эти проекты частью более сложной задачи программирования, например Project Euler, и вы просто собираете все свои решения? Тогда один репозиторий может иметь больше смысла.
• Какова вероятность того, что отдельные проекты перерастут в более крупные вещи? Многие вещи начинаются очень мало, но в конечном итоге могут превратиться в реальные вещи, которые оправдывают их собственный репозиторий. В этот момент вы можете заставить других внести свой вклад.
• Имеет ли смысл, чтобы эти отдельные файлы делились историей? Могут ли файлы даже редактироваться после их завершения? То есть это просто сборник готовых вещей, или они на самом деле продолжаются эксперименты?

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

К сожалению, пользовательский интерфейс GitHub не предназначен для небольших одноразовых проектов. Список репозитория для этого просто неорганизован. Если вы решили использовать небольшие проекты, я советую вам добавить префикс для категоризации в вашем профиле GitHub, чтобы вы знали, что это значит.

Хорошая альтернатива для одноразовых проектов, особенно когда это всего лишь один (или несколько) файлов: Gists. Гисты рождаются как способ обмена фрагментами кода, но под капотом каждый Gist фактически является полным хранилищем Git. Разумеется, Гисты не предлагают инструменты для нормальных хранилищ на GitHub (например, проблемы, запросы на загрузку, вики). Но для того, что вы описываете, вам, вероятно, не нужно ни того, ни другого. Затем, Gists - прекрасный способ поделиться простыми вещами, не добавляя полные репозитории в свой профиль. И вы все еще можете клонировать их (удаленный URL-адрес - git@gist.github.com:/<gist-id>.git) и иметь полную историю и поддержку нескольких файлов, если вам это нужно.

Answer 2

Как правило, вы увидите, что верхний уровень репо содержит файл README, может быть, setup.py и некоторую другую постороннюю информацию, и, возможно, папку tests. Тогда будет папка, которая имеет имя с репо. Внутри этой папки находится код, который предназначен для основного содержимого модуля/пакета/скрипта.

Также необычно видеть разные организации, особенно с очень маленькими проектами однофайловых скриптов.

Для конкретного случая, о котором вы говорите, делайте то, что вам нравится. То, что вы предлагаете, звучит вполне разумно для меня. Я бы не хотел иметь отдельное репо для всех задач, которые я решаю!

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