Perché tutti usano Git in modo centralizzato?

Ahh, ma in effetti stai usando git in modo decentralizzato!

Confrontiamo il predecessore di git in mindshare, svn. Subversion aveva solo un "repo", una fonte di verità. Quando hai fatto un commit, era per un singolo repository centrale, a cui anche altri sviluppatori si stavano impegnando.

Questo tipo di ha funzionato, ma ha portato a numerosi problemi, il più importante è il temuto unire conflitto . Questi si rivelarono ovunque da fastidiosi a incubi da risolvere. E con una sola fonte di verità, avevano la brutta abitudine di portare il lavoro di tutti a uno stridore fino a quando non fossero risolti. I conflitti di unione esistono sicuramente con git, ma non sono eventi che fermano il lavoro e sono molto più facili e veloci da risolvere; generalmente riguardano solo gli sviluppatori coinvolti con le modifiche in conflitto, piuttosto che tutti.

Poi c'è l'intero single point of failure e i problemi che ne derivano. Se il tuo repository centrale svn muore in qualche modo, sei tutto fregato fino a quando non può essere ripristinato dal backup, e se non ci sono stati backup, sei tutti doppiamente fregato. Ma se il repository "centrale" git muore, è possibile ripristinare dal backup, o anche da una delle altre copie del repository che si trovano sul server CI, sulle workstation degli sviluppatori, ecc. È possibile farlo esattamente perché sono distribuiti, e ogni sviluppatore ha una copia di prima classe del repository.

D'altra parte, dal momento che il tuo repository git è un repository di prima classe a pieno titolo, quando esegui il commit, i tuoi commit vengono inviati al repository locale. Se vuoi condividerli con gli altri o con la fonte centrale della verità, devi farlo esplicitamente con una spinta verso un remoto. Altri sviluppatori possono quindi abbattere tali modifiche quando è conveniente per loro, piuttosto che dover controllare costantemente svn per vedere se qualcuno ha fatto qualcosa che potrebbe rovinarli.

Il fatto che, invece di spingere direttamente ad altri sviluppatori, li spinga indirettamente tramite un altro repository remoto, non importa molto. La parte importante dal nostro punto di vista è che la copia locale del repository è un repository a sé stante. In svn, la fonte centrale della verità è imposta dal design del sistema. In git, il sistema non ha nemmeno questo concetto; se c'è una fonte di verità, è decisa esternamente.

Quando il tuo server di build (tu sei usando CI, giusto?) crea una build, da dove viene estratto? Certo, una build di integrazione che potresti argomentare non ha bisogno di "un vero repository" ma sicuramente una build di distribuzione (cioè ciò che dai al cliente) fa.

In altre parole: frammentazione. Se si nomina un repo come "il" repo e si nominano i tutori che esaminano le richieste di pull, si ha un modo semplice per soddisfare la richiesta di "dammi un software build" o "Sono nuovo per il team, dov'è il codice?"

La forza di DVCS non è tanto l'aspetto peer-to-peer di esso, ma il fatto che sia gerarchico . Modifico il mio spazio di lavoro, quindi mi impegno a locale. Una volta completata la funzione, unisco i miei commit e li spingo al mio telecomando. Quindi chiunque può vedere il mio codice provvisorio, fornire feedback, ecc. Prima di creare una richiesta pull e un amministratore del progetto lo unisce nel repository One True.

Con CVCS tradizionale ti impegni o no. Questo va bene per alcuni flussi di lavoro (io uso entrambi i tipi di VCS per diversi progetti), ma cade piatto sul suo volto per un progetto pubblico o OSS. La chiave è DVCS ha più passaggi, che sono più lavoro, ma forniscono un modo migliore per integrare il codice da estranei attraverso un processo integrato che consente una migliore visibilità in ciò che viene archiviato. Usarlo in modo centralizzato significa che puoi ancora avere quel gold standard dello stato attuale del progetto e allo stesso tempo fornire un meccanismo di condivisione del codice migliore.

Non so come tu definisca "tutti", ma il mio team ha "un repository centrale su un server" e anche di volta in volta preleviamo dai repository di altri colleghi senza passare per quel repository centrale. Quando lo facciamo, passiamo comunque tramite un server, perché scegliamo di non inviare per email le patch relative al luogo, ma non tramite il repository centrale. Ciò accade generalmente quando un gruppo sta collaborando su una particolare funzione e desidera tenersi aggiornato l'un l'altro, ma non ha ancora alcun interesse a pubblicare la funzione su tutti. Naturalmente dal momento che non siamo silos segreti, queste situazioni non durano a lungo, ma DVCS offre la flessibilità necessaria per fare tutto ciò che è più conveniente. Possiamo pubblicare una funzione o meno secondo il gusto.

