Hola usuario de nuestra página web, hemos encontrado la solución a lo que andabas buscando, deslízate y la obtendrás a continuación.
Solución:
TL; DR: git branch --set-upstream-to origin/solaris
La respuesta a la pregunta que hiciste, que reformularé un poco como “¿tengo que establecer un flujo ascendente”, es: no, no tengo para establecer una corriente arriba en absoluto.
Sin embargo, si no tiene upstream para la rama actual, Git cambia su comportamiento en git push, y también en otros comandos.
La historia de empuje completa aquí es larga y aburrida y se remonta a la historia anterior a la versión 1.5 de Git. Para acortarlo mucho git push se implementó mal.1 A partir de la versión 2.0 de Git, Git ahora tiene un botón de configuración escrito push.default que ahora tiene como valor predeterminado simple. Para varias versiones de Git antes y después de la 2.0, cada vez que ejecutaba git push, Git emitiría mucho ruido al intentar convencerte de que configures push.default solo para conseguir git push para callar.
No menciona qué versión de Git está ejecutando, ni si ha configurado push.default, así que debemos adivinar. Supongo que está utilizando Git versión 2-point-something, y que ha configurado push.default para simple para que se calle. Precisamente qué versión de Git tienes y si tienes alguna push.default ajustado a, lo hace importa, debido a esa larga y aburrida historia, pero al final, el hecho de que esté recibiendo otra queja de Git indica que su Git es configurado para evitar uno de los errores del pasado.
¿Qué es un upstream?
Un río arriba es simplemente otro nombre de sucursal, generalmente una sucursal de seguimiento remoto, asociada con una sucursal (regular, local).
Cada rama tiene la opción de tener un (1) conjunto aguas arriba. Es decir, cada rama tiene un upstream o no tiene un upstream. Ninguna sucursal puede tener más de una en sentido ascendente.
El río arriba deberían, pero no tiene que ser una rama válida (ya sea de seguimiento remoto como origin/B o local como master). Es decir, si la rama actual B tiene corriente arriba U, git rev-parse Udeberían trabaja. Si no funciona, si se queja de que U no existe, entonces la mayoría de Git actúa como si el upstream no estuviera configurado en absoluto. Algunos comandos, como git branch -vv, mostrará la configuración aguas arriba pero marcarla como “desaparecida”.
¿De qué sirve un upstream?
Si tu push.default se establece en simple o upstream, la configuración aguas arriba hará git push, usado sin argumentos adicionales, simplemente funciona.
Eso es todo, eso es todo lo que hace git push. Pero eso es bastante significativo, ya que git push es uno de los lugares donde un simple error tipográfico causa grandes quebraderos de cabeza.
Si tu push.default se establece en nothing, matching, o current, configurar un upstream no hace nada para git push.
(Todo esto supone que su versión de Git es al menos 2.0).
El río arriba afecta git fetch
Si tu corres git fetch sin argumentos adicionales, Git se da cuenta cuales remoto para buscar consultando el flujo ascendente de la rama actual. Si el flujo ascendente es una rama de seguimiento remoto, Git busca desde ese control remoto. (Si el upstream no está configurado o es una rama local, Git intenta obtener origin.)
El río arriba afecta git merge y git rebase también
Si tu corres git merge o git rebase sin argumentos adicionales, Git usa el flujo ascendente de la rama actual. Por lo que acorta el uso de estos dos comandos.
El río arriba afecta git pull
Nunca deberías2 usar git pull de todos modos, pero si lo haces, git pull utiliza la configuración ascendente para averiguar de qué control remoto buscar y luego con qué rama fusionar o rebasar. Es decir, git pull hace lo mismo que git fetch—Porque en realidad carrerasgit fetch—Y luego hace lo mismo que git merge o git rebase, porque en realidad carrerasgit merge o git rebase.
(Por lo general, debe realizar estos dos pasos manualmente, al menos hasta que conozca Git lo suficientemente bien como para que, cuando alguno de los pasos falle, lo que eventualmente sucederá, reconozca lo que salió mal y sepa qué hacer al respecto).
El río arriba afecta git status
En realidad, esto puede ser lo más importante. Una vez que tenga un conjunto de aguas arriba, git status puede informar la diferencia entre su rama actual y su anterior, en términos de confirmaciones.
Si, como es el caso normal, estás en la sucursal B con su corriente arriba en origin/By tu corres git status, verá inmediatamente si tiene confirmaciones que puede enviar y / o confirmaciones en las que puede fusionar o rebasar.
Esto es porque git status carreras:
git rev-list --count @u..HEAD: ¿cuántas confirmaciones tienes enBque no estan enorigin/B?git rev-list --count [email protected]u: ¿cuántas confirmaciones tienes enorigin/Bque no estan enB?
Establecer un upstream le brinda todas estas cosas.
Cómo master ya tiene un set upstream?
Cuando clona por primera vez desde un control remoto, usa:
$ git clone git://some.host/path/to/repo.git
o similar, el último paso que hace Git es, esencialmente, git checkout master. Esto verifica su sucursal local master—Sólo tu no tengo una sucursal local master.
Por otro lado, tu hacer tener una rama de seguimiento remoto llamada origin/master, porque lo acaba de clonar.
Git adivina que debes haber querido decir: “hazme un nuevo local master que apunta a la misma confirmación que el seguimiento remoto origin/mastery, mientras lo hace, configure el flujo ascendente para master para origin/master. “
Esto pasa por cada ramificarte git checkout que aún no tienes. Git crea la rama y hace que “rastree” (tenga como flujo ascendente) la rama de rastreo remoto correspondiente.
Pero esto no funciona para nuevo sucursales, es decir, sucursales sin sucursal de seguimiento remoto todavía.
Si crea un nuevo rama:
$ git checkout -b solaris
todavía no hay origin/solaris. Tu local solarisno poder seguimiento de rama de seguimiento remoto origin/solaris porque no existe.
Cuando empuja la nueva rama por primera vez:
$ git push origin solaris
ese creasolaris sobre origin, y por lo tanto también crea origin/solaris en su propio repositorio de Git. Pero es demasiado tarde: ya tienes un local solaris ese no tiene aguas arriba.3
¿No debería Git simplemente configurar eso, ahora, como el flujo ascendente automáticamente?
Probablemente. Consulte “implementado de manera deficiente” y la nota al pie 1. Es difícil de cambiar ahora: Hay millones4 de los scripts que usan Git y algunos pueden depender de su comportamiento actual. Cambiar el comportamiento requiere una nueva versión principal, nag-ware para obligarlo a establecer algún campo de configuración, y así sucesivamente. En resumen, Git es víctima de su propio éxito: cualquier error que tenga, hoy, solo puede corregirse si el cambio es mayormente invisible, claramente mucho mejor o si se hace lentamente con el tiempo.
El hecho es que hoy no es así, a no ser que tu usas --set-upstream o -u durante el git push. Eso es lo que te dice el mensaje.
No tienes que hacerlo así. Bueno, como señalamos anteriormente, no tiene que hacerlo en absoluto, pero digamos que querer un río arriba. Ya has creado una rama solaris sobre origin, a través de un empujón anterior, y como su git branch la salida muestra, ya tengoorigin/solaris en su repositorio local.
Simplemente no lo tiene configurado como el upstream para solaris.
Para configurarlo ahora, en lugar de durante el primer impulso, use git branch --set-upstream-to. los --set-upstream-to subcomando toma el nombre de cualquier rama existente, como origin/solarisy establece el flujo ascendente de la rama actual a esa otra rama.
Eso es todo, eso es todo lo que hace, pero tiene todas las implicaciones mencionadas anteriormente. Significa que puedes simplemente correr git fetch, luego mira a tu alrededor, luego corre git merge o git rebase según corresponda, luego realice nuevas confirmaciones y ejecute git push, sin un montón de preocupaciones adicionales.
1Para ser justos, en ese entonces no estaba claro que la implementación inicial fuera propensa a errores. Eso solo quedó claro cuando todos los usuarios nuevos cometieron los mismos errores cada vez. Ahora es “menos pobre”, lo que no quiere decir “excelente”.
2“Nunca” es un poco fuerte, pero encuentro que los novatos de Git entienden las cosas mucho mejor cuando separo los pasos, especialmente cuando puedo mostrarles lo que git fetch realmente hizo, y luego pueden ver lo que git merge o git rebase haré a continuación.
3Si ejecuta su primerogit push como git push -u origin solaris—Es decir, si agrega el -u bandera: Git establecerá origin/solaris como el flujo ascendente para su rama actual si (y solo si) el empuje tiene éxito. Entonces deberías suministrar -u sobre el primero empujar. De hecho, puede suministrarlo en cualquier impulso posterior, y se configurará o cambiar el río arriba en ese punto. Pero yo pienso git branch --set-upstream-to es más fácil, si lo olvidaste.
4Medido por el método Austin Powers / Dr Evil de simplemente decir “un MILLLL-YUN”, de todos modos.
La diferencia entregit push origin
ygit push --set-upstream origin
es que ambos empujan bien al repositorio remoto, pero es cuando tiras que notas la diferencia.
Si lo haces:git push origin
al tirar, tienes que hacer:git pull origin
Pero si lo hace:git push --set-upstream origin
luego, al tirar, solo tienes que hacer:git pull
Entonces agregando en el --set-upstream permite no tener que especificar de qué rama desea extraer cada vez que lo hace git pull.
Un comando básicamente completo es como git push . Si corres solo git push, git no sabe qué hacer exactamente a menos que haya realizado alguna configuración que ayude a git a tomar una decisión. En un repositorio de git, podemos configurar varios controles remotos. También podemos enviar una referencia local a cualquier referencia remota. El comando completo es la forma más sencilla de hacer un empujón. Si desea escribir menos palabras, primero debe configurar, como –set-upstream.
Reseñas y valoraciones del tutorial
Acuérdate de que tienes la capacidad de parafrasear si te fue preciso.