Perché Git ha avuto così tanto clamore? ... mentre gli altri no? [chiuso]

Negli ultimi anni, l'hype attorno a Git è cresciuto notevolmente. Tutti conoscono Git, nessuno conosce alternative.

Altri come Mercurial sembrano passare inosservati. Entrambi sono stati rilasciati nel 2005 e offrono funzionalità simili. Inoltre, Mercurial è generalmente considerato più facile da usare, più intuitivo e ha da tempo migliori interfacce utente. Pertanto, si potrebbe presumere che questa sarebbe un'alternativa popolare, specialmente per i nuovi al controllo della versione distribuito. Tuttavia, sembra sconosciuto alla maggior parte delle persone, a differenza di Git che è riuscito abbastanza bene.

Il punto di questo post è cercare di capire meglio questo fenomeno.

Come mai Git ottiene tutto parte della torta? Hanno usato in qualche modo un marketing migliore? È perché la sua comunità è più ... ahem ... "verbosa"? È a causa del nome "Linus"? È a causa della sua immagine geek?

Qual'è la tua opinione?

Credo che servizi come GitHub o Gitorious siano un grande fattore. È importante per le persone che possano ospitare le loro cose da qualche parte e soprattutto GitHub è un ottimo servizio per questo.

Per i mercuriali, non esisteva tale servizio quando il DVCS divenne popolare (almeno nessuno di cui ero a conoscenza). Hai Bitbucket ora e probabilmente altri, ma GitHub è lì da un po 'di tempo, è ben noto e migliora sempre di più.

Vedo molte risposte a ciò che dipendono dai sentimenti che l'autore ha avuto quando ha sentito parlare dell'uno o dell'altro SCM. Altri dicono che è stata una pura fortuna. Credo che la fortuna possa essere ricondotta alla storia.

Parlerò di storia.

Git e Mercurial sono stati creati contemporaneamente per risolvere lo stesso problema. A quei tempi, il kernel Linux era costretto a smettere di usare BitKeeper , un SCM distribuito proprietario che utilizzava da 3 anni. La ragione di ciò era che Larry McVoy, CEO di BitMover, la società dietro BitKeeper, ha smesso di distribuire il suo software gratuitamente agli sviluppatori Linux, perché qualcuno all'interno della comunità Linux lo aveva decodificato.

Linus Torvalds, insoddisfatto di ciò che già esisteva, successivamente iniziò a lavorare su un nuovissimo SCM che avrebbe presto chiamato Git. Subito dopo, Matt Mackall ha avviato il progetto Mercurial per ragioni simili.

Dopo un po 'di tempo a sviluppare questi progetti separatamente, Matt Mackall ha presentato una versione avanzata del suo SCM e lo ha confrontato in un certo modo, confrontandolo con Git (che era di per sé solo un paio di settimane). Linus pensò di usarlo al posto di Git per lo sviluppo del kernel, ma lasciò cadere l'idea quando si rese conto che Mercurial stava usando i changeset per registrare le modifiche di revisione . Temeva che fosse troppo vicino al modo in cui BitKeeper funzionava, e certamente non voleva nulla che potesse far dire a qualcuno: "Hanno costruito un clone di BitKeeper".

Git è stato quindi utilizzato per lo sviluppo del kernel anziché per Mercurial, ma entrambi erano tecnicamente rilevanti. Il risultato finale è che Git ha iniziato ad essere effettivamente utilizzato dove era stato progettato per essere utilizzato, mentre Mercurial non è stato così veloce nel trovare il suo primo grande utilizzo FOSS. Perché era dotato di un ottimo design e grazie alla perseveranza di Matt Mackall, alla fine divenne famoso e si abituò a grandi progetti del mondo reale.

Oggi sono entrambi famosi. Qual è il più famoso è impossibile da dire. Google Code ha integrato Git solo di recente, mentre Mercurial aveva da molto tempo. Molti progetti molto grandi e famosi usano entrambi.

