¿Cómo se organizan varios repositorios de git para que se realice una copia de seguridad de todos ellos juntos?

Question

Con SVN, tenía un único repositorio grande que guardaba en un servidor y lo guardaba en algunas máquinas.Este era un sistema de respaldo bastante bueno y me permitía trabajar fácilmente en cualquiera de las máquinas.Podría verificar un proyecto específico, confirmarlo y actualizar el proyecto 'maestro', o podría verificar todo.

Ahora tengo un montón de repositorios de git, para varios proyectos, varios de los cuales están en github.También tengo el repositorio SVN que mencioné, importado mediante el comando git-svn.

Básicamente, me gusta tener todo mi código (no sólo proyectos, sino fragmentos y scripts aleatorios, algunas cosas como mi CV, artículos que he escrito, sitios web que he creado, etc.) en un gran repositorio que puedo clonar fácilmente en un lugar remoto. máquinas, o tarjetas de memoria/discos duros como respaldo.

El problema es que, dado que es un repositorio privado, y git no permite retirar una carpeta específica (que podría enviar a github como un proyecto separado, pero los cambios aparecen tanto en el repositorio maestro como en el sub- repositorios)

I podría uso el sistema de submódulos de git, pero tampoco actúa como yo quiero (los submódulos son punteros a otros repositorios y en realidad no contienen el código real, por lo que es inútil para realizar copias de seguridad)

Actualmente tengo una carpeta de git-repos (por ejemplo, ~/code_projects/proj1/.git/ ~/code_projects/proj2/.git/), y después de hacer cambios en proj1 lo hago git push github, luego copio los archivos en ~/Documents/code/python/projects/proj1/ y hago una única confirmación (en lugar de las numerosas en los repositorios individuales).Entonces hazlo git push backupdrive1, git push mymemorystick etc.

Entonces, la pregunta:¿Cómo funciona su código personal y sus proyectos con los repositorios de Git y cómo mantenerlos sincronizados y respaldados?

Answer 1

me gustaría fuertemente Aconsejar sobre poner datos no relacionados en un repositorio GIT dado.La sobrecarga de crear nuevos repositorios es bastante bajo, y eso es un característica Eso hace posible mantener diferentes linajes completamente separados.

Combatir esa idea significa terminar con la historia innecesariamente enredada, que hace que la administración sea más difícil y, más importante, las herramientas de "arqueología" menos útiles debido a la dilución resultante.Además, como mencionó, Git supone que la "unidad de clonación" es el repositorio, y prácticamente tiene que hacerlo debido a su naturaleza distribuida.

Una solución es mantener cada proyecto/paquete/etc.como propio desnudoRepositorio (es decir, sin árbol de trabajo) bajo una bendita jerarquía, como:

/repos/a.git
/repos/b.git
/repos/c.git

Una vez que se han establecido algunas convenciones, se vuelve trivial aplicar operaciones administrativas (copia de seguridad, embalaje, publicación web) a la jerarquía completa, que cumple un papel que no es completamente diferente a los repositorios SVN "monolíticos".Trabajar con estos repositorios también se vuelve algo similar a los flujos de trabajo de SVN, con la adición de la quepoder utilice confirmaciones y sucursales locales:

svn checkout   --> git clone
svn update     --> git pull
svn commit     --> git push

Puede tener múltiples remotos en cada clon de trabajo, para la facilidad de sincronización entre las múltiples partes:

$ cd ~/dev
$ git clone /repos/foo.git       # or the one from github, ...
$ cd foo
$ git remote add github ...
$ git remote add memorystick ...

Luego puede buscar/sacar de cada una de las "fuentes", trabajar y comprometerse localmente, y luego empujar ("copia de seguridad") a cada uno de estos controles remotos cuando está listo con algo como (tenga en cuenta cómo eso empuja el mismo se compromete e historia a cada uno de los controles remotos!):

$ for remote in origin github memorystick; do git push $remote; done

La forma más sencilla de convertir un repositorio de trabajo existente ~/dev/fooen un repositorio tan simple es probablemente:

$ cd ~/dev
$ git clone --bare foo /repos/foo.git
$ mv foo foo.old
$ git clone /repos/foo.git

que es mayoritariamente equivalente a un svn import-pero no arroja la historia existente "local".

Nota: submódulos son un mecanismo para incluir acciones compartidas relacionadoLinajes, por lo que no los consideraría una herramienta apropiada para el problema que está tratando de resolver.

