Recibí este mensaje de Git:
Solicitó extraer desde el 'origen' remoto, pero no especificó una rama. Debido a que este no es el control remoto configurado por defecto para su rama actual, debe especificar una rama en la línea de comando.
¿Alguien puede explicarlo? y más importante, ¿cómo solucionarlo?
Respuestas:
Tienes que decirle a git qué rama quieres extraer de los repositorios remotos de "origen".
Supongo que desea la rama predeterminada (maestra), por lo que git pull origin masterdebería solucionar su problema.
Ver git help branch, git help pully git help fetch para más información.
git pullextrae y se fusiona con la rama actual, por lo que su comportamiento depende completamente de la rama que se haya verificado, y con un HEAD separado (sin rama), no hay forma de que pueda saber qué rama extraer.
Para solucionarlo, suponiendo que está en la masterrama y desea extraer la masterrama desde el origincontrol remoto, en versiones de Git suficientemente nuevas (1.8 o más reciente):
git branch -u origin/master master
(Análogamente para otras sucursales y / o controles remotos).
Si puede combinar esto con un empujón, es aún más corto:
git push -u origin master
A partir de entonces, un simple git pull/ git pushhará lo que esperas.
Durante la serie Git 1.7, git branchno tenía el -uinterruptor (solo lo git pushtenía), y en su lugar, tuvo que usar mucho más tiempo --set-upstream:
git branch --set-upstream master origin/master
Tenga en cuenta la inversión de argumentos en comparación con -u. Busqué esta orden más de una vez.
Todos estos, por cierto, son abreviaturas para hacer lo siguiente, que aún puede hacer explícitamente:
git config branch.master.remote origin
git config branch.master.merge refs/heads/master
Antes de 1,7, que tenía que hacerlo de esta manera.
git branch --set-upstream master origin/master
-uopción no está documentada git branchen mi versión 1.8.5.3, lo que hace que su documentación aquí sea aún más importante. Y, como notará, la opción no estaba disponible en la versión 1.7. *. Dado que -ues la abreviatura de --set-upstream, ¿no debería revertirse el orden de sus argumentos como lo hizo --set-upstreamdebido al comentario de @ EvanDonovan?
git branch -u origin/master master), funciona como se esperaba / previsto para mí: "El maestro de la rama se configuró para rastrear el maestro de la rama remota desde el origen".
-uinterruptor es en realidad no la forma corta de --set-upstream. Su orden de argumentos se invierte efectivamente del orden de --set-upstream. Creo que fue solo más tarde que --set-upstream-tose introdujo (nótese el "-to"), que es lo -uque ahora es en realidad la forma abreviada de.
El mensaje dice exactamente de qué se trata. Su sucursal actual no está asociada (no está rastreando) ninguna sucursal en origen . Entonces, git no sabe qué hacer.
¿Qué hacer? Eso depende...
En la situación más habitual, está trabajando con una rama local xyz que se ramificó desde el maestro, que se clonó desde el maestro de origen . La forma habitual de resolverlo es cambiar a master y tirar para sincronizarlo con el origen y luego volver a xyz y rebase master.
Pero en su situación, es posible que desee hacer otra cosa. No podemos saberlo sin conocer los detalles de sus sucursales y controles remotos y cómo intenta usarlos.