Immagino che intendo, quando il vero motivo per cui hai avviato un progetto svanisce, è più difficile guadagnare popolarità, ma è ancora fattibile.

Bazaar è un altro SCM molto famoso nel mondo GNU, ma non molto al di fuori di quello, perché è stato costruito con l'intento di soddisfare la comunità GNU. Il software spesso va dove vogliono i loro creatori e non oltre.

D'altra parte, gli SCM distribuiti sono chiari vincitori. Non vedo molti SCM non distribuiti ampiamente usati là fuori.

Linus Torvalds

Linus è un grande sostenitore di Git e lo ha promosso pesantemente nel gruppo principale di Linux per anni ed è cresciuto da lì. Oserei dire che è interamente dovuto all'influenza di Linus sulla comunità * nix.

Personalmente uso ancora Subversion, ma è per preferenza piuttosto che per utilità.

Il solito punto debole con il sistema di controllo della versione è la fusione dei rami .

Devi averlo provato quando non funziona per capire quanto possa essere doloroso e quanto sia importante lavorare per lavorare liberamente con i rami.

Apprendendo che Linus Torvalds ha scritto git per fare questo in modo corretto, e che presumibilmente in una situazione ha usato git per unire dodici rami contemporaneamente, questo è un argomento molto convincente per fare in modo che git sia interessante.

Ero nella situazione circa un anno fa, dove ho dovuto scegliere tra hg e git, e la fusione sopra è stata un fattore importante nella scelta di git. Il secondo è stato che l'organizzazione Eclipse è passata a git, quindi gli strumenti Eclipse avrebbero funzionato bene per i progetti Java. Con il rilascio di Eclipse 3.7 questo è successo. Eravamo in anticipo di 6-9 mesi.

Per esigenze diverse, hg potrebbe essere altrettanto utile. Sun l'ha scelto per il loro VCS sulla base di un'indagine molto attenta. Potresti voler trovare i white paper e vedere quali erano i loro ragionamenti.

EDIT: Nota, non sto dicendo che non c'è nulla che Mercurial non possa fare, solo quello per Java con Eclipse - che è il nostro obiettivo principale - le forze di mercato sono attualmente più forti per git, anche sotto Windows, e dobbiamo stare sulle spalle di altri, non i loro piedi.

Invece di dire perché git o mercurial è meglio e dire che è l'unica ragione per cui è popolare, mi concentrerò sulla comunità.

Come ho sottolineato in precedenza , la comunità Git è molto rumorosa e arrogante. Molti difenderanno con forza il loro prezioso programma. La maggior parte delle guerre Git vs Mercurial che ho visto sono state iniziate da persone git che si chiedevano perché tutti sulla Terra non stessero usando il santo git. Siti come whygitisbetterthanx.com mostrano anche questa arroganza nell'introduzione, che è scritta per attirare gli altri.

Non sto dicendo che tutti sono così, ma la maggior parte delle volte quando ho incontrato persone git, siti web pro-git e blog pro-git mi è sembrato che Git mi venisse spinto in gola invece che offerto come un DVCS praticabile sistema.

Al contrario, altre comunità DVCS non sono così rumorose. Non sapevo che Mercurial esistesse fino a quando non ho visto un "Qual è il miglior DVCS?" domanda su SO. Mentre git appare ovunque, altri DVCS impiegano del tempo per trovare.

Non credo che Mercurial abbia un profilo particolarmente basso. Kiln è basato su Hg e da un po 'di tempo c'è un buon supporto negli IDE come Eclipse e Netbeans.

La maggior parte degli sviluppatori con cui parlo sembra preferire Hg a causa del miglior supporto di Windows. Se fossimo sviluppatori Linux, potrebbe essere una storia diversa.

Ti manca anche "Bazaar" che è il vero "DVCS dimenticato".

