Al hacer un ‘git push’, ¿qué hace ‘–set-upstream’?

¿Qué significa git? --set-upstream ¿hacer?

Traté de entenderlo leyendo el manual de gitpero no lo entendí del todo.

Para evitar confusión,
versiones recientes de git despreciar esto algo ambiguo --set-upstream opción
a favor de una más detallada --set-upstream-to opción
con idéntica sintaxis y comportamiento.
[ Reference ]

git branch --set-upstream-to <remote-branch>

establece la sucursal remota predeterminada para la sucursal local actual.

cualquier futuro git pull comando (con la rama local actual desprotegida),
intentará traer compromisos desde el <remote-branch> en la rama local actual.

Una forma de evitar tener que escribir explícitamente --set-upstream / --set-upstream-to es usar su bandera abreviada -u como sigue:

git push -u origin local-branch

Esto establece automáticamente la asociación ascendente para cualquier intento futuro de empujar/jalar.
Para más detalles, echa un vistazo a este explicación detallada sobre las ramas ascendentes y el seguimiento.

Cuando presionas un control remoto y usas el --set-upstream flag git establece la rama a la que está empujando como la rama de seguimiento remoto de la rama que está empujando.

Agregar una rama de seguimiento remoto significa que git sabe lo que quieres hacer cuando git fetch, git pull o git push en el futuro. Asume que desea mantener la sucursal local y la sucursal remota que está rastreando sincronizadas y hace lo apropiado para lograrlo.

Podrías lograr lo mismo con git branch --set-upstream-to o git checkout --track. Consulte las páginas de ayuda de git en seguimiento de ramas para más información.

git branch --set-upstream <<origin/branch>> oficialmente ya no es compatible y es reemplazado por git branch --set-upstream-to <<origin/branch>>

--set-upstream se usa para asignar una sucursal en su local a una sucursal en el control remoto para que pueda hacer git push o git pull y sabrá de qué rama empujar/tirar

Para agregar un repositorio remoto, uso estos comandos

• Primero, revisa tus repositorios remotos con git remote -v
• Si no puede ver aguas arriba, use git remote add upstream <URL>
• Revisa nuevamente tus repositorios remotos con git remote -v

Al usar los mismos comandos anteriores, es posible tener múltiples controles remotos en un repositorio local.

Simplemente cambie el nombre ascendente git remote add NAME <URL>

Estoy asumiendo que tu pregunta es:

Que hace git push --set-upstream <repository> <branchname> ¿hacer?

Como puede ver, asumí que el comando git en cuestión es git push. Espero que eso sea lo que quisiste decir. Para simplificar la respuesta, especifiqué además que la sucursal local en la que se encuentra tiene el mismo nombre que la sucursal remota en su repositorio ascendente al que está ingresando. Finalmente, asumo una configuración común de git.

Dicho esto, este es mi respuesta:

Además de la operación que un git push sin la opción --set-upstream hace, esta opción marcas git push colocar al menos dos variables de configuración:

• branch..remote =
• sucursal..merge = /ref/heads/

Eso es todo lo que hace este comando. Almacena información ascendente (es decir, repositorio remoto y sucursal) para la sucursal local en las variables de configuración.

La información ascendente se almacena bajo el nombre de la sucursal local. Si su sucursal local se llama mainlas respectivas variables de configuración son branch.main.remote y branch.main.merge. Según la forma en que se almacena esta información ascendente, una sucursal local no puede tener más de un único conjunto de información ascendente.

Puede consultar si alguna de estas variables de configuración está configurada usando git config --get-regexp ^branch\.. Esto generará cualquier variable que comience con “branch”.

La magia ocurre cuando estas variables de configuración son utilizadas, por ejemplo, git fetch, git pull o git push para averiguar el repositorio ascendente y la rama remota para una rama local si no los especifica explícitamente en la línea de comandos. Es decir, cuando se establecen estas variables de configuración, solo puede emitir git push y git sabrá (usando estas variables) el repositorio remoto y la rama ascendente para usar.

