Git - Qual è la differenza tra push.default "matching" e "simple"


285

Sto usando git da un po 'di tempo, ma non ho mai dovuto creare un nuovo repository remoto e sono stato curioso di farlo. Ho letto tutorial e sono confuso su come far funzionare "git push".

Se lo uso semplicemente git pushmi chiede di vedere un ramo predefinito (?) A cui puntare? Qual è la differenza tra queste due opzioni che mi fornisce?

git config --global push.default matching
git config --global push.default simple

L'abbinamento semplicemente spinge qualsiasi ramo ho sul mio repository locale, e se non corrispondono devo dirlo manualmente a spingere qualsiasi nuovo ramo locale che ho, giusto? È questa best practice da utilizzare o è semplicemente la migliore?



1
Ora, se solo pull.defaultfosse disponibile per l'aggiornamento di tutte quelle filiali localmente
Nogurenn,

Risposte:


368

git push può spingere tutti i rami o uno solo a seconda di questa configurazione:

Spingere tutti i rami

git config --global push.default matching

Spingerà tutti i rami al ramo remoto e li unirebbe. Se non vuoi spingere tutti i rami, puoi spingere solo il ramo corrente.

Spingere solo il ramo corrente

git config --global push.default simple

Quindi, secondo me, è meglio usare questa opzione e spingere il tuo codice ramo per ramo. È meglio spingere i rami manualmente e individualmente.


16
Mi è piaciuta la push.default currentrisposta di @UpAndAdam. Non lo sapeva.
Alanjds,

4
Nota che simplenon è più un'opzione. In 1.7.8.4(e precedenti?) Si verifica un errore quando si tenta di inviare. ma currentè ancora disponibile
sixty4bit

@ sixty4bit: sto usando git versione 1.7.1. Sto usando tracking-> spingere il ramo corrente al suo ramo a monte.
kevinarpe,

@ sixty4bit No, è stato incluso in una versione successiva di Git, ma non so in quale, ma (1.7) è vecchio come l'inferno, anche per il 2016. Non consiglierei affatto di usare versioni così vecchie.
Schmoudi,

Downvoted. Siamo spiacenti, ma la descrizione della pagina collegata di simplenon ha senso, contraddice questa risposta ed è errata, il che rende questa risposta confusa. La pagina collegata dice simple"spingerà i rami uno per uno. Principalmente collegati al ramo corrente". Ciò significa che spingerà i rami in sequenza anziché in parallelo? Che cosa significa "principalmente connesso"? Quindi, la descrizione per simpleprosegue citando la descrizione per la matchingquale si potrebbe pensare che la descrizione per matchingvale anche per simple. Ma ovviamente questo non è vero.
tvanc,

91

Dalla documentazione GIT: Git Docs

Di seguito fornisce le informazioni complete. In breve, simplespingerà solo current working branche anche solo se avrà anche lo stesso nome sul telecomando. Questa è un'ottima impostazione per i principianti e diventerà l'impostazione predefinita inGIT 2.0

Considerando matchingche spingerà tutti i rami localmente che hanno lo stesso nome sul telecomando. (Indipendentemente dal tuo attuale ramo di lavoro). Ciò significa che potenzialmente verranno spinti molti rami diversi, inclusi quelli che potresti non voler condividere.

Nel mio uso personale, generalmente utilizzo un'opzione diversa: currentche spinge l'attuale ramo di lavoro, (perché mi ramifico sempre per eventuali modifiche). Ma per un principiante suggerireisimple

push.default
Definisce l'azione che git push dovrebbe intraprendere se nessuna refspec viene esplicitamente fornita. Valori diversi sono adatti per flussi di lavoro specifici; ad esempio, in un flusso di lavoro puramente centrale (ovvero la fonte di recupero è uguale alla destinazione push), probabilmente è quello a monte quello che vuoi. I valori possibili sono:

niente - non spingere nulla (errore) a meno che non venga esplicitamente dato un refspec. Questo è principalmente pensato per le persone che vogliono evitare errori essendo sempre esplicite.

corrente: premere il ramo corrente per aggiornare un ramo con lo stesso nome sull'estremità ricevente. Funziona in flussi di lavoro sia centrali che non centrali.

upstream: rimanda il ramo corrente al ramo le cui modifiche sono generalmente integrate nel ramo corrente (che si chiama @ {upstream}). Questa modalità ha senso solo se si sta spingendo nello stesso repository da cui normalmente si preleva (ovvero flusso di lavoro centrale).

