Qual è la differenza-pratica- tra un repository Bare e non Bare?

220

Ho letto dei repositor nudi e non nudi / predefiniti in Git. Non sono stato in grado di capire abbastanza bene (teoricamente) le differenze tra loro e perché dovrei "spingere" a un repository nudo. Ecco l'accordo:

Al momento, sono l'unico a lavorare su un progetto su 3 computer diversi, ma ci saranno più persone coinvolte in seguito, quindi sto usando Git per il controllo della versione. Clone il repository nudo su tutti i computer e quando finisco le mie modifiche su uno di essi, eseguo il commit e inserisco le modifiche nel repository nudo. Da quello che ho letto, il repository nudo NON ha un "albero funzionante", quindi se clono il repository nudo, non avrò un "albero funzionante".

Immagino che l'albero di lavoro memorizzi le informazioni di commit, i rami, ecc. Dal progetto. Non apparirebbe nel nudo repo. Quindi mi sembra meglio "spingere" i commit nel repository con l'albero funzionante.

Allora, perché dovrei usare il repository nudo e perché no? Qual è la differenza pratica? Ciò non sarebbe vantaggioso per più persone che lavorano a un progetto, suppongo.

Quali sono i tuoi metodi per questo tipo di lavoro? Suggerimenti?

git  repository  git-bare 
— AeroCross
fonte
4
AeroCross, puoi clonare un repository nudo per creare un repository non nudo (cioè uno che ha un'area di lavoro). Quindi, usando git clonepuoi convertire liberamente tra repository nudi e non nudi.
— Derek Mahar
13
@AeroCross: non si tratta di convertire; non importa cosa c'è dall'altra parte. Se corri git clone --bareotterrai un repository nudo, e se corri git clone, ne otterrai uno non nudo. Ogni progetto pubblico che hai mai clonato (ospitato su GitHub, ad esempio) è un semplice repository dall'altra parte.
— Cascabel
1
Jefromi, stavo correggendo il punto di AeroCross, "quindi se clono il repo nudo, non avrò un" albero funzionante "", quindi è una sorta di conversione. E non tutti i progetti pubblici devono essere un semplice archivio. È solo la scelta tipica perché un repository nudo è più efficiente in termini di spazio poiché non ha un albero funzionante (è efficiente in termini di spazio come qualsiasi repository che non ha un albero funzionante, però).
— Derek Mahar
2
@Derek: Ma il punto è che, non appena trova la directory .git, il recupero è del tutto inconsapevole se il telecomando è nudo o meno. Non converte. Prende semplicemente ciò di cui ha bisogno dal telecomando e lo posiziona dove dovrebbe andare. Non c'è niente da convertire. Questo è quello che stavo cercando di sottolineare all'OP. E sono ben consapevole che i progetti pubblici non devono essere nudi, ma poiché le persone non sono stupide, essenzialmente lo sono tutti. Penso di aver fatto una generalizzazione accettabile.
— Cascabel
2
Vedere Push to non-bare repository che fornisce un'altra eccellente spiegazione dell'utilizzo del bare repository.
— Craig McQueen

Risposte:

97

Un'altra differenza tra un repository bare e non-bare è che un repository bare non ha un repository di origine remota predefinito :

~/Projects$ git clone --bare test bare
Initialized empty Git repository in /home/derek/Projects/bare/
~/Projects$ cd bare
~/Projects/bare$ git branch -a
* master
~/Projects/bare$ cd ..
~/Projects$ git clone test non-bare
Initialized empty Git repository in /home/derek/Projects/non-bare/.git/
~/Projects$ cd non-bare
~/Projects/non-bare$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

Dalla pagina del manuale per git clone --bare:

Anche i branch head sul telecomando vengono copiati direttamente nei corrispondenti branch locali, senza mapparli a refs / remotes / origin /. Quando si utilizza questa opzione, non vengono creati né i rami di monitoraggio remoto né le variabili di configurazione correlate.

Presumibilmente, quando crea un repository nudo, Git presume che il repository nudo fungerà da repository di origine per diversi utenti remoti, quindi non crea l'origine remota predefinita. Ciò significa che le operazioni di base git pulle le git pushoperazioni non funzioneranno poiché Git presume che senza uno spazio di lavoro non si intenda applicare alcuna modifica al repository nudo:

~/Projects/bare$ git push
fatal: No destination configured to push to.
~/Projects/bare$ git pull
fatal: /usr/lib/git-core/git-pull cannot be used without a working tree.
~/Projects/bare$
— Derek Mahar
fonte
1
Sì, sono d'accordo sul fatto che questa è probabilmente la differenza più significativa tra i repository Git nudi e non nudi. Il fatto che un repository non nudo abbia uno spazio di lavoro, ma un archivio nudo non è una differenza importante, ma git clone --no-checkoutpuò anche creare un archivio non nudo senza file dell'area di lavoro.
— Derek Mahar
11
Un repository non nudo non ha necessariamente nemmeno una "origine" remota predefinita.
— mipadi
2
Puoi creare un repository Git semplicemente con git init, che creerà un repository non nudo senza telecomando specificato.
— mipadi
1
mipadi, questo è vero, ma non è nemmeno un clone.
— Derek Mahar
1
Questo non è corretto. Un repository avrà un'origine predefinita se è stato modificato clone. Se è stato modificato initlocalmente, non avrà tale origine. Questo non ha nulla a che fare con il fatto che sia nudo o no.
— Noufal Ibrahim
65

5 anni troppo tardi, lo so, ma nessuno ha risposto alla domanda:

Allora, perché dovrei usare il repository nudo e perché no? Qual è la differenza pratica? Ciò non sarebbe vantaggioso per più persone che lavorano a un progetto, suppongo.

Quali sono i tuoi metodi per questo tipo di lavoro? Suggerimenti?

Per citare direttamente dal libro Loeliger / MCullough (978-1-449-31638-9, p196 / 7):

Un semplice archivio potrebbe sembrare di scarsa utilità, ma il suo ruolo è cruciale: fungere da autorevole punto focale per lo sviluppo collaborativo. Altri sviluppatori clonee fetchdal repository nudo e gli pushaggiornamenti ad esso ... se si imposta un repository in cui gli sviluppatori pushcambiano, dovrebbe essere nudo. In effetti, questo è un caso speciale della migliore pratica più generale che un repository pubblicato dovrebbe essere nudo.

— EML
fonte
64

La distinzione tra un repository Git nudo e non nudo è artificiale e fuorviante poiché uno spazio di lavoro non fa parte del repository e un repository non richiede uno spazio di lavoro. A rigor di termini, un repository Git include quegli oggetti che descrivono lo stato del repository. Questi oggetti possono esistere in qualsiasi directory, ma in genere esistono nella .gitdirectory nella directory di primo livello dell'area di lavoro. Lo spazio di lavoro è un albero di directory che rappresenta un particolare commit nel repository, ma può esistere in qualsiasi directory o non esistere affatto. La variabile d'ambiente $GIT_DIRcollega uno spazio di lavoro al repository da cui ha origine.

I comandi Git git cloneed git initentrambi hanno opzioni --bareche creano repository senza uno spazio di lavoro iniziale. È un peccato che Git fonda i due concetti separati ma correlati di spazio di lavoro e repository e quindi utilizzi il termine confuso nudo per separare le due idee.

— Derek Mahar
fonte
63

Un semplice repository non è altro che la cartella .git stessa, cioè il contenuto di un semplice repository è lo stesso del contenuto della cartella .git all'interno del tuo repository di lavoro locale.

  • Usa un repository nudo su un server remoto per consentire a più contributori di spingere il loro lavoro.
  • Non nudo: quello che ha un albero funzionante ha senso sulla macchina locale di ogni collaboratore del progetto.
— Deepak Sharma
fonte
20

Un repository non nudo ha semplicemente un albero di lavoro estratto. L'albero di lavoro non memorizza alcuna informazione sullo stato del repository (rami, tag, ecc.); piuttosto, l'albero di lavoro è solo una rappresentazione dei file effettivi nel repository, che consente di lavorare (modificare, ecc.) sui file.

— mipadi
fonte
Quindi questo significa che posso aggiungere rami, tag, ecc. Al repository nudo e poi tirare dal repository nudo a quello non nudo / di produzione?
— AeroCross
2
mipadi, un repository non nudo potrebbe non avere un albero estratto. Questo è il caso se crei un repository non nudo con git clone --no-checkout. In questo caso, il repository non nudo ha una posizione per lo spazio di lavoro, ma Git non esegue il checkout di alcun file in quell'area di lavoro.
— Derek Mahar
17

Un repository nudo ha vantaggi in

  • utilizzo del disco ridotto
  • meno problemi legati al push remoto (poiché nessun albero funzionante è lì per perdere la sincronizzazione o avere modifiche in conflitto)
— sehe
fonte
3
Quindi il repository nudo è il modo migliore / consigliato per lavorare con più persone senza accesso ai LORO repository? (Un po 'come SVN?)
— AeroCross
2
AeroCross, direi che un archivio nudo è una buona scelta per quello scenario.
— Derek Mahar
Ho pensato che il messaggio "n commit in anticipo" fosse correlato ai rami (cioè refs) e non correlato agli alberi funzionanti.
— aderchox
@aderchox Sì, niente qui lo contraddice?
— guarda il
1
@aderchox Se il repo remoto non è nudo, si potrebbe causare il worktree per ottenere fuori sincrono con una testa controllato pure. Questo è il motivo per cui non sarebbe consentito, e quindi il vantaggio di avere un semplice repo (in pratica, semplicemente non avere un albero di lavoro)
— guarda il
13

Un repository Git predefinito / non nudo contiene due parti di stato:

  1. Una fotografia istantanea di tutti i file nel repository (questo è ciò che significa "albero di lavoro" in Git gergo)
  2. Una cronologia di tutte le modifiche apportate a tutti i file che sono mai stati nel repository (non sembra esserci un pezzo conciso di gergo Git che racchiude tutto questo)

L' istantanea è ciò che probabilmente pensi come il tuo progetto: i tuoi file di codice, i file di compilazione, gli script di supporto e qualsiasi altra cosa che esegui con Git.

La cronologia è lo stato che ti consente di controllare un commit diverso e ottenere un'istantanea completa di come apparivano i file nel tuo repository quando quel commit è stato aggiunto. Consiste in un mucchio di strutture dati interne a Git con cui probabilmente non hai mai interagito direttamente. È importante sottolineare che la cronologia non si limita a memorizzare i metadati (ad es. "L'utente U ha aggiunto molte righe al file F all'ora T come parte del commit C"), ma memorizza anche i dati (ad es. "L'utente U ha aggiunto queste righe esatte al file F" ).

L'idea chiave di un semplice repository è che in realtà non è necessario disporre dell'istantanea. Git mantiene l'istantanea in giro perché è conveniente per gli esseri umani e altri processi non Git che vogliono interagire con il tuo codice, ma l'istantanea è solo la duplicazione dello stato che è già nella cronologia.

Un repository nudo è un repository Git che non dispone di uno snapshot. Memorizza solo la cronologia.

perchè vorresti questo? Bene, se hai intenzione di interagire con i tuoi file solo usando Git (cioè, non modificherai direttamente i tuoi file o li userai per creare un eseguibile), puoi risparmiare spazio non mantenendo l'istantanea. In particolare, se stai mantenendo una versione centralizzata del tuo repository su un server da qualche parte (cioè stai fondamentalmente ospitando il tuo GitHub), quel server dovrebbe probabilmente avere un repository nudo (useresti comunque un repository non nudo sul tuo macchina locale, tuttavia, poiché presumibilmente vorrai modificare la tua istantanea).

Se desideri una spiegazione più approfondita dei repository nudi e un altro caso d'uso di esempio, ho scritto un post sul blog qui: https://stegosaurusdormant.com/bare-git-repo/

— Greg Owen
fonte
12

Il repository non nudo ti consente di (nel tuo albero di lavoro) catturare le modifiche creando nuovi commit.

I repository nudi vengono modificati solo trasferendo le modifiche da altri repository.

— Nitin
fonte
10

Non sono certo un "esperto" di Git. Ho usato TortoiseGit per un po 'e mi sono chiesto di cosa stesse parlando quando mi ha chiesto se volevo creare un repository "nudo" ogni volta che ne ho creato uno. Stavo leggendo questo tutorial: https://www.atlassian.com/git/tutorials/setting-up-a-repository/git-init e risolve il problema, ma non stavo ancora comprendendo del tutto il concetto. Questo ha aiutato molto: http://bitflop.com/tutorials/git-bare-vs-non-bare-repositories.html . Ora, anche il primo ha senso!

Secondo queste fonti, in poche parole un repo "nudo" viene utilizzato su un server in cui si desidera impostare un punto di distribuzione. Non è previsto per l'uso sulla macchina locale. In genere si inviano i commit dalla macchina locale a un repository nudo su un server remoto e tu e / o altri tirate da quel repository nudo alla vostra macchina locale. Quindi il tuo repository di archiviazione / distribuzione remota GitHub, Assembla, ecc. È un esempio in cui viene creato un repository "nudo". Ne faresti uno tu stesso se stessi creando il tuo analogo "centro di condivisione".

— BuvinJ
fonte
ooooh ora ho capito
— Fuseteam
4

Questa non è una risposta nuova, ma mi ha aiutato a capire i diversi aspetti delle risposte sopra (ed è troppo per un commento).

Usando Git Bash prova semplicemente:

me@pc MINGW64 /c/Test
$ ls -al
total 16
drwxr-xr-x 1 myid 1049089 0 Apr  1 11:35 ./
drwxr-xr-x 1 myid 1049089 0 Apr  1 11:11 ../

me@pc MINGW64 /c/Test
$ git init
Initialized empty Git repository in C:/Test/.git/

me@pc MINGW64 /c/Test (master)
$ ls -al
total 20
drwxr-xr-x 1 myid 1049089 0 Apr  1 11:35 ./
drwxr-xr-x 1 myid 1049089 0 Apr  1 11:11 ../
drwxr-xr-x 1 myid 1049089 0 Apr  1 11:35 .git/

me@pc MINGW64 /c/Test (master)
$ cd .git

me@pc MINGW64 /c/Test/.git (GIT_DIR!)
$ ls -al
total 15
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:35 ./
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:35 ../
-rw-r--r-- 1 myid 1049089 130 Apr  1 11:35 config
-rw-r--r-- 1 myid 1049089  73 Apr  1 11:35 description
-rw-r--r-- 1 myid 1049089  23 Apr  1 11:35 HEAD
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:35 hooks/
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:35 info/
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:35 objects/
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:35 refs/

Lo stesso con git --bare:

me@pc MINGW64 /c/Test
$ ls -al
total 16
drwxr-xr-x 1 myid 1049089 0 Apr  1 11:36 ./
drwxr-xr-x 1 myid 1049089 0 Apr  1 11:11 ../

me@pc MINGW64 /c/Test
$ git init --bare
Initialized empty Git repository in C:/Test/

me@pc MINGW64 /c/Test (BARE:master)
$ ls -al
total 23
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:36 ./
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:11 ../
-rw-r--r-- 1 myid 1049089 104 Apr  1 11:36 config
-rw-r--r-- 1 myid 1049089  73 Apr  1 11:36 description
-rw-r--r-- 1 myid 1049089  23 Apr  1 11:36 HEAD
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:36 hooks/
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:36 info/
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:36 objects/
— Christoph
fonte
2

$ git help repository-layout

Un repository Git è disponibile in due versioni differenti:

  • una directory .git alla radice dell'albero di lavoro;
  • una directory .git che è nudo repository (cioè senza il suo albero di lavoro), che viene in genere utilizzato per scambiare storie con altri spingendolo in esso e il recupero da esso.
— MichK
fonte
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.