En GitHub, no puede agrupar sus repositorios por "carpeta", a menos que cree organizaciones .
Vea SublimeText , por ejemplo, como un grupo de todos los repos de paquetes de sublimeText.
Pero eso no admitirá una organización de carpetas anidadas. Por ahora (junio de 2017), eso solo admite una estructura de organización de equipo anidada .
Actualización de febrero de 2019: ahora tiene el concepto de proyecto :
consulte " Proyectos propiedad del usuario: su espacio de trabajo personal "
También puede vincular hasta 5 repositorios a su tablero de proyecto. La vinculación de repositorios limitará el alcance de la búsqueda a esos repositorios vinculados, por lo que puede reducir rápidamente cualquier problema nuevo que aún no haya agregado al tablero del proyecto
GitHub también admite etiquetas ahora (en forma de temas ).
Respuestas originales 2012:
Otra solución es definir repositorios que hagan referencia a otros repositorios, declarados como submódulos .
De esa manera, cuando clones uno de los repositorios (que hace referencia a otros repositorios), llamados "repositorios principales", se clonarán en su propio directorio, con un subdirectorio por submódulos.
No será visualmente aparente en su cuenta de GitHub (ya que todavía contiene una gran lista de repositorios, incluso más grande con los repositorios principales), pero al clonar un repositorio principal, obtendrá todos sus submódulos asociados.
El tema 302 mencionado en los comentarios de AnneTheAgile en 2014 solo hace referencia ahora (noviembre de 2018)tbnorth/github_repo_tags
El pequeño programa de Python en este repositorio utiliza la API de GitHub para obtener una lista de sus repositorios. y agregue su nombre, descripción y URL a un nuevo repositorio, por defecto llamado repo_tags. Inicialmente, cada "problema" se etiqueta sin clasificar, pero puede etiquetarlos como desee, utilizando el etiquetado de problemas regular.
Cuando se vuelve a ejecutar, repo_tags.py
solo crea problemas para repos. que ya no estaban cubiertos por un problema.