semplice: nel flusso di lavoro centralizzato, funziona come a monte con una sicurezza aggiuntiva per rifiutare di spingere se il nome della diramazione a monte è diverso da quello locale.

Quando si spinge verso un telecomando diverso dal telecomando da cui si estrae normalmente, lavorare come corrente. Questa è l'opzione più sicura ed è adatta per i principianti.

Questa modalità diventerà quella predefinita in Git 2.0.

matching - spinge tutti i rami con lo stesso nome su entrambe le estremità. Questo rende il repository che stai spingendo per ricordare l'insieme di rami che verranno espulsi (ad es. Se spingi sempre maint e master lì e nessun altro ramo, il repository a cui spingi avrà questi due rami e il tuo maint e master locale verrà spinto lì).

Per utilizzare questa modalità in modo efficace, è necessario assicurarsi che tutti i rami che si espellere siano pronti per essere espulsi prima di eseguire git push, poiché l'intero punto di questa modalità è consentire di spingere tutti i rami in una volta sola. Se di solito finisci di lavorare su un solo ramo e estrai il risultato, mentre altri rami non sono finiti, questa modalità non fa per te. Inoltre, questa modalità non è adatta per l'inserimento in un repository centrale condiviso, in quanto altre persone possono aggiungere lì nuove filiali o aggiornare la punta delle filiali esistenti al di fuori del tuo controllo.

Questo è attualmente il valore predefinito, ma Git 2.0 cambierà il valore predefinito in semplice.


sì, ma suppongo anche con l'impostazione push.default che se fai "$ git push origin master ", spingerà solo il ramo corrente verso l'origine sul ramo sull'origine con lo stesso nome ... giusto? dovresti dire che esiste anche un telecomando predefinito
Alexander Mills

1
Non sono sicuro di capire a cosa stai arrivando. In QUALSIASI MODALITÀ se dici git push origin masterche farà la stessa cosa. Il punto delle modalità e delle impostazioni predefinite è generalmente ciò che accade quando si dice semplicemente git pushe non si dice un telecomando o un ramo. Quale impostazione predefinita? intendi l'impostazione predefinita di push.default? l'impostazione predefinita in quale versione di git ... se non lo capisci il tuo commento è estremamente vago.
UpAndAdam,

'push.default Definisce l'azione che git push dovrebbe intraprendere se nessun refspec viene esplicitamente dato' se dici che git push origin master gli stai dando più informazioni e potrebbe ancora non fare quello che descrivi; a seconda del refspec impostato .. git-scm.com/book/en/v2/Git-Internals-The-Refspec
UpAndAdam

2

Note di rilascio di Git v2.0

Note sulla compatibilità con le versioni precedenti

Quando git push [$there]non dice cosa spingere, finora abbiamo usato la tradizionale semantica "matching" (tutti i tuoi rami sono stati inviati al telecomando fintanto che ci sono già rami con lo stesso nome laggiù). In Git 2.0, l'impostazione predefinita è ora la semantica "semplice", che spinge:

  • solo il ramo corrente al ramo con lo stesso nome e solo quando il ramo corrente è impostato per integrarsi con quel ramo remoto, se si sta spingendo sullo stesso telecomando da cui si preleva; o

  • solo il ramo corrente al ramo con lo stesso nome, se si sta spingendo su un telecomando che non è il punto da cui in genere si preleva.

È possibile utilizzare la variabile di configurazione "push.default" per modificare questo. Se sei un vecchio timer che desidera continuare a utilizzare la semantica "matching", ad esempio, puoi impostare la variabile su "matching". Leggi la documentazione per altre possibilità.

Quando git add -ue git add -Avengono eseguiti all'interno di una sottodirectory senza specificare quali percorsi aggiungere sulla riga comandi, operano su tutto l'albero per coerenza con git commit -ae altri comandi (questi comandi utilizzati per operare solo sulla sottodirectory corrente). Dire git add -u .ogit add -A . se si desidera limitare l'operazione alla directory corrente.

git add <path>è lo stesso di git add -A <path>adesso, quindi git add dir/noterai i percorsi rimossi dalla directory e registrerai la rimozione. Nelle versioni precedenti di Git, git add <path>utilizzato per ignorare le rimozioni. Puoi dire git add --ignore-removal <path>di aggiungere solo percorsi aggiunti o modificati <path>, se lo desideri davvero.

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.