¿Hay alguna forma de configurar un repositorio de git, de manera que git pull se establezca de manera predeterminada en un control remoto y git push se establezca de manera predeterminada en otro? Sé que puedo establecer ambos cambiando el valor de la variable remote en la sección de rama de .git/config, pero ¿cómo hacerlo para cada dirección por separado?Diferente control remoto predeterminado (seguimiento de derivación) para git pull y git push
Para Git 1.6.4 y posterior, establezca remote.<name>.pushurl con git config.
Se puede usar esto para tirar usando el protocolo de solo lectura https: y presionar usando un protocolo basado en ssh.
Say url origin 's (remote.origin.url) es https://git.example.com/some/repo.git. Es de solo lectura, pero tiene acceso de escritura a través de la 'URL' basada en ssh [email protected]:some/repo.git. Ejecute el siguiente comando para efecto de empuje sobre el protocolo basado en ssh:
git config remote.origin.pushurl [email protected]:some/repo.git
De lo que se desprende de la git config man page, el repositorio de aguas arriba es:
branch.remotegit pull/fetch y git pullPara una dada la rama, no veo ninguna manera de tener dos controles remotos separados por defecto.
Esto parece ser cierto en la práctica para git v1.8.3.2, después de probar las respuestas 'git config remote ...' y git remote set-url ... ', para una sola rama o para un todo copia de un repositorio. –
para restablecer el control remoto predeterminado de nuevo a 'origen' para la rama actual y empujar/tirar a/desde el nombre de la rama correspondiente:' git push --set-upstream origen
Desde Git versión 1.7.0, se puede establecer esto con:
git remote set-url --push origin https://your.push.com/blah/
3 años más tarde que la pregunta, pero esta debería ser la nueva respuesta aceptada. – Kevlar
@Kevlar ¿Por qué? La aceptación se utiliza para marcar no siempre las "mejores" respuestas, sino la que funcionó para OP (lea las preguntas frecuentes para obtener más información). En el momento de hacer la pregunta anterior, la respuesta no funcionaría (ni siquiera existiría), ya que git era mucho antes que la 1.8. Sin embargo, la respuesta aceptada funcionó para OP. ¿Qué motivo encuentra para cambiar la decisión de OP después de tres años? – trejder
@trejder Stack Overflow es también un lugar para servir respuestas útiles a futuros visitantes, que encuentran una pregunta a través de un motor de búsqueda o lo que sea. Es valioso tener primero la mejor respuesta actual. No estoy diciendo que OP * debe * cambiar la respuesta aceptada, pero que sería perfectamente razonable (y en mi opinión un positivo neto) hacerlo. – amalloy
Esto funciona en 1.7.1 y superiores -
git remote set-url --push origin [email protected]:username/somerepo.git
¿En qué se diferencia esto de la respuesta de [user392887] (http://stackoverflow.com/a/17930364/41071)? – svick
No tengo la capacidad de comentar o menospreciar esa respuesta. Dos cosas clave a tener en cuenta en mi respuesta: 1) Uso ssh. Según GitHub, "recomendamos utilizar una conexión SSH cuando se interactúa con GitHub. Las claves SSH son una forma de identificar las computadoras de confianza, sin incluir contraseñas". 2) Cualquiera que use RHEL/CentOS 6 usará git 1.7.1 de manera predeterminada - 1.7.1 admite set-url, acabo de usarlo. – potto
Desde Git 1.8.3, puede utilizar la opción remote.pushDefault para hacer exactamente lo que quiere (es decir, con diferentes mandos a distancia por defecto para pull y push). Puede establecer la opción como cualquier otra; por ejemplo, para fijar a la pushTarget remoto, utilice
git config remote.pushDefault pushTarget
Esta opción tendrá el siguiente efecto:
git pull se tire de la especificada a distancia por la opción de remote en la sección rama relevante en .git/config, mientras quegit push presionarán al control remoto especificado por remote.pushDefault.Tenga en cuenta que es necesario especificar el nombre de un mando a distancia, no una URL. Esto hace que esta solución sea más flexible que la solución que implica remote.<name>.pushurl, porque (por ejemplo) aún tendrá rastreos de rastreo para ambos controles remotos. Si usted necesita o desea esta flexibilidad, depende de usted.
The release notes dicen que esta opción se ha agregado específicamente para admitir flujos de trabajo triangulares.
Extraño: pensé que solo empujabas hacia arriba, y no sabes cuántos repositorios en sentido descendente están sacando de ti: mira http://stackoverflow.com/a/2749166/6309 – VonC
@VonC Ah, sí, veo por qué es confuso Por lo general, llamo al control remoto del que quiero * extraer * de forma predeterminada 'ascendente' porque ... bueno ... está en la parte superior de mi repositorio durante esos pulls. Pero la opción es 'pushDefault', no' pullDefault', así que usé 'downstream' como el nombre en el ejemplo. Probablemente sea una mejor idea llamarlo 'defaultPushTarget';) – MvanGeest
@MvanGeest Estoy de acuerdo. Pero confirmo que generalmente presionas para "subir". Hay una (o muy pocas y conocidas) aguas arriba. Pero puede haber muchas (y desconocidas) aguas abajo. Tal es el universo DVCS (como en el universo "distribuido"). – VonC
Cómo hacer push push a say ' ¿rama de desarrollo y extracción procedente de la rama de 'producción' en el mismo repositorio de Git remoto + desnudo? – Ninad