Ma il 90% + del tempo, certo, passiamo attraverso il repository centrale. Quando non mi interessa un particolare cambiamento o il lavoro di un particolare collega è più conveniente, e si adatta meglio, per tirare "i cambiamenti di tutti i miei colleghi che sono stati controllati nel repository centrale", piuttosto che tirare separatamente i cambiamenti da ciascuno di N colleghi. DVCS non sta tentando di impedire che "pull from main repo" sia il flusso di lavoro più comune, sta tentando di impedire che sia l'unico flusso di lavoro disponibile.

"Distribuito" significa che tutti i repository sono tecnicamente equivalenti per quanto riguarda il software git , ma non ne deriva che abbiano tutti uguale importanza per quanto riguarda gli sviluppatori e i nostri flussi di lavoro. Quando rilasciamo ai clienti o ai server di produzione, il repository usato per farlo ha un significato diverso da un repository utilizzato solo da uno sviluppatore sul proprio laptop.

Se "veramente decentrato" significa "non ci sono reposzi speciali", allora non penso che sia questo che Linus intende difendere, dato che in effetti fa mantiene repository speciali che sono più importanti nel grande schema delle cose, che è un clone casuale di Linux che ho realizzato ieri e ho intenzione di usare solo per sviluppare qualche piccola patch e poi cancellarla una volta che ha accettato la patch. git non privilegia il suo repo sul mio, ma Linus fa lo privilegia. Il suo "è lo stato attuale di Linux", il mio non lo è. Quindi, naturalmente, tende a passare attraverso Linus. La forza del DVCS rispetto al VCS centralizzato non è che non ci debba essere un centro di fatto, è che i cambiamenti non devono passare attraverso alcun centro perché (i conflitti permettono) chiunque può unire qualsiasi cosa.

I sistemi DVCS sono anche forzati , perché sono decentralizzati, per fornire alcune funzionalità utili basate sul fatto che devi necessariamente avere una cronologia completa (vale a dire un repository) localmente per fare qualsiasi cosa. Ma se ci pensate, non vi è alcun motivo fondamentale per cui non sia possibile configurare un VCS centralizzato con una cache locale che mantenga l'intera cronologia per operazioni di sola lettura che possono essere superate (penso che Perforce abbia un'opzione per questa modalità, ma non ho mai usato Perforce). In linea di principio, potresti configurare git con la tua directory .git/ su un filesystem montato su remoto per emulare la "funzione" di SVN che non funziona quando non hai una connessione di rete. In effetti, DVCS costringe l'impianto idraulico a essere più robusto di quanto si possa ottenere in un VCS centralizzato. Questo è un effetto collaterale (molto gradito) e ha contribuito a motivare il design DVCS, ma questa distribuzione di responsabilità a livello tecnico non è la stessa cosa che decentralizzare completamente tutte le responsabilità di human .

La cosa interessante della natura di DVCS è che se altre persone lo usano in modo distribuito, probabilmente non lo sapresti a meno che non stiano interagendo direttamente con te. L'unica cosa che puoi dire in modo definitivo è che tu e i tuoi diretti compagni di squadra non usano git in questo modo. Questo non richiede una politica aziendale. Quindi ti chiederò, perché non tu usi git in modo decentralizzato?

Per indirizzare la tua modifica, forse hai bisogno di una certa esperienza di lavoro con un controllo della versione centralizzato per apprezzare le differenze, perché sebbene possano sembrare sottili, sono pervasive. Queste sono tutte cose che la mia squadra fa sul lavoro che non potevamo fare quando avevamo VCS centralizzato:

• Avere un elenco molto ristretto di sviluppatori core con accesso diretto al repository "centrale" per ogni microservizio. Tutti gli altri possono lavorare fuori dalle forcelle e inviare tramite richieste di pull.
• Può impegnare molto più frequentemente, di solito più volte all'ora rispetto a una o due volte al giorno.
• Puoi creare succursali per qualsiasi motivo per coordinarti temporaneamente con i colleghi, e spingerti verso di essa e tirartene più volte al giorno, poi schiacciarlo quando sei pronto per condividere con un gruppo più grande. Hai idea di quanto sia difficile ottenere il permesso di creare un ramo temporaneo per qualcosa di simile in un CVCS tradizionale?

