Qual è la differenza tra git push.default = current e push.default = upstream?

89

La pagina man di git-config elenca queste opzioni per 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.

Nella maggior parte dei casi presumo che spingere al ramo a monte di un ramo sarebbe lo stesso che spingere a un ramo con lo stesso nome, poiché il ramo a monte normalmente avrebbe lo stesso nome e poiché il ramo con lo stesso nome ("corrente" ) sarebbe normalmente (o sempre, per definizione?) essere a monte. Allora qual è la differenza?

UPDATE : La pagina man per git-config è stato aggiornato (come ci si aspetterebbe), quindi le distinzioni fatte ci può essere molto più chiaro ora.

git  git-branch  git-push 
— iconoclasta
fonte
2
per gli sviluppatori è davvero fastidioso differenziarli, quindi viene introdotto "semplice" e sarà il comportamento predefinito per git-push. in realtà è apparso in git 1.7.11
— xhlwill
14
Per ulteriori informazioni sul recente avviso di git push.default is unset; its implicit value is changing in Git 2.0e su matchingvs, simplevedere stackoverflow.com/questions/13148066/…
— Nate
iconoclaust: Non penso che la mia modifica abbia cambiato affatto l'integrità della domanda e le informazioni obsolete devono solo essere corrette. Perché costringere l'utente a fare il lavoro extra di fare clic sul collegamento?
— Flimm

Risposte:

72

Hai riassunto la differenza nella tua domanda. upstreamesegue il push al ramo a monte configurato , mentre currentassume che il ramo a monte abbia lo stesso nome del ramo locale corrente e esegue il push a quel nome specifico. In realtà, non c'è motivo di presumere che il ramo di tracciamento a monte di un ramo locale abbia lo stesso nome del ramo locale stesso.

Ad esempio, se lavori in più repository o su molti telecomandi di sviluppatori condivisi, spesso finisci per tracciare diversi fork dello stesso ramo, come allen-mastero susan-master, entrambi i quali tracciano il masterramo rispettivamente nei repository di Allen e Susan. In questo caso, currentsarebbe l'impostazione errata, perché quei nomi di ramo non esistono sui loro telecomandi. upstream, tuttavia, funzionerebbe perfettamente.

Un esempio più pratico potrebbe essere il monitoraggio sia di a developmentche di productionrepository. Il tuo flusso di lavoro potrebbe utilizzare un ramo principale diverso per ciascuno, ma ciò potrebbe creare confusione. Supponi di essere un integratore di codice e di voler monitorare masterseparatamente i rami di entrambi i repository .

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

Ora hai due rami che tengono traccia dei rispettivi repository, nessuno dei quali utilizza masteraffatto la convenzione di denominazione. C'è poca confusione sui nomi dei rami: descrivono esplicitamente ciò di cui tengono traccia. Tuttavia, push.default = currentnon avrebbe alcun senso in quanto nessuno dei due telecomandi contiene un ramo developmento production.

— Christopher
fonte
6
Stai fornendo due esempi per quando upstreamè preferibile current. Penso che sia abbastanza ovvio, quindi dovresti piuttosto fare un esempio per il caso opposto.
— AndreKR
1
@AndreKR AFAIK currentè meglio nel caso in cui sei uno sviluppatore nuovo perché non hai bisogno di git configmolto, soprattutto se hai clonato da qualche parte. currentspinge o crea-poi-spinge-a rami omonimi sul repository remoto per te se non esistono già, mentre simplesi rifiuterà di farlo a titolo definitivo quando un ramo con lo stesso nome non esiste già. upstreamha lo stesso comportamento in questo caso a meno che un ramo a monte non sia stato esplicitamente impostato o altrimenti impostato come menzionato nella risposta di Yawar .
— Raramente "Dov'è Monica" ha bisogno del
6

current invierà il ramo corrente a un ramo con lo stesso nome nel repository remoto.

upstream spingerà il ramo corrente al ramo a monte.

Il ramo a monte è un ramo che è stato definito esplicitamente o implicitamente come a monte del ramo corrente. Ciò significa che push and pull per impostazione predefinita si sincronizzerà con questo ramo. Il ramo a monte può trovarsi nello stesso repo del ramo corrente stesso. Puoi fare cose interessanti come impostare il tuo ramo principale locale come a monte del tuo ramo locale (argomento) e spingere e tirare tra di loro.

L'impostazione a monte implicita viene eseguita tramite il branch.autosetupmergevalore di configurazione. Puoi trovare la documentazione nella git configpagina della guida. L'impostazione a monte esplicita viene eseguita con l' -uopzione del git branchcomando. Vedere la pagina della guida per i dettagli.

— Yawar
fonte
Non credo branch.autoSetupMergeche pensi lo stesso di -u/ --set-upstream. Almeno, non vedo nulla nella documentazione che implichi che fa comportare git push come se fosse stato chiamato -uper impostazione predefinita, che è quello che mi sembra tu stia dicendo. Puoi chiarire cosa intendevi?
— waldyrious
@waldyrious sicuro; quando si effettua il check out di un ramo di monitoraggio remoto, la branch.autoSetupMergeconfigurazione per impostazione predefinita crea un nuovo ramo locale e lo imposta a monte come ramo di monitoraggio remoto. Questa azione implicita può essere eseguita esplicitamente usando i flag -t( --track) o -u ...( --set-upstream-to=...), che fanno la stessa cosa con sintassi leggermente diverse.
— Yawar
1
Capisco cosa è successo qui - poiché questa domanda riguarda git push, io (erroneamente) presumo che tu stia parlando -udell'opzione di git push, piuttosto che -udell'opzione di git branch.
— Ci
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.