Certamente sono d'accordo sul fatto che Linus sia un ragazzo molto carismatico e un secchione alfa quasi senza eguali, quindi molte persone graviterebbero su Git per questo. Inoltre, il "mito della creazione" di Git è molto convincente con Linus che lavora per 6 giorni per creare Git e riposare sul settimo - o qualcosa del genere. Quando un prodotto ha una storia memorabile, è più facile ottenere trazione.

È un'opinione modesta, ma git potrebbe ottenere tutto questo clamore a causa di due parametri:

1. È molto efficiente
2. È divertente da usare (in una sorta di modo informatico molto specifico)

Inoltre, git ha ottenuto un'app killer come github e alcuni progetti molto popolari hanno deciso di usarla, il che le ha dato molta visibilità.

Ci sono tre fattori al lavoro qui, "beta geek media", "il momento è giusto" e "segui il leader"

Beta Geek Media

Esistono numerosi canali che discutono di "attività geek". Avrebbero certamente coperto l'aspetto di un nuovo sistema di controllo della versione, ma copriranno di più git. Perché? Perché Linus Torvalds lo scrisse inizialmente, ne discusse pubblicamente e lo usò come soluzione al suo problema ben pubblicizzato con Bitkeeper. In effetti, ogni volta che c'è una guerra alla fiamma su lkml, i media beta geek scriveranno un articolo al riguardo. La discussione Git è iniziata su lkml, quindi ha ottenuto una copertura maggiore rispetto ad altre alternative. E i fanatici della beta che leggono slashdot come se fosse Variety lo mangiarono. Il risultato finale è che git ha dieci volte più articoli di mercurial.

Il momento è giusto

I grandi progetti open source con molti collaboratori hanno problemi con il controllo centralizzato del codice sorgente. Man mano che l'open source cresce e i progetti hanno maggiori probabilità di avere molti collaboratori, il problema peggiora. Linux è probabilmente il progetto più noto che soffre di questo, ma ce ne sono molti altri. Con molti progetti che raggiungono questo punto, era necessario un qualche tipo di VCS avanzato. Git, Mercurial e Bazaar sono stati i grandi vincitori qui. Arch e Monotone erano solo un po 'troppo presto e perse l'ondata di hype.

Segui il leader

I grandi progetti hanno follower che controllano e costruiscono il codice regolarmente, anche se non contribuiscono. I follower acquisiscono familiarità con gli strumenti necessari per recuperare il progetto che seguono, in modo che tali strumenti ne traggano maggiore utilità. Diamo un'occhiata ai progetti "big draw" per i tre grandi DVCS:

• Git : Linux, Perl, jQuery, Ruby on Rails, Eclipse, Gnome, KDE, QT, X
• Mercuriale : Java, Mozilla, Python
• Bazar : Ubuntu, Emacs

Git ha più progetti "big draw" che lo utilizzano, quindi più persone hanno familiarità con Git, ci sono più tutorial git scritti.

È principalmente solo un hype auto-rinforzante. Git è il più popolare, quindi ottiene più pubblicità, il che lo rende più popolare.

Git, Hg e Bzr sono tutti ottimi sistemi DVCS, ma un numero spaventoso di persone identifica DVCS con Git e pensa che tutte le adorabili funzionalità di un DVCS siano uniche di Git. E così usano Git, raccomandano Git e dicono cose come "Git è meglio perché può fare le fusioni di polpo" (Così può Bazaar), o "Git è meglio perché è distribuito" (così è qualsiasi DVCS, da cui il nome ) o "Git è meglio perché semplifica la ramificazione e l'unione" (di nuovo, questo vale per ogni DVCS).

Purtroppo, perché ritengo che anche le alternative abbiano molto da offrire e preferirei che le persone scegliessero Git per i suoi punti di forza unici, piuttosto che semplicemente perché pensano DVCS == Git.

Quando qualcuno scopre quanto siano intelligenti i DVCS, indicando uno specifico DVCS, spesso non vanno e dicono agli altri "ehi, i DVCS sono fantastici, dovresti usarli", ma piuttosto "il DVCS che io imparato da DVCS è fantastico, dovresti usarlo ".