A rischio di sembrare vecchio per averlo detto, non sai davvero quanto sia facile.

Penso che la tua domanda derivi da una mentalità (comprensibile) sempre connessa . cioè. Il server centrale 'verità' ci è sempre (o quasi sempre) disponibile. Mentre questo è vero nella maggior parte degli ambienti, ho lavorato in almeno uno che era lontano da questo.

Un progetto di simulazione militare che il mio team ha lavorato diversi anni fa. Tutto il codice (stiamo parlando di un codice di > USb 1b codebase) dovuto a (per legge / accordo internazionale, gli uomini in abiti scuri vengono se non lo fai) essere su macchine fisicamente isolate dalla qualsiasi connessione Internet . Ciò significava la solita situazione in cui ognuno di noi aveva 2 PC, uno per scrivere / eseguire / testare il codice, l'altro per le cose di Google, controllare l'e-mail e così via. E c'era una rete locale all'interno del team di queste macchine, ovviamente non in alcun modo connessa a Internet.

La "fonte centrale della verità" era una macchina su una base militare, in una stanza senza finestre sotterranea (edificio blindato, yada-yada). Quella macchina anche non ha avuto una connessione Internet.

Periodicamente, sarebbe compito di qualcuno trasportare (fisicamente) un disco con il repository git (contenente tutte le nostre modifiche al codice) alla base dell'esercito - che si trovava a diverse centinaia di chilometri di distanza, quindi, puoi immaginare.

Inoltre, in molto sistemi di grandi dimensioni in cui hai lotti di team. Generalmente hanno ciascuno un proprio repository "centrale", che poi ritorna al repository centrale "centrale" effettivo (dio livello). Conosco almeno un altro appaltatore che ha eseguito lo stesso repo git del disco rigido con il loro codice.

Inoltre, se consideri qualcosa sulla scala del kernel Linux ... Gli sviluppatori non inviano semplicemente una richiesta di pull a Linus stesso. È essenzialmente una gerarchia di repo - ognuno dei quali era / è "centrale" per qualcuno / qualche squadra.

La natura disconnessa di git significa che può essere utilizzato in ambienti in cui connected strumenti di controllo del codice sorgente ( ie SVN, per uno) non possono essere utilizzati - o non può essere usato facilmente.

In definitiva, stai costruendo un prodotto. Questo prodotto rappresenta il tuo codice in un singolo punto nel tempo. Detto questo, il tuo codice deve coalizzarsi da qualche parte . Il punto naturale è un server ci o server centrale da cui è stato creato il prodotto, e ha senso che questo punto centrale sia un repository git.

L'aspetto distribuito di un DVCS si presenta sempre nello sviluppo open source, sotto forma di biforcazione. Ad esempio, alcuni dei progetti a cui ho contribuito sono stati abbandonati dall'autore originale e ora hanno una serie di fork in cui i manutentori a volte richiamano caratteristiche specifiche l'una dall'altra. Anche in generale, i progetti OSS accettano contributi esterni tramite richiesta di pull, piuttosto che concedere a persone a caso di accedere al repository di verità.

Questo non è un caso d'uso molto comune quando si costruisce un prodotto concreto con una specifica versione ufficiale, ma nel mondo F / OSS è la norma, non l'eccezione.

Why does everyone use git in a centralized manner?

Non ci siamo mai incontrati, come mai dici a tutti? ;)

In secondo luogo, ci sono altre funzionalità che trovi in Git ma non in CVS o SVN. Forse supponiamo solo che questa sia la funzione solo per tutti .

Certo, molte persone potrebbero usarlo centralizzato come CVS o SVN. Ma non dimenticare l'altra caratteristica intrinsecamente associata a un VCS distribuito: tutte le copie sono più o meno "complete" (tutti i rami e la cronologia completa è disponibile) e tutte le filiali possono essere controllate senza connettersi a un server.

Secondo me questa è un'altra caratteristica che non dovrebbe essere dimenticata.

Anche se non sei in grado di farlo con CVS e SVN fuori dalla scatola, Git può essere usato centralmente come i precedenti senza problemi.