Answer 2

quiero agregar a La respuesta de Damián. donde recomienda:

$ for remote in origin github memorystick; do git push $remote; done

Puede configurar un control remoto especial para presionar a todos los controles remotos reales individuales con 1 comando;lo encontré en http://marc.info/?l=git&m=116231242118202&w=2:

Entonces, para "Git Push" (donde tiene sentido empujar las mismas ramas varias veces), puede hacer lo que hago:

• .git/config contiene:

  [remote "all"]
  url = master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6
  url = login.osdl.org:linux-2.6.git
  

• y ahora git push all master empujará la rama "maestra" a ambos
  de esos repositorios remotos.

También puedes ahorrarte escribir las URL dos veces usando la construcción:

[url "<actual url base>"]
    insteadOf = <other url base>

Answer 3

También tengo curiosidad sobre las formas sugeridas de manejar esto y describiré la configuración actual que uso (con SVN).Básicamente, he creado un repositorio que contiene una jerarquía de minisistema de archivos que incluye sus propios directorios bin y lib.Hay un script en la raíz de este árbol que configurará su entorno para agregar estos bin, lib, etc.otros directorios a las variables de entorno adecuadas.Entonces, el directorio raíz esencialmente se ve así:

./bin/            # prepended to $PATH
./lib/            # prepended to $LD_LIBRARY_PATH
./lib/python/     # prepended to $PYTHONPATH
./setup_env.bash  # sets up the environment

Ahora dentro de /bin y /lib están los múltiples proyectos y sus bibliotecas correspondientes.Sé que este no es un proyecto estándar, pero es muy fácil para otra persona de mi grupo verificar el repositorio, ejecutar el script 'setup_env.bash' y tener las versiones más actualizadas de todos los proyectos localmente en su verificar.No tienen que preocuparse por instalar/actualizar /usr/bin o /usr/lib y es sencillo tener múltiples pagos y un entorno muy localizado por pago.Alguien también puede simplemente configurar todo el repositorio y no preocuparse por desinstalar ningún programa.

Esto funciona bien para nosotros y no estoy seguro de si lo cambiaremos.El problema con esto es que hay muchos proyectos en este gran repositorio.¿Existe una forma estándar de git/Hg/bzr de crear un entorno como este y dividir los proyectos en sus propios repositorios?

Answer 4

Todavía no he intentado anidar repositorios de git porque no me he encontrado con una situación en la que sea necesario.Como he leído en el canal #git git parece confundirse al anidar los repositorios, es decir.estás intentando git-init dentro de un repositorio de git.La única forma de administrar una estructura git anidada es usar git-submodule o de Android repo utilidad.

En cuanto a esa responsabilidad de respaldo que estás describiendo, digo delegar él...En mi caso, normalmente coloco el repositorio de "origen" para cada proyecto en una unidad de red en el trabajo que los técnicos de TI realizan copias de seguridad periódicamente según la estrategia de copia de seguridad que elijan.Es simple y no tengo que preocuparme por eso.;)

Answer 5

¿Qué pasa con el uso señor para administrar sus múltiples repositorios de Git a la vez:

El comando MR (1) puede revisar, actualizar o realizar otras acciones en un conjunto de repositorios como si fueran un respositorio combinado.Admite cualquier combinación de subversión, GIT, CVS, Mercurial, BZR, DARCS, CVS, VCSH, repositorios de fósiles y veracidades, y se puede soportar fácilmente el soporte para otros sistemas de control de revisiones.[...]

Es extremadamente configurable mediante scripts de shell simples.Algunos ejemplos de cosas que puede hacer incluyen:

[...]

• Al actualizar un repositorio de git, extraiga de dos fuentes diferentes y combine las dos.
• Ejecute varias actualizaciones del repositorio en paralelo, lo que acelera enormemente el proceso de actualización.
• Recuerde las acciones que fallaron debido a que una computadora portátil estaba fuera de línea, para que pueda volver a intentarlas cuando vuelva a estar en línea.

Answer 6

Existe otro método para tener repositorios de git anidados, pero no resuelve el problema que buscas.Aún así, para otros que buscan la solución, yo estaba:

En el repositorio de git de nivel superior, simplemente oculte la carpeta en .gitignore que contiene el repositorio de git anidado.Esto hace que sea fácil tener dos repositorios de git separados (¡pero anidados!).