2013-10-20 18 views
5

Sono nuovo in git e ho qualche dubbio: Qual è la differenza con l'inizializzazione di un repository come personale o come centrale?Git Extensions - Differenze tra repository personale e repository centrale

Immagino che se stabilisco come centrale, tutti i membri del mio team possono accedervi. Tuttavia, se inizializzo come personale, sono l'unico a cui posso accedere (gli altri membri del mio team non possono accedervi). Ho ragione?

Qualcuno potrebbe confermare se ho ragione e che cosa è la differenza tra i repository personali e centrali a git? e per il repository centrale, cosa significa bare?

+4

Non si stanno utilizzando termini git standard. Non esiste un repository "centrale" o "personale". Git non ha nemmeno il controllo di accesso integrato per la maggior parte. Intendi l'inizializzazione con '--bare' rispetto al non utilizzo? –

+0

Sto usando le estensioni git scusate. Così, quando provo a inizializzare il repository, chiedo di inizializzare come repository personale (non nudo) o centrale (nudo). Tra parentesi, per centrale, si dice (--bare --shared = all). – user304602

+1

In questo caso, un repository nullo significa semplicemente che non è stato controllato alcun albero di lavoro; tutto ciò che è memorizzato su disco è la cartella '.git' e il suo contenuto. Un repository regolare ha un albero di lavoro estratto, il che significa che i file memorizzati nel repository sono disponibili per la modifica e il lavoro. –

risposta

7

Il repository non è nudo sviluppatori uno usa - ha una copia di lavoro estratto, cioè il codice è direttamente disponibile.

In caso di un repository nudo tutto ciò che è v'è il contenuto della cartella .git. Questo è ottimo per spingere/tirare su/dal repository ma per ovvi motivi non adatti per visualizzare il codice direttamente o lavorare sul codice.

Quindi, quando si desidera sviluppare materiale si desidera un repository non nudo. Quando vuoi spingere su un'altra macchina, creane una nuda e spingila da quella non nuda. Se usi, ad es. GitHub non creerà quel repository nudo manualmente - lo creerai sul sito web (che di solito ne crea uno nudo internamente e configura il controllo di accesso) e poi lo configurerai come remoto in locale (l'indirizzo del repository verrà visualizzato in modo da è necessario copiare & incollarlo).

+0

Quindi, come ho capito, la prima volta, quando è l'origine, è meglio usare un repository nudo. Quindi i membri del team possono clonarlo nel loro computer locale come non bare per poter lavorare, pe, apportare modifiche, ecc ... Infine, quando un membro del team vuole impegnare le sue modifiche per far sì che gli altri membri del team lo vedano cambia, egli commette i suoi cambiamenti. Ho ragione? Una volta che le modifiche sono state commesse, come gli altri membri del team possono aggiornare il loro codice clonato per vedere quelle modifiche? – user304602

+1

In genere inizio con un repository non nullo e lavoro da solo lì. Quando è il momento di coordinarsi con gli altri, creo un repository vuoto vuoto su un server e spingo il mio lavoro fino a questo punto. –

3

Git è distribuito. Se permetti ad altre persone di accedere al tuo repository, possono scaricare/tirare direttamente da te. In questo caso non hai nemmeno bisogno di un repo centrale e il master è proprio quello che decidi di essere.

Il repository bare è un dato che si trova nel proprio archivio personale .git. Nella tua cartella di lavoro hai dati reali (file .c se sei C-programmatore) e una cartella .git con repository che è storia e tutti gli altri dati necessari. Bare non ha bisogno di "dati estratti", quindi è solo file .git.

Il repository bare funziona come il repository personale e viceversa. L'eccezione è quando si tratta di gestire i dati locali, perché il repository nudo lo ha, perché non ne ha bisogno.

Ci sono diverse opzioni su come organizzare il repository. In ogni caso ogni persona ha un repo locale.

repository remoti sono tutti nudi, si può avere solo repo remoto o ogni memeber ha il proprio repository remoto, che enyone può leggere in qualsiasi momento. Quest'ultima versione è utilizzata da github e la prima opzione con singolo telecomando è repo centralizzato (configurazione simile a SVN)

3

Ritengo che i due stati siano pubblici e privati.

Privato.
Il privato è solo per me. È utile avere il mio codice nel cloud, è stato eseguito il backup e posso scaricarlo su qualsiasi macchina che utilizzo.

pubblico. Pubblico è per la condivisione con altre persone ("collaboratori") le cui chiavi sono state inserite nel progetto.