Trabajar con Git en múltiples máquinas

13

Esto puede sonar un poco extraño, pero me pregunto sobre una buena manera de trabajar en Git desde varias máquinas conectadas en red de alguna manera. Me parece que tengo dos opciones y puedo ver los beneficios en ambos lados:

  • Usa git para compartir, cada máquina tiene su propio repositorio y tienes que buscar entre ellas.
    • Puede trabajar en cualquiera de las dos máquinas, incluso si la otra está fuera de línea. Esto por sí solo es bastante grande, creo.
  • Use un repositorio que se comparte en la red entre las máquinas.
    • No es necesario hacer git pulls cada vez que cambias de máquina, ya que tu código siempre está actualizado.
    • Nunca se preocupe de que olvidó insertar el código de su otra máquina que no es de alojamiento, que ahora está fuera de su alcance, ya que estaba trabajando con un recurso compartido de archivos en esta máquina.

Mi intuición dice que, en general, todos van con la primera opción. Pero el inconveniente que veo es que es posible que no siempre pueda acceder al código desde sus otras máquinas, y ciertamente no quiero enviar todas mis sucursales WIP a github al final de cada día. Tampoco quiero tener que dejar mis computadoras encendidas todo el tiempo para poder buscarlas directamente. Por último, un punto secundario es que todos los comandos de git para mantener múltiples sucursales al día pueden ser tediosos.

¿Hay una tercera manija en esta situación? ¿Es posible que existan algunas herramientas de terceros que ayuden a facilitar este proceso? Si lidias con esta situación regularmente, ¿qué sugieres?

    
pregunta Tesserex 10.07.2012 - 21:05

4 respuestas

12

Me ocupo de las dos soluciones propuestas diariamente. Hay dos conceptos clave para manejarlos bien.

  1. Use ramas de temas. Creo que el historial de producción debe ser prístino. Como resultado, dedico una gran cantidad de tiempo a hacer que el historial de mi sucursal production sea lógico, replicable y se pueda depurar. Sin embargo, cuando utiliza varias máquinas, ocasionalmente debe realizar un trabajo en curso. Utilice una rama de tema. Puede pull y push esta rama desde ambas máquinas con poco esfuerzo, y cuando esté lista para unirse a master o production vuelva a hacer una base para crear un historial más mantenible.
  2. El uso de un repositorio compartido a través de una red está bien, a menos que también lo compartas con otros usuarios. Usamos un repositorio compartido para scripts, llamado creativamente el repositorio scripts . Al principio parecía una buena idea, ya que el repo no cambia a menudo, pero con el tiempo se ha convertido en una pesadilla. Es fácil sobrescribir el trabajo del otro y terminas gastando tanto tiempo en el tráfico aéreo controlando quién está implementando el repositorio mientras trabajas en él.

La mejor solución es mantener un repositorio local en cada máquina y compartir ramas de temas entre ellos a través de un control remoto. Comprometa el trabajo en curso en esas sucursales con la frecuencia que desee. Siempre y cuando estés dispuesto a convertirlos en una historia más inteligible, es bastante efectivo en la práctica.

Si se encuentra trabajando en más de una rama temática a lo largo del día pero no desea enviar cada una individualmente al control remoto, rebase empujará todas las ramas coincidentes de forma predeterminada a git push <remote> . Este predeterminado cambiará en una versión posterior de git , pero se puede anular mediante configurando <remote> en un archivo de configuración o especificando la coincidencia push.default :

git push <remote> :
    
respondido por el Christopher 10.07.2012 - 21:28
2

He llegado a esto desde una dirección ligeramente diferente (y uso mercurial, pero filosóficamente es lo mismo). Esta no es mi idea, solo la uso y funciona para mis cosas personales.

Creé un clon de mis repositorios en una carpeta de SkyDrive (también podría ser Dropbox u otra herramienta de sincronización mágica de su elección), luego configuré las instancias en mis dos máquinas para que ingresen automáticamente al repositorio de SkyDrive.

Cuando cambio de cajas, es solo cuestión de hacer un pull y una actualización: en teoría, siempre estarás trabajando de manera lineal, aunque esté en múltiples repositorios.

La clave aquí es que el repositorio de SkyDrive existe principalmente para proporcionar un medio para garantizar que tengo acceso a más o menos la última versión del código en mis dos máquinas, aunque también funcionaría para más, y para proporcionar una copia de seguridad adicional. Todo lo que está "hecho" se transfiere a Kiln (si estuviera usando git y entendiera correctamente la forma en que se juega el juego, ese sería el punto en el que hago una rebase).

Lo que realmente no querría hacer es salir de una carpeta compartida ... si estás usando un DVCS, entonces puedes disfrutar del beneficio.

    
respondido por el Murph 10.07.2012 - 23:21
2

Si no todas las máquinas están activadas todo el tiempo, no hay una bala de plata: antes de apagar la máquina, debe empujar los cambios en otro lugar. Empujo a un servidor privado, pero podría ser también Dropbox o una llave USB que lleves a todas partes.

Sí, empujar varias ramas a un lugar central puede ser tedioso, pero eso no debería ser demasiado difícil de escribir. Utilizo un script push.sh para eso, que ejecuto cada vez que termino de trabajar en una máquina.

    
respondido por el janos 11.07.2012 - 17:37
0

La primera de tus dos alternativas es la respuesta. Eso está implícito por la "D" en "DVCS". Cada usuario tiene su propia instancia local del repositorio, y los repositorios hablan entre sí de maneras manejables.

Podría hacer su segunda alternativa, pero el problema es que solo hay un directorio de trabajo del repositorio. Por lo tanto, el árbol de trabajo puede estar en un solo estado a la vez: no hay Joe trabajando en una rama y Jane trabajando en la otra. Por lo tanto, los desarrolladores pueden sobrescribir los cambios de los demás y manipular el trabajo de los demás. ¡Por qué, es como no tener control de versión en absoluto!

Hay un punto intermedio llamado, que tiene un repositorio simple en una unidad de red y que los usuarios individuales pueden ingresar y salir de ella. Esto separa su trabajo WIP (que sí, mantiene localmente) del trabajo que publica hasta el repositorio. No es "guardar", es "publicar". El trabajo que desea que sus compañeros vean y utilicen.

    
respondido por el Dan Ray 10.07.2012 - 21:22

Lea otras preguntas en las etiquetas