Dos sucursales locales son rastreados por dos repositorys remotos diferentes

Actualmente estoy trabajando en un proyecto en el que tuve que desviarme del master , realizar un montón de cambios localmente y 'ponerlo en marcha' con un entorno de testing que se envía a un repository remoto particular, de la siguiente manera:

 git push origin site-testing 

empuja a la twig de site-testing en el siguiente repository:

 user-name@testing.com:/path/to/root-dir-containing-.git 

Ahora necesito seleccionar los cambios de la twig de site-testing del site-testing en la twig master .

El problema es que, cuando git push origin master , me gustaría que estos cambios fueran enviados a un repository remoto totalmente diferente.

Entonces el resultado deseado es:

 git push origin master 

empuja al master al siguiente repository:

 user-name@aws-live-domain.com:/path/to/root-dir-containing-.git 

y no master en testing.com ..

es posible? Agradezco cualquier sugerencia

Puede agregar otro origen y pulsarlo, de la siguiente manera:

 git remote add origin1 https://aws-live-domain.com/user-name/<path/to/root-dir-containing->.git git push origin1 master 

Puede tener más de un control remoto. Esto te permite hacer lo que quieras.

La syntax general para usar git push es:

git push remote branch

que a menudo verás, por ejemplo, como git push origin master . La parte de origin es el nombre de un control remoto y la segunda parte es un nombre de sucursal (bueno, en realidad es más complicado, pero vamos a ir con "nombre de sucursal" aquí :-)).

Recuerde que un control remoto en Git es solo un nombre corto para otro repository de Git en alguna otra URL. Por lo general, un repository de Git viene con un origin remoto, con nombre, prefabricado, porque git clone configura un control remoto para usted, y el nombre que usa de manera pnetworkingeterminada es el origin .

Para agregar otro, diferente, remoto, ejecute git remote add , por ejemplo:

 git remote add xyzzy ssh://user-name@testing.com/path/to/repo.git 

Ahora xyzzy es el nombre de un segundo control remoto, que se refiere a un repository de Git en testing.com , al que se accede a través de ssh user-name@testing.com , viviendo en path/to/repo.git en ese sistema. Ahora puede git push xyzzy branch .

¡Pero espera hay mas!

Cada twig puede tener una (y solo una) configuration ascendente . El upstream de una twig es en realidad un par de elementos: es el nombre del control remoto, más un nombre de twig. Este par de ítems es también lo que tu Git usa para recordar esa twig como se ve en ese control remoto la última vez que tu Git realmente conversó con ese otro Git.

Por lo tanto, si tiene una plugh-test twig que normalmente debería xyzzy a xyzzy remoto, puede hacer:

 git branch --set-upstream-to=xyzzy/plugh-test plugh-test 

Ahora la plugh-test sucursal restring que su xyzzy/plugh-test ascendente es xyzzy/plugh-test , que es la memory de plugh-test de plugh-test de su propio Git, como se ve en el xyzzy remoto.

Si su configuration de push.default es simple (como lo es por defecto en Git 2.0 o posterior), y está en plugh-test twig, puede simplemente ejecutar:

 git push 

porque su Git searchá el control remoto de su sucursal actual , y lo usará como el argumento remoto pnetworkingeterminado, al presionar la bifurcación actual, que es el argumento de bifurcación pnetworkingeterminado.

Sin embargo, tenga en count que si accidentalmente ejecuta:

 git push colossal-cave 

pensar que esto empujará a la twig colossal-cave , no lo hará: el argumento posicional aquí es siempre un control remoto , no una twig.

( xyzzy y plugh son verbos mágicos de Colossal Cave Adventure.)