Github. Github è un pioniere nella programmazione sociale. Ha trasformato il controllo delle versioni in una piattaforma social che ha attirato molta attenzione e ovviamente supporta solo Git. Social media = maggiore adozione. Bitbucket sta guadagnando slancio anche se sta ottenendo molte nuove funzionalità, rendendolo un probabile rivale :)

Beh, in effetti penso che l'hype riguardi tutti i DSVC insieme.

Ma i sostenitori di Git sono solo più vocali, spesso più aggressivi nei loro commenti per essere onesti e amano parlarne ovunque.

Ho il sospetto che Mercurial sia ampiamente usato, certamente tanto quanto git, forse di più (Microsoft e altre grandi aziende lo usano ora), ma le persone che usano Mercurial il più delle volte volevano solo un DSVC che possono afferrare rapidamente, non qualcosa su cui basare una religione. Quindi sono meno vocali e più reattivi nelle discussioni che proattivi come alcuni utenti git.

Bazaar non è molto discusso di certo perché solo pochi grandi progetti noti lo usano e nessun'altra grande azienda oltre a Canonical è nota per usarlo. Confronta ad esempio Google (git, mercurial, svn) e grandi progetti open-source e puoi vedere perché non ne parla davvero. Fossil è un altro che è interessante per una nicchia di sviluppatori, quindi immagino che sia normale e corretto per loro essere ascoltati solo da coloro che cercano le funzionalità che forniscono (come wiki incorporato, tracciamento dei problemi e forum).

Detto questo, penso che stiamo lentamente calando il ciclo dell'hype e molti sviluppatori che hanno utilizzato diverse soluzioni possono iniziare a vedere quale si adatta alle loro esigenze.

Inoltre, Google Code Hosting e SourceForge ora consentono sia git che mercurial, quindi sta diventando più una scelta specifica del progetto rispetto a prima quando hai scelto git a causa delle funzionalità di GitHub.

Non esiste una vera guerra, solo un'interessante varietà di strumenti.

So che ci sono già molte risposte a questa domanda, ma ho sentito di poter aggiungere un po 'più di prospettiva.

Ho usato Bazaar praticamente da quando è stato creato per varie cose. La cosa più grande per cui l'ho usato è stato il progetto AllTray, per il quale sono (attualmente) l'unico sviluppatore e manutentore. Il bazar è carino. Funziona, resta fuori dai piedi e quasi mai devo guardare una pagina --help o la pagina man per questo. Detto questo, ci sono alcuni aspetti negativi:

