Trabajando con Git en múltiples máquinas

Esto puede sonar un poco extraño, pero me pregunto acerca de 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 beneficios en ambos lados:

• Use git para compartir, cada máquina tiene su propio repositorio y debe buscar entre ellos.
  • Puede trabajar en cualquier máquina incluso si la otra está fuera de línea. Esto en sí mismo es bastante grande, creo.
• Use un repositorio que se comparte en la red entre máquinas.
  • No es necesario hacer git pull cada vez que cambie de máquina, ya que su código siempre está actualizado.
  • No se preocupe si olvidó insertar el código de su otra máquina que no es de alojamiento, que ahora está fuera del alcance, ya que estaba trabajando en un recurso compartido de archivos en esta máquina.

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

¿Hay un tercer control sobre esta situación? ¿Quizás hay algunas herramientas de terceros disponibles que ayudan a facilitar este proceso? Si lidias con esta situación regularmente, ¿qué sugieres?

Trato con sus dos soluciones propuestas diariamente. Hay dos conceptos clave para manejarlos bien.

1. Usa ramas temáticas. Creo que la historia de la producción debe ser inmaculada. Como resultado, paso mucho tiempo haciendo que productionla historia de mi sucursal sea lógica, replicable y depurable. Sin embargo, cuando utiliza varias máquinas, ocasionalmente necesita comprometer el trabajo en progreso. Usa una rama temática. Puede pully pushesta rama de ambas máquinas con poco esfuerzo, y cuando esté listo para fusionarse mastero production volver a crear una base para crear un historial más fácil de mantener.
2. Usar un repositorio compartido en una red está bien, a menos que también lo comparta con otros usuarios. Utilizamos un repositorio compartido para scripts, llamado creativamente el scriptsrepositorio. Al principio, parecía una buena idea, ya que el repositorio no cambia a menudo, pero con el tiempo se ha convertido en una pesadilla. Es fácil sobrescribir el trabajo del otro, y terminas pasando tanto tiempo controlando el tráfico aéreo que está desplegando el repositorio como lo haces trabajando en él.

La mejor solución es mantener un repositorio local en cada máquina y compartir ramas temáticas entre ellos a través de un control remoto. Comprometa el trabajo en progreso a esas ramas con la frecuencia que desee. Mientras estés dispuesto a rebaseellos 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 empujar cada una individualmente al control remoto, git push <remote>por defecto empujará todas las ramas coincidentes <remote>. Este valor predeterminado cambiará en una versión posterior de git , pero puede anularse configurando push.defaultun archivo de configuración o especificando la coincidencia refspec:

git push <remote> :

Si no todas las máquinas están encendidas todo el tiempo, no hay una bala de plata: antes de apagar la máquina, debe presionar los cambios en otro lugar. Empujo a un servidor privado, pero podría ser Dropbox o una clave USB que llevas 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 push.shscript para eso, que ejecuto cada vez que termino de trabajar en una máquina.

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 se envíen automáticamente al repositorio de SkyDrive al confirmar.

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

La clave aquí es que el repositorio 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 funcionaría también para más, y para proporcionar un copia de seguridad adicional. Todo lo que está "hecho" se envía a Kiln (si estuviera usando git y entiendo correctamente la forma en que se juega el juego, entonces ese sería el punto en el que haría un rebase).

Lo que realmente no quisiera hacer es ejecutar una carpeta compartida ... si está utilizando un DVCS, entonces también puede disfrutar del beneficio.

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

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 otra. Para que los desarrolladores puedan sobrescribir los cambios de los demás, destrozar el trabajo de los demás. ¡Es como no tener control de versiones en absoluto!

Hay un término medio llamado, tener un repositorio desnudo en una unidad de red y hacer que los usuarios individuales ingresen y salgan de él. Esto separa su trabajo WIP (que sí, usted mantiene localmente) del trabajo que publica hasta el repositorio. No es "guardar", es "publicar". El trabajo que desea que sus compañeros vean y usen.