L'uso di un repository centrale va contro lo scopo di GIT?

Question

Se ti trovi in ??un ambiente aziendale con molte persone che lavorano su una particolare applicazione, sta andando contro il grano di un controllo versione distribuita per avere un repository centrale ufficiale?

A volte faccio fatica a capire il concetto di un sistema di controllo di versione distribuito come GIT in un ambiente aziendale. Se non avessi un repository centrale, non sarebbe un PITA capire da chi aveva l'ultima versione aggiornata da cui estrarre, che ha la funzione x o la correzione di bug y che tutti devono prendere, ecc, ecc.

Sta sconfiggendo lo scopo di GIT usarlo in modo simile a SVN , con un repository centrale da cui tutti spingono / estraggono? Ogni volta che penso di farlo mi sembra di perdere il punto di tutto.

Qualcuno potrebbe illuminarmi?

Answer 1

Non proprio. DCVS offre solo maggiore libertà su come interagire tra gli sviluppatori senza coinvolgere il repository centrale. Il repository ufficiale è solo ufficiale per consenso . Linux ha anche un repository centrale, quello da cui il "ufficiale" vengono create le versioni del kernel, ma non vi è alcuna differenza fisica tra il repository centrale, "ufficiale", e il repository client come è in VCS centralizzato.

Answer 2

Probabilmente stai pensando secondo le linee di questo diagramma:

Probabilmente sembrerà un caos proveniente da un CVCS. " Abbiamo bisogno di un po 'd'ordine " ti sento dire?

  

Se non avessi un repository centrale, non sarebbe un PITA capire chi avesse l'ultima versione aggiornata da cui estrarre, chi ha la funzione x o bug fix y che tutti devono prendere, ecc., ecc. .

Sì. A differenza di un CVCS, in realtà non è davvero l'ultima versione di # 8221 ;. Se non c'è una posizione centrale, non sai immediatamente se vedere Sue, Joe o Eve per l'ultima versione. Una posizione centrale aiuta a chiarire ciò che è l'ultimo & # 8220; stabile & # 8221; il rilascio è.

Qualcosa di più simile a questo:

Potrebbe anche valere la pena notare che potrebbe esserci più di un repository centrale percepito a seconda delle competenze di gruppi di persone all'interno di un'organizzazione.

Immagina un project manager che gestisce più team di sviluppo, ogni team potrebbe avere un "centrale" repository a cui spingono. Ogni settimana, il project manager potrebbe inserire le modifiche da ciascun team nel suo "centrale" repository, uniscili e rimandali nella "centrale" delle sue squadre repository.

Questo probabilmente non è un grande esempio (sto ancora cercando di capire anche tutto questo), ma questo è solo un project manager. Aggiungete altri progetti / manager e team di controllo qualità, quindi potreste vedere da dove vengo ..

-

• Diagrammi e un paragrafo per gentile concessione di un articolo di Kalid Azad

Answer 3

Con controllo del codice sorgente distribuito, un "ufficiale" centrale il repository è stabilito dalla policy, non dall'architettura dello strumento di controllo del codice sorgente.

Answer 4

Sicuramente non sconfiggere lo scopo di Git.

Il vantaggio di usare Git o qualsiasi altro DVCS anche quando esiste un repository centrale, ufficiale, è ancora che il controllo del codice sorgente è decentralizzato. Cioè, puoi prendere la tua copia del repository, lavorare sul tuo codice ed eseguire un commit locale ogni pochi minuti se necessario. Non devi preoccuparti che gli commit siano su codice semifinito che rompe la build, è tutto locale. (E molto veloce.)

Quindi, quando tutto il lavoro è terminato, è possibile ripulire la cronologia e inviare le modifiche completate al repository centrale in uno stato omogeneo, pulito,

Non credo che tu possa sottovalutare il vantaggio di separare l'idea di "privato" si impegna e "pubblica" spinge. Permette di tenere traccia delle modifiche anche se sei l'unico a beneficiare di una così piccola granularità.

Answer 5

Se controlli questa Presentazione di Git , (diapositiva 475 e seguenti), un modello di repository centrale è perfettamente supportato da Git.

Puoi forzare chiunque desideri git push a svilupparlo per fare prima un git fetch + git merge , quindi premere.

Ciò non vanifica affatto lo scopo di Git e garantisce che tutti siano "sincronizzati" tra loro.

La differenza con il "funzionario" di Linus il repository menzionato da JesperE è che è gestito da un diverso flusso di lavoro, vale a dire un "dittatore e tenenti"; modello, in cui l'accesso in scrittura (push) è concesso solo per Linus e read è concesso a chiunque.

Ora: " questo sconfigge il punto di DVC " ?

No, hai ancora repository distribuiti, uno per ogni sviluppatore, e possono recuperare / unire tra i loro repository, in base al flusso di lavoro del proprio team interno.
Tuttavia, se vogliono contribuire al repository centrale, devono essere prima aggiornati con la cronologia più recente di tale repository.

Answer 6

Uno dei principali vantaggi di DVCS è che puoi ottenere l'ultima versione dal repository 'ufficiale' e quindi essere avventuroso con esso. È possibile eseguire il commit delle modifiche localmente e ripristinare a piacimento. Questo significa anche che puoi persino lavorare anche senza accesso al repository centrale e avere comunque i vantaggi del controllo del codice sorgente.

Penso che con un po 'di disciplina il modello funzioni molto bene. Questo articolo spiega bene i vari modelli che potresti adottare

Answer 7

DVCS come Git non ti costringono a usare un repository centrale. Ovviamente è possibile dichiarare che un repository è & # 8220; central & # 8221; o & # 8220; ufficiale & # 8221; o qualunque cosa, e in un contesto aziendale un repository centrale ha un senso & # 8212; se non per lo sviluppo, almeno per scopi di backup.