git: solución simple para empujar entre copys de trabajo

Lo que quiero hacer: en mi máquina universitaria (ssh remotamente accesible) trabajo en un proyecto que he puesto bajo control de fuente git init ( git init , luego git commit -a después de cada cambio, todo funciona bien). Ahora quiero querer trabajar en ese proyecto en mi máquina privada en casa. Debería ser fácil, ya que git es un vcs distribuido, ¿no?

Leí el tutorial de git , que sugiere hacer un git pull en la universidad para hacer los cambios en casa. Eso no funcionará, ya que mi máquina en casa no es remotamente accesible. Así que pensé que haría un git push en casa. Eso funciona, pero es complicado (requiere un git reset en la universidad después, etc.), ya que los repositorys no desnudos no están diseñados para empujar .

Pregunta 1: ¿Hay alguna manera más fácil que agregar un repository vacío adicional a mi configuration (lo que significaría que tenía: (1) el repository "principal", (2) la copy de trabajo de la universidad, (3) la copy de trabajo en el hogar )?
<Rant> Si realmente necesito esa configuration, podría haberme quedado con SVN. </ Rant>

Pregunta 2: Si esa configuration es realmente necesaria, ¿cómo creo ese repository desnudo ( git clone --bare , supongo) y lo convierto en el repository "principal" , es decir, le digo a las copys de trabajo que se supone que el git push irá allí .

PD: Sé que hay un gancho post-recepción flotando que te permite ingresar a repositorys no vacíos. Lo intenté, pero no funcionó bien ya que la versión de git en la máquina de la universidad es bastante antigua (1.5.5.6) y omite algunos commands utilizados por el gancho. La actualización no es una opción, y preferiría una solución sin scripts de terceros de todos modos.

En realidad, no debe empujar hacia la twig desprotegida, ya que efectivamente tira de la alfombra desde debajo de la copy de trabajo remota. Entonces es difícil determinar si el tree de trabajo se modificó porque la cabeza de la twig se ha movido o si también hubo cambios locales que se perderían por un reset --hard .

Lo más simple es presionar a una twig diferente. A continuación, puede fusionar esto en la twig de salida de la copy de trabajo de la copy de trabajo (o volver a establecer la bifurcación en la twig local) cuando tenga acceso a la máquina remota y necesite trabajar en ella.

Desde casa:

 git push origin HEAD:from-home 

Del 'trabajo':

 git merge from-home 

Puede configurar su configuration de forma pnetworkingeterminada a un refspec de inserción en particular.

p.ej

 git config remote.origin.push +master:from-home 

Un repository desnudo es a menudo más natural. Puede clonarlo desde un repository existente o, lo que suelo hacer, inicializar un nuevo repository y enviar la twig maestra que yo quiera desde un repository existente.

Mejor aún, si va a utilizar copys de trabajo en cada location, es utilizar este truco para modificar directamente los controles remotos, en lugar de una twig con un nombre diferente.

Entonces, en origen, crea un control remoto llamado 'hogar'; obviamente no puedes recuperarlo debido a tu configuration de networking. Eso no importa.

En casa, dígale: "Cuando presiono hacia el origen, tengo que actualizar el origen remoto del origen del origen :

 git config remote.origin.push +master:home/master 

Ahora, las cosas se ponen realmente resbaladizas. Desde casa, ejecuta git push origin , ve a origen y ejecuta git status o git branch -a -v – Lo que verás es algo así como: "master está detrás de home / master por 3 commits y puede ser reenviado rápidamente. "

En otras palabras, usar el hogar para enviar un cambio al hogar remoto designado del origen, es funcionalmente el mismo que usar el origen para extraer del hogar.

El único inconveniente aquí es que tendrá que hacer continuamente nuevas configuraciones de configuration de git a medida que crea twigs adicionales en el hogar. Esa es la sobrecarga que paga por la configuration de su networking. Afortunadamente, es simple y solo ocurre una vez por twig.

  1. Esta pregunta resume mi experiencia al tratar de sincronizar dos copys de trabajo. Eventualmente, pensé que era más natural y simple tener un repository simple. No es un repository "principal" en el sentido SVN; puede tener uno en la universidad y otro en casa, por ejemplo, y push-pull entre ellos.

  2. Es probable que alguien publique la forma correcta de configurar el repository vacío como su destino de inserción, pero sin mirar los documentos, simplemente eliminaría la copy de trabajo y la clonaría desde el repository vacío nuevamente.