Quelle est la différence entre git push.default = current et push.default = upstream?

89

La page de manuel de git-config répertorie ces options pour 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.

Dans la plupart des cas, je suppose que pousser vers la branche amont d'une branche équivaudrait à pousser vers une branche du même nom, puisque la branche amont aurait normalement le même nom, et puisque la branche du même nom ("actuelle" ) serait normalement (ou toujours, par définition?) en amont. Alors, quelle est la différence?

MISE À JOUR : La page de manuel de git-config a été mise à jour (comme on pouvait s'y attendre), donc les distinctions qui y sont faitespeuvent être beaucoup plus claires maintenant.

git  git-branch  git-push 
— iconoclaste
source
2
pour les développeurs, il est en effet ennuyeux de les différer, donc «simple» est introduit, et sera le comportement par défaut pour git-push. en fait, il est apparu dans git 1.7.11
— xhlwill
14
Pour en savoir plus sur l'avertissement récent de git push.default is unset; its implicit value is changing in Git 2.0et sur matchingvs, simpleconsultez stackoverflow.com/questions/13148066/…
— Nate
iconoclaust: Je ne pense pas que ma modification ait du tout changé l'intégrité de la question, et les informations obsolètes doivent juste être corrigées. Pourquoi demander à l'utilisateur de faire le travail supplémentaire de cliquer sur le lien?
— Flimm

Réponses:

72

Vous avez résumé la différence dans votre question. upstreampousse vers la branche amont configurée , alors que currentsuppose que la branche amont a le même nom que la branche locale actuelle , et pousse vers ce nom spécifique. En réalité, il n'y a aucune raison de supposer que la branche de suivi en amont d'une branche locale porte le même nom que la branche locale elle-même.

Par exemple, si vous travaillez dans plusieurs référentiels ou sur de nombreuses télécommandes de développeurs partagées, vous finissez souvent par suivre différentes fourches de la même branche, telles que allen-masterou susan-master, qui suivent la masterbranche dans les dépôts d' Allen et de Susan, respectivement. Dans ce cas, ce currentserait le paramètre incorrect, car ces noms de branche n'existent pas sur leurs télécommandes. upstream, cependant, fonctionnerait très bien.

Un exemple plus pratique pourrait être le suivi à la fois d'un référentiel developmentet production. Votre flux de travail peut utiliser une branche principale différente pour chacun, mais cela peut prêter à confusion. Supposons que vous soyez un intégrateur de code et que vous vouliez suivre les masterbranches des deux référentiels séparément.

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

Maintenant, vous avez deux branches qui suivent leurs référentiels respectifs, aucune d'elles n'utilisant du tout la masterconvention de dénomination. Il y a peu de confusion sur les noms des branches: ils décrivent explicitement ce qu'ils suivent. Néanmoins, cela push.default = currentn'aurait aucun sens car aucune télécommande ne contient de branche developmentou production.

— Christophe
source
6
Vous donnez deux exemples pour savoir quand upstreamest préférable current. Je pense que c'est assez évident, vous devriez donc plutôt donner un exemple pour le cas contraire.
— AndreKR
1
@AndreKR AFAIK currentest meilleur dans le cas où vous êtes un nouveau développeur car vous n'avez pas besoin de git configbeaucoup, surtout si vous avez cloné de quelque part. currentpousse ou crée-puis-pousse-vers des branches homonymes sur le dépôt distant pour vous si elles n'existent pas déjà, alors que vous simplerefuserez de le faire carrément lorsqu'une branche du même nom n'existe pas déjà. upstreama le même comportement dans ce cas à moins qu'une branche amont n'ait été explicitement définie ou définie autrement comme mentionné dans la réponse de Yawar .
— Rarement 'Where's Monica' Needy
6

current poussera la branche actuelle vers une branche du même nom sur le référentiel distant.

upstream poussera la branche actuelle vers la branche amont.

La branche amont est une branche qui a été explicitement ou implicitement définie comme étant en amont de votre branche actuelle. Cela signifie que push and pull par défaut se synchronise avec cette branche. La branche amont peut être dans le même dépôt que la branche actuelle elle-même. Vous pouvez faire des choses intéressantes comme configurer votre branche principale locale en amont de votre branche de fonctionnalité locale (sujet), et pousser et tirer entre elles.

La configuration en amont implicite est effectuée via la branch.autosetupmergevaleur de configuration. Vous pouvez trouver de la documentation dans la git configpage d'aide. La configuration amont explicite est effectuée avec l' -uoption de la git branchcommande. Consultez la page d'aide pour plus de détails.

— Yawar
source
Je ne pense pas que branch.autoSetupMergece soit la même chose que -u/ --set-upstream. Au moins, je ne vois rien dans la documentation qui implique que git push se comporte comme s'il était appelé -upar défaut, ce qui me semble être ce que vous dites. Pouvez-vous clarifier ce que vous vouliez dire?
— waldyrious
@waldyrious sûr; lorsque vous extrayez une branche de suivi à distance, la branch.autoSetupMergeconfiguration crée par défaut une nouvelle branche locale et définit son amont comme branche de suivi à distance. Cette action implicite peut être effectuée explicitement en utilisant les indicateurs -t( --track) ou -u ...( --set-upstream-to=...), qui font la même chose avec des syntaxes légèrement différentes.
— Yawar
1
Je vois ce qui s'est passé ici - puisque cette question porte sur git push, j'ai supposé (à tort) que vous parliez de l' -uoption git pushplutôt que de l' -uoption git branch. Désolé pour la confusion :)
— waldyrious
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.