1. Molte funzionalità che possibilmente dovrebbero essere parte del core VCS non lo sono. Cose come la capacità di eseguire una sezione di storia, di eseguire lunghi output attraverso un cercapersone o di avere rami "colocati" (ad esempio, repository in stile git) vengono forniti come plug-in.
2. Molti plugin non sono poi così stabili. Ad esempio, la funzionalità dei rami associati non sembra funzionare bene sul lato server (almeno, non l'ho mai fatto funzionare, tende a sbagliare dicendo che il ramo in un determinato percorso non esiste quando è proprio lì di fronte a te e puoi vedere la cosa insanguinata).
3. Non ha operazioni di "clonazione", i rami si tirano uno alla volta. Devi fare un lavoro extra se vuoi avere un repository in modo da poter estrarre in modo efficiente nuovi rami.
4. Per alcuni progetti, è dolorosamente lento. Prova "bzr branch lp: mysql" qualche volta.
5. Manca un forte supporto per i ganci; puoi scrivere plugin bzr che forniscono hook, ma non esiste un modo standard per avere script hook arbitrari sul lato server.

Di recente sono passato a git per lo sviluppo di AllTray e sto prendendo molto rapidamente in considerazione l'idea di migrare tutti i miei progetti su git. C'è un po 'più di tempo in anticipo speso per conoscere le corde, ma sembra valerne la pena. Alcune cose che ho notato:

1. git clone è un'operazione relativamente veloce e ti fornisce informazioni su tutti i rami esistenti nel repository che hai clonato.
2. L'aggiunta di ulteriori repository remoti è indolore, quindi è possibile tenere traccia di molti repository diversi che hanno più rami se lo si desidera.
3. Il libro Pro Git è disponibile online e in più formati, incluso per i dispositivi di lettura di eBook, e non è una lettura difficile.
4. git sembra molto più facile da estendere di Bazaar e non è necessario utilizzare alcuna API particolare per farlo. (NB: questo è sia un lato positivo che uno negativo).
5. git ha la bisection integrata e non posso sottolineare abbastanza l'utilità di quella funzione.
6. GitHub è piuttosto carino.
7. Anche il gitosissistema è abbastanza carino. Non sono nemmeno sicuro di come implementarlo se non come un plugin in Bazaar, e non riesco a immaginare che sarebbe altrettanto efficiente.

Per farla breve: ho usato bzr per molto tempo, ma Git mi sta rapidamente dimostrando la sua bellezza.

Usando git, tendi a rimanere sempre nella stessa directory locale quando fai lo sviluppo, e semplicemente git checkout branchnameper passare da un ramo all'altro (io uso sempre rami "leggeri", quindi questa è una caratteristica molto importante per me).

Guardando la documentazione e le esercitazioni di Mercurial, sembra che il modo preferito per gestire i diversi rami dello sviluppo sia creare nuovi repository mediante la clonazione. Questo tutorial è un esempio.

Credo che tu possa fare la stessa cosa in Mercurial come in git, ma per qualche ragione la documentazione di Mercurial (che ho letto) mostra quasi sempre ramificazioni creando un clone del repository.

(Uso git quotidianamente. Ho poca esperienza con mercurial, ci ho giocato e seguito alcuni tutorial)

Non so quanti di questi rant ho visto nelle ultime settimane, ma tutti sembrano considerarlo come un fatto che Mercurial e / o Bazaar sono oggettivamente migliori di Git. L'usabilità sembra essere un tema comune. Sì, imparare Git è stato sorprendentemente difficile dopo aver usato CVS e Subversion, ma a questo punto non vorrei scambiarlo con nessun altro VCS a meno che non costituisse un altro cambio di paradigma . E indicare una tabella di funzioni non mi dirà molto su quanto sia flessibile, estensibile, sicuro o senza sforzo . Ad esempio, per impostazione predefinita git-diff utilizza i colori e un cercapersone. Certo che posso ottenere lo stesso con diff ... | colordiff | less -Ro qualcosa del genere, ma dovrebbe essere ovvio il motivo per cui uno è superiore all'altro.

Ad essere onesti, penso che i sostenitori git vs. mercurial siano pochi e lontani tra loro rispetto ai sostenitori git vs. centralizzati. Tuttavia, i motivi sono facili da riassumere:

Git è il controllo della versione per programmatori. Mercurial è il controllo della versione per le imprese. La centralizzazione fu un primo tentativo adeguato di inventare il controllo delle versioni, soprattutto considerando che era stato progettato prima della rivoluzione del personal computer.

Quello che intendo per controllo di versione per programmatori è che i programmatori in generale favoriscono la flessibilità rispetto alla facilità di apprendimento. Dopotutto, siamo disposti a dedicare anni all'apprendimento delle lingue esoteriche per avere la flessibilità di far fare ai computer ciò che i non addestrati non possono fare. Git offre ai programmatori la flessibilità di usarlo come preferiscono, a spese di esso impiegando più tempo per imparare a usare quella flessibilità in sicurezza. Permette di mettere in atto restrizioni per far rispettare le politiche, ma non esce così fuori dalla scatola. Nota ho detto facilità di apprendimento piuttosto che facilità d' uso . Una volta appreso, git è facile da usare come qualsiasi altro VCS e spesso più facile a causa della maggiore velocità e funzionalità.

Alcuni programmatori imparano abbastanza per fare ciò che vogliono, quindi resistono all'apprendimento di nuovi modi per farlo. Le aziende assumono e assumono molte di queste persone, quindi desiderano che qualsiasi cambiamento negli strumenti che usano abbia un certo grado di familiarità. Le aziende vogliono anche che i loro programmatori abbiano abbastanza flessibilità per fare il loro lavoro, ma non tanto da rendere difficile la formazione o la migrazione iniziale. È qui che si inserisce Mercurial. Ha la maggior parte del potere di Git, ma un percorso di migrazione un po 'più semplice.

Non penso sia giusto dire che git è popolare solo per l'hype o l'approvazione di Linus. Ciò probabilmente spiega molte persone che lo provano , ma si attaccano e lo promuovono perché funziona bene per loro, puro e semplice.

Lo sviluppo di NetBSD utilizza CVS e questo è tutto ciò che è importante.

Ha un nome più scattante e pithy che si presta bene ai giochi di parole.

Recentemente stavo cercando un sistema di controllo della versione per progetti personali, quindi ho appena provato un sacco di loro. Sono praticamente analfabeta sulla riga di comando e avevo sentito che sebbene le GUI fossero disponibili, Git era davvero destinato a essere utilizzato attraverso la riga di comando, il che mi ha reso un po 'titubante. Onestamente, è stato ridicolmente facile da prendere, e mi sto davvero divertendo. La documentazione è un fattore determinante per l'adozione di una nuova tecnologia e Git ha tonnellate di documentazione ridicolmente semplice, chiara e disponibile. Le altre alternative come SVN e Bazaar erano fantastiche, ma non lo rendevano abbastanza facile come Git. Anche Github è un grande fattore, poiché al momento è diventato così centrale nel movimento open source. Avere una posizione (ironicamente) centralizzata per scambiare codice e progetti è un punto di svolta in sé.

Solo il mio 2 ¢ - Ho scelto git rispetto alle alternative perché è scritto in C piuttosto che in una lingua radtool o in un linguaggio di alto livello eccessivamente accademico. I vantaggi sono che è veloce ed efficiente e che posso effettivamente RTFS se incontro bug o comportamenti che non posso spiegare. Inoltre, è possibile utilizzare su piccoli ambienti di sviluppo self-hosted che non includono interpreti / runtime giganteschi, il che significa che posso estrarre direttamente da un repository git e compilare su tali sistemi piuttosto che dover recuperare l'ultima fonte altrove e rsync.

Potresti essere interessato a leggere perché il progetto desktop GNOME ha scelto git su hg e bzr, quando ha deciso di passare da svn qualche anno fa. Ci sono state molte discussioni religiose accese lungo la strada, ma questa pagina Wiki di GNOME riassume bene i pro ei contro mentre si applicavano a quella particolare comunità.

Per non parlare del fatto che Apple ora si è impegnata a spingerlo nella comunità dell'obiettivo c, se di recente hai creato una nuova applicazione in Xcode 4, avrai notato che ti chiede automaticamente se desideri effettuare un repository Git.

Concesso Xcode 4 è in circolazione da pochi mesi e non influisce sul successo precedente di Gits, ma sappiamo tutti quanto Apple possa fare cose in poco tempo.

Attualmente sto passando da hg (forno) a git (github). Ho usato il forno per circa un anno in questo momento. Per me hg non ha svantaggi. Posso fare tutto ciò che devo. Quindi è fantastico.

Perché sto usando adesso?

Ci sono solo tre ragioni in questo momento.

1. gitHub offre contenuti fantastici
2. gitHub offre grandi funzionalità social
3. Durante le presentazioni e i seminari degli sviluppatori ho sempre pubblicato i miei campioni su hg e git. Su git ho circa 10 volte più visitatori che su hg !!

Penso che il terzo sia il più importante.

Thorsten

Pura fortuna immagino, fino ad ora quasi impossibile dimostrare perché qualcosa ha funzionato e altri no. Linus può costruire qualcos'altro di spettacolare e non avere successo.