Quindi sono in grado di commettere le mie modifiche, magari spacchettare le commesse di lavoro in corso, quindi recuperare e rebase il mio lavoro sul ramo di sviluppo principale.

Altre caratteristiche che escono dalla scatola con Git:

• firma il segno crittografico
• ribaditura (riordina e squash commits, edit commit, non solo il messaggio)
• cherry picking
• bisecatura della cronologia
• rami locali e modifiche di memorizzazione (chiamati "scaffalature" in Wikipedia)

Vedi anche queste tre tabelle in Wikipedia - Confronto del software di controllo della versione :

• Funzionalità

• Comandi di base

• Comandi avanzati

Quindi di nuovo, forse la modalità decentralizzata non è la quella sola caratteristica che fa sì che la gente la usi.

1. Why don't people use a distributed workflow for Git in practice?

Chiunque contribuisca o stia ospitando un progetto più grande su Bitbucked, GitHub, ecc. lo farà esattamente. I manutentori tengono il repository "principale", i cloni di un contributore, commettono e quindi inviano una richiesta di pull.

Nelle aziende, anche con piccoli progetti o team, un flusso di lavoro distribuito è un'opzione quando esternalizzano i moduli e non vogliono che gli esterni modificino il / i ramo / i di sviluppo sacro senza che le loro modifiche siano riviste prima.

2. Is the ability work in a distributed manner even important to modern version control, ...

Come sempre: dipende dai requisiti.

Utilizza un VCS decentralizzato se si applica un punto qualsiasi:

• vuoi impegnare o navigare nella cronologia offline (ad esempio finendo il sottomodulo nella cabina di montagna durante le vacanze)
• fornisce repository centralizzati ma desidera tenere separato il "vero" repository per rivedere le modifiche (ad esempio per grandi progetti o team distribuiti)
• desidera fornire (una copia di) l'intera storia e ramificazioni di tanto in tanto impedendo l'accesso diretto al repository centrale (simile al secondo)
• vuoi creare qualcosa senza doverlo archiviare in remoto o creare un repository dedicato (specialmente con Git un semplice git init . che sarebbe sufficiente per essere pronto per la versione qualcosa)

Ce ne sono altri ma solo quattro dovrebbero essere sufficienti.

... or does it just sound nice?

Certo che suona carino - per i principianti.

La flessibilità è una maledizione e una benedizione. E dato che Git è estremamente flessibile, è quasi sempre lontano troppo flessibile per la situazione tipica. Nello specifico, la maggior parte dei progetti Git non è Linux.

Di conseguenza, la scelta intelligente è quella di rimuovere parte della flessibilità teorica durante l'implementazione di Git. In teoria i repository possono formare qualsiasi grafico, in pratica la scelta abituale è un albero. Possiamo vedere gli evidenti benefici usando la teoria dei grafi: in un albero di repository, ogni due repository condivide esattamente un antenato. In un grafico casuale, l'idea di un antenato non esiste nemmeno!

Tuttavia, il tuo client git ha quasi certamente valore predefinito per il modello "single antenance". E i grafici in cui i nodi hanno un singolo antenato (eccetto per un nodo radice) sono esattamente alberi. Quindi il tuo client git stesso imposta di default il modello ad albero, e quindi i repository centralizzati.

La logica aziendale premia un server centralizzato. Per quasi tutti gli scenari di business realistici, un server centralizzato è una caratteristica fondamentale del flusso di lavoro.

Solo perché hai la capacità di fare DVCS non significa che il tuo flusso di lavoro principale debba essere DVCS. Quando uso git al lavoro, lo usiamo in maniera centralizzata, ad eccezione di quegli strani strani casi in cui il bit distribuito era essenziale per mantenere le cose in movimento.

Il lato distribuito delle cose è complicato. In genere si desidera mantenere le cose semplici e agevoli. Tuttavia, utilizzando git ti assicuri di avere accesso al lato distribuito per affrontare le situazioni nette che potrebbero sorgere lungo la strada.

Affinché un collega possa prelevare da un repository git sulla mia macchina, è necessario avere un demone git in esecuzione a livello di root come attività in background. Sono molto diffidente nei confronti dei demoni che girano sul mio computer o sul portatile della mia azienda. La soluzione più semplice è "NO"! Perché un collega possa prelevare da un repository git sulla mia macchina significa anche che il mio indirizzo internet deve essere corretto. Io viaggio, lavoro da casa e occasionalmente lavoro dal mio ufficio.