Lectura adicional sugerida:

• ¿Por qué tengo que “git push –set-upstream origin”?

Pero ten cuidado con las peculiaridades de git:

Si se proporciona como una URL o ruta de archivo, consulte, por ejemplo este ejemplo:

git push --set-upstream git@gitlab.example.com:namespace/myproject.git master

git push no crea una referencia a la cabecera de la sucursal remota en .git/refs/remotes/<repository>

Solo si al repositorio ascendente se le ha dado un nombre usando

git remote add <repository> <URL>

y git push --set-upstream se ha utilizado con este nombre, todo el poder de las ramas de seguimiento remoto está disponible en todos los comandos de git.

Lectura adicional sugerida:

• Git: Dificultad para hacer que el repositorio Git existente rastree el nuevo repositorio remoto desnudo

FYI: todos los comandos probados con git V2.32 en Windows.

--set-upstream no se trata solo de git branch -u o git push -u.

Tu también tienes git fetch --set-upstream y git pull --set-upstream.

Si el control remoto se obtiene con éxito, agregue una referencia ascendente (seguimiento), utilizada por sin argumentos git pull y otros comandos

Se establecerá:

• branch.<name>.remote
• branch.<name>.merge

Eso permitirá git push saber dónde para empujar, y a a qué rama remota empujar.

Pero: “git fetch --set-upstream“^(hombre) no verificó si hay una rama actual, lo que lleva a una defecto de segmento cuando se ejecuta en un cabeza separadaque se ha corregido con Git 2.35 (Q1 2022).

Ver cometer 17baeaf (07 dic 2021) por Ævar Arnfjörð Bjarmason (avar).
^{(Combinado por Junio ​​C Hamano — gitster — en cometer dcaf17c22 de diciembre de 2021)}

pull, fetch: arreglar segfault en la opción –set-upstream

^{Reportado por: Clemens Fruhwirth
Reportado por: Jan Pokorný
Firmado por: Ævar Arnfjörð Bjarmason}

Solucionar un error de segmentación en el --set-upstream opción añadida en 24bc1a1 (tirar, 2019-08-19, Git v2.24.0-rc0 — unir listado en lote #2) (tirar, buscar: add^(hombre) --set-upstream opción, 2019-08-19) agregado en v2.24.0.

El código agregado allí no hizo la misma verificación que hacemos para “git branch“^(hombre) mismo desde 8efb889 (“branch: corrección de errores de segmento y validación”, 2013-02-23, Git v1.8.3-rc0 — unir listado en lote #2), que a su vez arregló el mismo tipo de defecto de segmento que estoy arreglando ahora en “git branch --set-upstream-to“^(hombre)ver 6183d82 (“branch: introducir --set-upstream-to“, 2012-08-20, Git v1.8.0-rc0 — unir listado en lote #5).

El mensaje de advertencia que estoy agregando aquí es una amalgama del error agregado para “git branch” en 8efb889y la salida de error install_branch_config() sí mismo emite, es decir
se recorta”refs/heads/” del nombre y dice “branch X on remote“, no “branch refs/heads/X on remote“.

Nueva advertencia:

could not set upstream of HEAD to 'X' from 'X' 
when it does not point to any branch

Creo que tendría más sentido simplemente die() aquí, pero en los otros cheques para --set-upstream añadido en 24bc1a1emitimos una advertencia() en su lugar.
Hagamos lo mismo aquí por consistencia por ahora.

Hubo una forma alternativa enviada anteriormente de arreglar esto en este hilodebido a que ese parche interrumpió el enhebrado con el informe original en este hilo.
No lo noté antes de crear esta versión.
Creo que el mensaje de advertencia más detallado aquí es mejor, y también deberíamos tener pruebas para este comportamiento.

El --no-rebase opción a “git pull“^(hombre) es necesario a partir de la fusión reciente 7d0daf3 (“Merge branch ‘en/pull-conflicting-options'”, 2021-08-30, Git v2.34.0-rc0 — unir listado en lote #2).