Qual è la differenza tra git clone –mirror e git clone –bare

La pagina della guida di clone git ha questo da dire su --mirror :

Configura un mirror del repository remoto. Questo implica – --bare .

Ma non entra nei dettagli su come il clone --mirror sia diverso da un clone --bare .

La differenza è che quando si usa --mirror , tutti i riferimenti vengono copiati così come sono . Questo significa tutto: rami di tracciamento remoto, note, riferimenti / originali / * (backup da filtro-ramo). Il repository clonato ha tutto. È anche configurato in modo che un aggiornamento remoto recuperi tutto dall’origine (sovrascrivendo i riferimenti copiati). L’idea è davvero quella di rispecchiare il repository, di avere una copia totale, in modo che tu possa ad esempio ospitare il repository centrale in più posizioni o eseguirne il backup. Pensa semplicemente a copiare il repository, tranne che in un modo molto più elegante.

La nuova documentazione dice quasi tutto questo:

--mirror

Configurare un mirror del repository di origine. Questo implica – --bare . Rispetto a --bare , --mirror non solo esegue il mapping dei rami locali della sorgente ai rami locali del target, ma mappa tutti i riferimenti (inclusi rami remoti, note, ecc.) E imposta una configurazione refspec in modo tale che tutti questi riferimenti vengano sovrascritti da un git remote update nel repository di destinazione.

La mia risposta originale ha anche rilevato le differenze tra un clone nudo e un clone normale (non nudo): il clone non nudo imposta i rami di monitoraggio remoto, creando solo un ramo locale per HEAD , mentre il clone nudo copia direttamente i rami.

Supponiamo che l’origine abbia pochi rami ( master (HEAD) , next , pu , e maint ), alcuni tag ( v1 , v2 , v3 ), alcuni rami remoti ( devA/master , devB/master ) e alcuni altri riferimenti ( refs/foo/bar , refs/foo/baz , che potrebbe essere note, stash, namespace di altri sviluppatori, chi lo sa).

  • git clone origin-url (non-bare): si otterranno tutti i tag copiati, un branch branch locale master (HEAD) traccia di un ramo origin/master ramo remoto, e origin/next remote origin/next , origin/pu , e origin/maint . I rami di tracciamento sono impostati in modo che se fai qualcosa come git fetch origin , essi verranno recuperati come previsto. Qualsiasi ramo remoto (nel telecomando clonato) e altri riferimenti sono completamente ignorati.

  • git clone --bare origin-url : si otterranno tutti i tag copiati, il branch branch master (HEAD) , next , pu , e maint , nessun ramo di tracciamento remoto. Cioè, tutti i rami sono copiati come sono, e sono impostati in modo completamente indipendente, senza alcuna aspettativa di recupero. Qualsiasi ramo remoto (nel telecomando clonato) e altri riferimenti sono completamente ignorati.

  • git clone --mirror origin-url : tutti gli ultimi ref saranno copiati così come sono. Otterrai tutti i tag, master (HEAD) diramazioni locali master (HEAD) , next , pu , e maint , diramazioni remote devA/master e devB/master , altri refs refs/foo/bar e refs/foo/baz . Tutto è esattamente come era nel telecomando clonato. Il monitoraggio remoto è impostato in modo tale che se esegui git remote update tutti i refs saranno sovrascritti dall’origine, come se avessi appena cancellato il mirror e lo avessi richiuso. Come hanno detto in origine i documenti, è uno specchio. Dovrebbe essere una copia funzionalmente identica, intercambiabile con l’originale.

 $ git clone --mirror $URL 

è una mano corta per

 $ git clone --bare $URL $ (cd $(basename $URL) && git remote add --mirror=fetch origin $URL) 

(Copiato direttamente da qui )

Come la mette in pratica la pagina man:

Rispetto a --bare , --mirror non solo esegue il mapping dei rami locali della sorgente ai rami locali del target, ma mappa tutti i riferimenti (inclusi rami remoti, note, ecc.) E imposta una configurazione refspec in modo tale che tutti questi riferimenti vengano sovrascritti da un git remote update nel repository di destinazione.

I miei test con git-2.0.0 oggi indicano che l’opzione –mirror non copia i hook, il file di configurazione, il file di descrizione, il file info / exclude, e almeno nel mio caso di test alcuni refs (che non uso t capire). Non lo chiamerei “copia funzionalmente identica, intercambiabile con l’originale”.

 -bash-3.2$ git --version git version 2.0.0 -bash-3.2$ git clone --mirror /git/hooks Cloning into bare repository 'hooks.git'... done. -bash-3.2$ diff --brief -r /git/hooks.git hooks.git Files /git/hooks.git/config and hooks.git/config differ Files /git/hooks.git/description and hooks.git/description differ ... Only in hooks.git/hooks: applypatch-msg.sample ... Only in /git/hooks.git/hooks: post-receive ... Files /git/hooks.git/info/exclude and hooks.git/info/exclude differ ... Files /git/hooks.git/packed-refs and hooks.git/packed-refs differ Only in /git/hooks.git/refs/heads: fake_branch Only in /git/hooks.git/refs/heads: master Only in /git/hooks.git/refs: meta 

Un clone copia i ref dal telecomando e li inserisce in una sottodirectory chiamata “questi sono i riferimenti che il telecomando ha”.

Uno specchio copia i ref dal telecomando e li mette nel suo livello superiore – sostituisce i propri ref con quelli del telecomando.

Ciò significa che quando qualcuno tira dal tuo specchio e riempie i ref del mirror nella loro sottodirectory, otterranno gli stessi refs dell’originale. Il risultato del recupero da un mirror aggiornato è lo stesso del recupero direttamente dal repository iniziale.

Una spiegazione dettagliata della documentazione di GitHub sulla duplicazione di un repository :

Come con un clone nudo, un clone con mirroring include tutti i rami e tag remoti, ma tutti i riferimenti locali saranno sovrascritti ogni volta che si recupera, quindi sarà sempre uguale al repository originale.

Aggiungo un’immagine, mostra la differenza di config tra mirror e bare. inserisci la descrizione dell'immagine qui La sinistra è spoglia, la destra è specchio. Puoi essere chiaro, il file di configurazione di mirror ha la chiave di fetch , il che significa che puoi aggiornarlo, con git remote update o git fetch --all