¿Cuál es una buena manera de organizar una gran colección de scripts personales usando git?

Question

Tengo una gran colección de scripts personales que me gustaría comenzar a versionar usando Git. He organizado previamente el código de la siguiente manera:

~/code/python/projects/ (for large stuff, each project contained in an individual folder) 
~/code/python/scripts/ (single file scripts all contained in this directory) 
~/code/python/sandbox/ (my testing area) 
~/code/python/docs/ (downloaded documentation) 

~/code/java/... (as above) 

Ahora voy a comenzar mi código de versiones usando git, para que pueda tener la historia y la copia de seguridad de todo mi código a un servidor remoto.

Sé que si estuviera usando SVN solo mantendría todo mi directorio "~/code/" en un gran repositorio, pero entiendo que esta no es una buena manera de hacer cosas con Git.
La mayoría de la información que he visto en línea sugiere mantener todas las carpetas de proyectos en un solo lugar (como en, sin directorios separados para python o java) con cada proyecto que contiene su propio repositorio git, y simplemente tener un directorio "snippets" que contenga todo scripts/experimentos de un solo archivo que pueden convertirse en proyectos en una fecha posterior.

Pero no estoy seguro de cómo me siento acerca de la consolidación de todos mis directorios de códigos en un área. ¿Hay una buena manera de mantener intactos mis directorios de códigos separados, o no vale la pena el esfuerzo? Tal vez estoy solo conectado a los directorios de códigos separados porque nunca he sabido nada más ...

También (como nota al margen), me gustaría poder ver rápidamente una historia cronológica de todo mi proyectos y scripts. Entonces puedo ver qué proyectos creé más recientemente. Solía ​​hacer esto manteniendo un número al principio de todos mis proyectos, 002project, 003project.
¿Hay manera automática o fácil de hacer esto en git sin tener que agregar un número a todos los nombres de proyecto?

Estoy abierto a cualquier consejo de organización práctica o filosófica que tenga. ¡¡¡Gracias!!!

Answer 1

sé que si estuviera usando SVN me acaba de mantener todo mi directorio "~/código /" en un gran repositorio, pero entiendo º no es una buena manera de hacer cosas con Git.

La razón git disuadir a la gente de tener, repositorios monolíticos individuales es que no se puede clonar los subdirectorios de un repositorio (como se hace con SVN)

Digamos que tiene git://blah/somecorp_code.git que tiene millones de revisiones, y es de 15 GB . Si solo quieres un subdirectorio de ese código, difícil: o obtienes todos los 15 GB o nada.

Para el código personal, esto realmente no es un problema - Tengo un repositorio git "monolítico", que es de aproximadamente 20 MB, y felizmente puedo clonarlo en todas las máquinas en las que deseo utilizarlo.

Nadie más lo usa, nadie más se compromete, y rara vez hago mucho en el camino de la bifurcación. Es realmente sólo tiene que utilizar un-undo-sistema de lujo con buena sincronización y copia de seguridad remota (proyecto privado GitHub)

He organizado de la siguiente manera:

En el nivel de la raíz del repositorio, tengo una carpeta code (junto con una carpeta sites, para la materia de web-dev - es por eso que el repositorio es de 20 MB)

En la carpeta de código, tengo carpetas para varios idiomas (python, ruby, c etc)

En cada idioma directorio, yo Ve dos carpetas, snippets y projects. Inside snippets es un grupo de archivos, dentro de los proyectos hay una serie de carpetas.

Estos proyectos son las cosas al azar que he escrito, pero realmente no funcionan en gran parte (proyectos de juguete, "Me pregunto si pudiera ..." - proyectos, etc.)

Si es un solo archivo de Python , que va en code/python/snippets/, si se trata de más de un archivo que va en code/python/projects/{project name}

Cuando quiero dar a conocer públicamente un proyecto (en Github, por lo general), se crea un nuevo repositorio, copie el código a este y sincronizarlo con Github.

El repositorio de "proyectos activos" por separado ahora no está relacionado con el repositorio monolítico. Miré en el proyecto submódulo, pero no está diseñado para este uso - que está diseñado para hacer que las dependencias de clonación fácil, no logra una serie de repositorios no relacionadas

tengo un script que utiliza la API de Github para clonar de forma automática toda mi proyectos localmente, o actualizarlos con git pull - es solo una versión autónoma de githubsync.py (he fusionado github.py en el mismo archivo).Se puede encontrar here as gist/373731

Utilicé githubsync.py para clonar mis proyectos inicialmente en mi computadora portátil y de escritorio, y también lo ejecuto rutinariamente en Dropbox, como respaldo.

Answer 2

Sé que si estuviera usando SVN me acaba de mantener todo mi directorio "~/code/" en un gran repositorio, pero entiendo que esto no es una buena manera de hacer las cosas con Git.

Sí, lo es.
Pero una vez que tenga ese repositorio grande, debe distinguir las partes que evolucionarán con su propio ciclo de vida y su propia etiqueta.
Esos serían submodules que serán, como usted dijo, un git repo propio.

Así que aún así obtener:

code 
    .git (main project) 
    python 
    .git (main sub-project for all python-related stuff) 
    project1 
     .git (first submodule) 
    project2 
     .git (first submodule) 
    ... 
    scripts 
     .git (one submodules for all your scripts) 
    sandbox 
     .git (sandbox submodule) 
    docs 
     .git (docs submodule) 
    java 
    .git (main sub-project for all java-related stuff) 
    ... (repeat same organization) 

Nota: la cronología de la creación de proyectos está siendo mejor gestionado con una convención de nomenclatura.

Con que muchas submódulos, puede:

• realidad clonar y trabajar en cualquier parte de su colección sin necesidad de obtener todo
• o puede re-construida de la misma organización de edad que tenía en el primer lugar