D'altra parte, la creazione di VPN sul sito aziendale e l'invio di un ramo al repository centrale richiedono meno di un minuto. Non ho nemmeno bisogno di VPN in se sono in ufficio. I miei colleghi possono facilmente tirare da quel ramo.

In terzo luogo, il mio repository git locale è un repository completo. Posso impegnarmi in un nuovo lavoro, creare una nuova branca per il lavoro sperimentale e ripristinare il lavoro quando faccio un casino di cose, anche quando lavoro in un aereo che vola a 30.000 piedi nel bel mezzo del nulla. Prova a farlo con un sistema di controllo della versione centralizzato.

Complessità:

Con un repository centrale, un flusso di lavoro tipico potrebbe essere

branch off from the central master branch
change the code
test
possibly go back to changing the code
commit
merge any new changes from the central master branch
test
possibly go back to changing the code
merge changes into the central master branch and push

La complessità rispetto al numero di sviluppatori in O (1).

Se invece ogni sviluppatore ha il proprio ramo principale diventa, per lo sviluppatore 0:

branch off from master branch 0
merge from master branch 1
...
merge from master branch N-1
change the code
test
possibly go back to changing the code
commit
merge any changes from master branch 0
merge any changes from master branch 1
...
merge any changes from master branch N-1
test
possibly go back to changing the code
merge changes into master branch 0

L'approccio peer-to-peer è O (N).

Consistenza:

Consideriamo ora se c'è un conflitto di fusione tra il ramo master di Alice e il ramo master di Bob. Ognuno degli sviluppatori N potrebbe risolvere il conflitto in modo diverso. Risultato: caos. Esistono modi per raggiungere un'eventuale coerenza, ma fino a quando ciò non accadrà, tutti i tipi di tempo di sviluppo potranno essere sprecati.

Semplice:

Le aziende sono organizzazioni centralizzate, con flusso di lavoro centralizzato.

Ogni programmatore ha un capo e ha il suo capo, ecc. fino al CTO. CTO è l'ultima fonte di verità tecnica. Qualunque strumento aziendale usi, deve riflettere questa catena di comando. Una compagnia è come un esercito: non puoi permettere ai privati di superare un generale.

GIT offre funzionalità che sono utili alle aziende (ad esempio, le richieste di pull per la revisione del codice) e che da sole le fanno passare a GIT. La parte decentralizzata è semplicemente una funzione di cui non hanno bisogno, quindi la ignorano.

Per rispondere alla tua domanda: La parte distribuita è effettivamente superiore in ambiente distribuito, ad esempio open-source. I risultati variano a seconda di chi sta parlando. Linus Torvalds non è esattamente il tuo ratto da cubicolo, per questo le diverse caratteristiche di GIT sono importanti per lui che per la tua azienda incentrata sul github.

Forse è perché l'elaborazione del libro paga è centralizzata, quindi dobbiamo mantenere una persona centrale felice se vogliamo essere pagati.

Forse è perché stiamo creando un prodotto, quindi abbiamo bisogno di una copia master del software per i clienti.

Forse è perché è molto più facile per un programmatore andare in un posto solo per ottenere le modifiche di tutti, piuttosto che dover connettersi a molte macchine diverse.

Forse è perché il database dei bug è centralizzato, e deve essere tenuto sincronizzato con il codice .

Essere centralizzati è fantastico, finché non c'è un problema ... ..

Git essendo un sistema distribuito consente di creare un nuovo centro a basso costo da qualsiasi repository aggiornato (basta esporre il repository alla rete). Git consente inoltre di aggiornare un backup non aggiornato dai repository sui computer degli sviluppatori, rendendo più semplice il ripristino del centro.

Essere in grado di unire etc su una copia locale di un repository quando la rete è inattiva è grande, ma non ha bisogno di un sistema distribuito; ha solo bisogno di un sistema che conserva una copia locale di tutti i dati. Allo stesso modo con il check-in del codice con volare ecc.

Alla fine della giornata c'è poco costo per essere distribuiti e alcuni benefici. La maggior parte del costo della distribuzione è in un'area che è necessaria se si desidera un monitoraggio ottimale dei rami ecc. Se si progettasse un sistema per l'utilizzo nella maggior parte delle aziende, non lo si progetterebbe per la distribuzione, come controllo centralizzato del codice sorgente è chiaramente il "caso d'uso" primario.