Sur GitHub lui-même, vous ne pouvez pas regrouper vos dépôts par «dossier», sauf si vous créez des organisations .
Voir SublimeText , par exemple, en tant que groupe de tous les dépôts de packages sublimeText.
Mais cela ne prend pas en charge une organisation de dossiers imbriqués. Pour l'instant (juin 2017), cela ne prend en charge qu'une structure d'organisation d' équipe imbriquée .
Mise à jour de février 2019: vous avez maintenant le concept de projet :
voir " Projets appartenant à l'utilisateur - votre espace de travail personnel "
Vous pouvez également lier jusqu'à 5 référentiels à votre tableau de projet. Lier les référentiels limitera la portée de la recherche à ces référentiels liés, afin que vous puissiez rapidement affiner les nouveaux problèmes que vous n'avez pas encore ajoutés au tableau de projet
![https://i0.wp.com/user-images.githubusercontent.com/3477155/52346373-734e2580-29ed-11e9-82ad-9e5f1ab8aa99.gif?resize=1024%2C512&ssl=1](https://i.stack.imgur.com/Rzng6.gif)
GitHub prend également en charge les balises maintenant (sous forme de rubriques ).
Réponses originales 2012:
Une autre solution consiste à définir des référentiels qui référencent d'autres dépôts, déclarés comme sous-modules .
De cette façon, lorsque vous clonez l'un des dépôts (qui référence d'autres dépôts), appelés "dépôts parents", ils seront clonés dans leur propre répertoire, avec un sous-répertoire par sous-modules.
Cela ne sera pas visuellement apparent sur votre compte GitHub lui-même (car il contiendra toujours une grande liste de dépôts, encore plus grande avec les dépôts parents), mais en clonant un dépôt parent, vous y récupérerez tous ses sous-modules associés.
Le numéro 302 mentionné dans les commentaires d' AnneTheAgile en 2014 ne fait que des références maintenant ( nov.2018 )tbnorth/github_repo_tags
Le petit programme python de ce référentiel utilise l'API GitHub pour obtenir une liste de vos dépôts. et ajoutez leur nom, leur description et leur URL à un nouveau dépôt, appelé par défaut repo_tags. Au départ, chaque «problème» est étiqueté comme non classé, mais vous pouvez les étiqueter comme vous le souhaitez, en utilisant un étiquetage régulier des problèmes.
Lorsqu'il est réexécuté, repo_tags.py
crée uniquement des problèmes pour les dépôts. qui n'étaient pas déjà couverts par un problème.