¿Cuál es la diferencia entre git push.default = current y push.default = upstream?

89

La página de manual de git-config enumera estas opciones para push.default:

nothing - do not push anything.
matching - push all matching branches. All branches having the same name in both ends are considered to be matching. This is the default.
upstream - push the current branch to its upstream branch.
tracking - deprecated synonym for upstream.
current - push the current branch to a branch of the same name.

En la mayoría de los casos, asumiría que empujar a una rama ascendente de una rama sería lo mismo que empujar a una rama del mismo nombre, ya que la rama ascendente normalmente tendría el mismo nombre, y dado que la rama del mismo nombre ("actual" ) normalmente (¿o siempre, por definición?) estaría aguas arriba. Entonces, ¿cuál es la diferencia?

ACTUALIZACIÓN : La página de manual de git-config se ha actualizado (como era de esperar), por lo que las distinciones hechas allí pueden ser mucho más claras ahora.

git  git-branch  git-push 
— iconoclasta
fuente
2
para los desarrolladores es realmente molesto diferenciarlos, por lo que se introduce 'simple' y será el comportamiento predeterminado de git-push. en realidad, apareció en git 1.7.11
— xhlwill
14
Para obtener más información sobre la advertencia reciente de git push.default is unset; its implicit value is changing in Git 2.0y sobre matchingvs, simpleconsulte stackoverflow.com/questions/13148066/…
— Nate
Iconoclaust: No creo que mi edición haya cambiado la integridad de la pregunta en absoluto, y la información desactualizada solo necesita ser corregida. ¿Por qué hacer que el usuario haga el trabajo adicional de hacer clic en el enlace?
— Flimm

Respuestas:

72

Ha resumido la diferencia en su pregunta. upstreamempuja a la rama ascendente configurada , mientras que currentasume que la rama ascendente tiene el mismo nombre que la rama local actual , y empuja a ese nombre específico. En realidad, no hay razón para suponer que la rama de seguimiento ascendente de una sucursal local tenga el mismo nombre que la sucursal local.

Por ejemplo, si trabaja en varios repositorios o en muchos controles remotos de desarrollador compartidos, a menudo termina rastreando diferentes bifurcaciones de la misma rama, como allen-mastero susan-master, las cuales rastrean la masterrama en los repositorios de Allen y Susan, respectivamente. En este caso, currentsería la configuración incorrecta, porque esos nombres de sucursales no existen en sus controles remotos. upstream, sin embargo, funcionaría bien.

Un ejemplo más práctico podría ser el seguimiento de un repositorio developmenty production. Su flujo de trabajo puede usar una rama de línea principal diferente para cada uno, pero eso puede resultar confuso. Suponga que es un integrador de código y desea rastrear las masterramas de ambos repositorios por separado.

git checkout -b production --track production/master
git checkout -b development --track development/master

Ahora tienes dos ramas que rastrean sus respectivos repositorios, ninguna de las cuales usa la masterconvención de nomenclatura en absoluto. Hay poca confusión sobre los nombres de las ramas: describen explícitamente lo que rastrean. Sin embargo, push.default = currentno tendría ningún sentido ya que ninguno de los controles remotos contiene una rama developmento production.

— Christopher
fuente
6
Estás dando dos ejemplos de cuándo upstreamse prefiere current. Creo que es bastante obvio, por lo que debería dar un ejemplo para el caso contrario.
— AndreKR
1
@AndreKR AFAIK currentes mejor en el caso de que seas un desarrollador nuevo porque no necesitas git configmucho, especialmente si has clonado desde algún lugar. currentempuja hacia o crea-luego-empuja-a ramas homónimas en el repositorio remoto por usted si aún no existen, mientras que simplese negará a hacer esto directamente cuando una rama del mismo nombre no exista ya. upstreamtiene el mismo comportamiento en este caso a menos que se haya establecido explícitamente una rama ascendente o se haya establecido de otra manera como se menciona en la respuesta de Yawar .
— Pocas veces '¿Dónde está Monica' necesitados
6

current empujará la rama actual a una rama con el mismo nombre en el repositorio remoto.

upstream empujará la rama actual a la rama ascendente.

La rama ascendente es una rama que se ha definido explícita o implícitamente como ascendente de su rama actual. Eso significa que empujar y tirar de forma predeterminada se sincronizará con esta rama. La rama ascendente puede estar en el mismo repositorio que la rama actual. Puede hacer cosas interesantes como configurar su rama maestra local como aguas arriba de su rama de característica local (tema) y empujar y tirar entre ellas.

La configuración ascendente implícita se realiza mediante el branch.autosetupmergevalor de configuración. Puede encontrar documentación en la git configpágina de ayuda. La configuración ascendente explícita se realiza con la -uopción del git branchcomando. Consulte la página de ayuda para obtener más detalles.

— Yawar
fuente
No creo branch.autoSetupMergeque piense lo mismo que -u/ --set-upstream. Al menos, no veo nada en la documentación que implique que hace que git push se comporte como si fuera llamado -upor defecto, que es lo que me parece que estás diciendo. ¿Puede aclarar lo que quiso decir?
— waldyrious
@waldyrious seguro; cuando está comprobando una rama de seguimiento remoto, la branch.autoSetupMergeconfiguración de forma predeterminada crea una nueva rama local y la establece en sentido ascendente como rama de seguimiento remoto. Esta acción implícita se puede realizar explícitamente utilizando las banderas -t( --track) o -u ...( --set-upstream-to=...), que hacen lo mismo con sintaxis ligeramente diferentes.
— Yawar
1
Veo lo que sucedió aquí: dado que esta pregunta es sobre git push, asumí (erróneamente) que estabas hablando de la -uopción de git push, en lugar de la -uopción de git branch. Perdón por la confusión :)
— waldyrious
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.