Perché Git è stato così eccitato? ... mentre altri no? [chiuso]

Credo che servizi come link o link è un grande fattore È importante per le persone che possano ospitare le loro cose da qualche parte e specialmente github è un ottimo servizio per questo.

Per mercurial, non esisteva un tale servizio quando i dvcs divennero popolari (almeno nessuno di cui ero a conoscenza). Hai link ora e probabilmente altri, ma Github è lì da un po 'di tempo, è noto e migliora sempre.

Vedo molte risposte a questo che si basano sui sentimenti che l'autore ha avuto quando ha sentito parlare dell'uno o dell'altro SCM. Altri dicono che tutto era pura fortuna. Credo che la fortuna possa essere fatta risalire alla storia.

Parlerò di storia.

Git e Mercurial sono stati creati simultaneamente per risolvere lo stesso problema. In quei giorni, il kernel di Linux è stato costretto a uscire da un periodo durante il quale aveva utilizzato BitKeeper , un SCM distribuito proprietario che li aveva serviti per molti anni.

In effetti, 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 l'ha decodificato.

Linus Torvalds, insoddisfatto di ciò che già esisteva, iniziò successivamente a lavorare su un nuovo 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 fa). Linus ha considerato di usarlo al posto di Git per lo sviluppo del kernel, ma ha abbandonato l'idea quando ha realizzato che Mercurial stava usando Modifiche per registrare 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 al posto di Mercurial, ma entrambi erano tecnicamente rilevanti. Il risultato finale è che Git è stato originariamente utilizzato dove era stato progettato per essere utilizzato, mentre Mercurial non era così veloce da trovare il suo primo grande utilizzo del FOSS. Perché è stato dotato di un ottimo design e, grazie alla perseveranza di Matt Mackall, è diventato famoso e utilizzato per i grandi progetti del mondo reale.

Oggi sono entrambi famosi. Qual è il più famoso è impossibile da dire. Google Code ha integrato Git solo recentemente, mentre Mercurial era da tanto tempo. Anche molti progetti molto grandi e famosi lo usano.

Credo che ciò che intendo sia, quando il vero motivo per cui hai avviato un progetto scompare, è più difficile ottenere popolarità, ma ancora fattibile.

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

D'altro canto, gli SCM distribuiti sono chiari vincitori. Lì fuori non vedo molti SCM largamente diffusi.

Linus Torvalds

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

Personalmente continuo a usare Subversion, ma questo deriva dalla preferenza piuttosto che dall'utilità.

Il solito punto di dolore con il sistema di controllo della versione è fusione di rami .

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

Imparando che Linus Torvalds ha scritto git per farlo bene, e che presumibilmente in una situazione ha usato git per fondere insieme rami dodici in una volta, questo è un argomento molto convincente per essere interessante .

Ero nella situazione di circa un anno fa, dove dovevo scegliere tra hg e git, e la fusione di cui sopra era un fattore importante nella scelta di git. Il secondo è che l'organizzazione Eclipse è passata a git, quindi ci si aspettava che gli strumenti Eclipse fossero validi per i progetti Java. Con il rilascio di Eclipse 3.7 questo è successo. Eravamo forse 6-9 mesi all'inizio di questo.

Per esigenze diverse potrebbe essere altrettanto utile. Sun lo ha scelto per il proprio VCS basato su un'indagine accurata molto . Potresti voler trovare i white paper e vedere quali erano i loro ragionamenti.

EDIT: Nota, non sto dicendo che c'è qualcosa che Mercurial non può 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 in piedi sulle spalle degli altri, non sui loro piedi.

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

Poiché evidenziato in precedenza , la community Git è molto rumorosa e arrogante. La maggior parte difenderà vigorosamente il loro prezioso programma. La maggior parte delle guerre tra Git e Mercurial che ho visto sono state avviate da persone git che si chiedevano perché tutti sulla Terra non usassero il santo idiota. Siti come whygitisbetterthanx.com mostrano anche questa arroganza nell'introduzione, che è scritta per fiamma esca altri.

Non sto dicendo che tutti sono in questo modo, ma il più delle volte in cui ho incontrato persone git, siti web pro-git e blog pro-git, mi sentivo come se un git venisse spinto in gola invece di essere offerto come un valido sistema DVCS.

Al contrario, altre comunità DVCS non sono così rumorose. Non sapevo che Mercurial esistesse finché non ho visto un "Qual è il miglior DVC?" domanda su SO. Mentre git appare ovunque, altri DVCS richiedono tempo per trovarlo.

Non credo che Mercurial abbia un profilo particolarmente basso. Il forno è costruito su Hg & c'è stato un buon supporto negli IDE come Eclipse & Netbeans per un po 'ora.

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

Manca anche "Bazaar" che è il vero "DVCS dimenticato".

Di certo sono d'accordo sul fatto che Linus sia un ragazzo molto carismatico e un alfa nerd quasi senza pari, quindi un sacco di gente potrebbe gravitare su Git per questo. Inoltre, il "mito della creazione" di Git è molto avvincente con Linus che lavora per 6 giorni per creare Git e riposare al settimo - o qualcosa del genere. Quando un prodotto ha una storia memorabile è più facile ottenere la trazione.

È un modesto parere, ma git potrebbe ottenere tutto questo hype a causa di due parametri:

1. È molto efficiente
2. È divertente da usare (in qualche tipo di computer science molto specifico)

Inoltre, ho ricevuto alcune app killer come github e alcuni progetti molto popolari hanno deciso di usarlo, il che ha dato molta visibilità.

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

Beta Geek Media

Ci sono diversi canali che parlano di "attività geek". Certamente copriranno l'aspetto di un nuovo sistema di controllo della versione, ma coprono di più git. Perché? Perché Linus Torvalds lo ha scritto inizialmente, ne ha discusso pubblicamente e l'ha usato come una soluzione al suo ben pubblicizzato problema con il bitkeeper. In effetti, ogni volta che si verifica una guerra di fuoco su lkml, i media beta-geek scriveranno un articolo a riguardo. La discussione su Git è iniziata su lkml, quindi ha ottenuto più copertura rispetto ad altre alternative. E i beta geek che leggono slashdot come Variety lo mangiano. Il risultato finale è che git ha dieci volte più articoli di mercurial.

L'ora è giusta

I grandi progetti open source con molti contributori 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 contributori, il problema peggiora. Linux è probabilmente il progetto più noto a soffrirne, ma ce ne sono molti altri. Con molti progetti che raggiungevano questo punto, era necessaria una specie di VCS avanzato. Git, Mercurial e Bazaar erano i grandi vincitori qui. Arch e Monotone erano solo un po 'troppo presto, e perse l'onda pubblicitaria.

Segui il leader

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

• Git : Linux, Perl, jQuery, Ruby on Rails, Eclipse, Gnome, KDE, QT, X
• Mercurial : 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.

Si tratta principalmente di hype auto-rinforzante. Git è il più popolare, quindi ottiene più pubblicità, il che lo rende sempre più popolare.

Git, Hg e Bzr sono tutti perfettamente buoni sistemi DVCS, ma un numero spaventoso di persone identifica DVCS con Git e pensa che tutte le caratteristiche di un DVCS siano uniche per Git. E quindi usano Git e raccomandano Git, e dicono cose come "Git è migliore perché può fare l'unione di polpi" (così può Bazaar), o "Git è meglio perché è distribuito" (così è qualsiasi DVCS, da cui il nome), o "Git è migliore perché rende facile la ramificazione e l'unione" (di nuovo, questo è vero per ogni DVCS).

Purtroppo, perché ritengo che 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 che DVCS == Git.

Quando qualcuno scopre quanto siano intelligenti i DVCS, essendo puntati su uno specifico DVCS, spesso non vanno a dire agli altri "hey, i DVCS sono fantastici, dovresti usarli", ma piuttosto "il I DVCS che I hanno imparato a conoscere da DVCS sono fantastici, dovresti usarli ".

Github. Github è un pioniere nella codifica sociale. Ha trasformato il controllo della versione in una piattaforma sociale che ha attirato molta attenzione e ovviamente supporta solo Git. Social media = maggiore adozione. Bitbucket sta guadagnando terreno grazie ad un sacco di nuove funzionalità, che lo rendono un probabile rivale:)

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

Ma i sostenitori del git sono solo più vocali, spesso più aggressivi nei loro commenti per essere onesti e piace parlarne ovunque.

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 vogliono solo un DSVC che riescano a cogliere velocemente, non qualcosa da basare religione su Quindi sono meno vocali e più reattivi nelle discussioni che proattivi come alcuni utenti git.

Bazaar non è parlato molto di sicuro perché solo pochi grandi progetti conosciuti lo usano e nessun'altra grande azienda di Canonical sa usarla. Confronta con Google (git, mercurial, svn) e grandi progetti open-source, per esempio, e puoi capire perché non è davvero parlato. Fossil è un altro interessante per una nicchia di sviluppatori, quindi credo sia normale e soddisfacente 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 prendendo il ciclo di hype e molti sviluppatori che hanno utilizzato diversi 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 per il 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 sentivo di poter aggiungere un po 'più di prospettiva.

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

1. Molte funzionalità che ha probabilmente dovrebbero far parte del core VCS, non lo è. Cose come la possibilità di eseguire una bisezione della cronologia, di eseguire un output lungo attraverso un cercapersone o di avere rami "colocati" (ad es. Repository in stile git) sono forniti come plugin.
2. Molti plug-in non sono così stabili. Ad esempio, la funzionalità dei rami separati non sembra funzionare bene sul lato server (almeno, non ho mai funzionato, tende ad errori dicendo che il ramo nel percorso specificato non esiste quando è proprio lì davanti a te e puoi vedere la cosa insanguinata)
3. Non ha l'operazione "clone", si tirano i rami 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 strong supporto per i ganci; puoi scrivere plugin bzr che forniscono hook, ma non esiste un modo standard per avere script hook arbitrari lato server.

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

1. git clone è un'operazione relativamente veloce e fornisce informazioni su tutti i rami esistenti nel repository che hai clonato.
2. L'aggiunta di repository remoti aggiuntivi è indolore e quindi puoi tenere traccia di molti repository diversi che hanno più filiali, se lo desideri.
3. Il libro Pro Git è disponibile online e in più formati, compresi i lettori di eBook e non è una lettura difficile.
4. git sembra molto più facile da estendere rispetto a Bazaar e non è necessario utilizzare alcuna particolare API per farlo. (NB: questo è al rialzo e al ribasso).
5. git ha un sistema integrato di bisezione e non posso sottolineare abbastanza l'utilità di quella funzione.
6. GitHub è piuttosto carino.
7. Anche il sistema gitosis è abbastanza carino. Non sono nemmeno sicuro di come si possa implementarlo a parte un plug-in in Bazaar e non riesco a immaginare che sarebbe altrettanto efficiente.

Per farla breve: ho usato bzr per un tempo molto lungo, ma git sta rapidamente dimostrando la sua bellezza per me.

Usando git, tendi a stare sempre nella stessa directory locale quando fai lo sviluppo, e fai semplicemente git checkout branchname per passare da un ramo all'altro (io uso sempre le branch caratteristiche "leggere", quindi questa è una caratteristica molto importante a me).

Guardando la documentazione e le esercitazioni Mercurial, sembra che il modo migliore 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 motivo la documentazione Mercurial (che ho letto) mostra quasi sempre diramazioni creando un clone di repository.

(Uso git ogni giorno. Ho poca esperienza con mercurial, ho giocato con esso e ho seguito alcuni tutorial)

Non so quanti rant che ho visto nelle ultime settimane, ma tutti sembrano considerarlo un dato di 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 shift di paradigma . E puntare ad una tabella di funzionalità mi dirà molto poco di quanto sia flessibile, estensibile, sicuro o senza sforzo . Ad esempio, di default git-diff utilizza colori e un cercapersone. Certo che posso ottenere lo stesso con diff ... | colordiff | less -R o qualcosa del genere, ma dovrebbe essere ovvio perché uno è superiore all'altro.

Per essere onesti, penso che i sostenitori del git vs. mercurial siano pochi e lontani tra i difensori contro i sostenitori centralizzati. Tuttavia, i motivi sono facili da riassumere:

Git is version control for programmers. Mercurial is version control for enterprises. Centralized was an adequate first try at inventing version control, especially considering it was designed before the personal computer revolution.

Ciò che intendo per controllo di versione per i programmatori è che i programmatori in generale favoriscono la flessibilità rispetto alla facilità di apprendimento. Dopotutto, siamo disposti a passare anni a imparare lingue esoteriche per avere la flessibilità di far fare al computer ciò che i non esperti non possono fare. Git offre ai programmatori la flessibilità di utilizzarlo comunque a loro piacimento, a scapito di impiegare più tempo per imparare come usare quella flessibilità in modo sicuro. Permette di mettere in atto restrizioni per far rispettare le politiche, ma non arriva così fuori dagli schemi. Nota ho detto facilità di apprendimento piuttosto che facilità di uso . Una volta appresa, git è facile da utilizzare come qualsiasi altro VCS, e spesso è più facile a causa dell'aumento della velocità e delle funzionalità.

Alcuni programmatori imparano abbastanza per fare ciò che vogliono, quindi resistono all'apprendimento di nuovi modi per farlo. Le aziende assumono e impiegano 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 svolgere il loro lavoro, ma non tanto da rendere difficile la formazione o la migrazione iniziale. È qui che entra in scena il mercurio. 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 a causa del clamore o del sostegno di Linus. Ciò probabilmente spiega che molte persone provano , ma se ne tengono e 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ù nitido e più conciso che si presta bene per i giochi di parole.

Recentemente stavo cercando un sistema di controllo delle versioni per progetti personali, quindi ho provato un po 'di loro. Sono praticamente analfabeta sulla riga di comando, e avevo sentito che nonostante le GUI fossero disponibili, Git era davvero destinato ad essere utilizzato attraverso la linea di comando, il che mi rendeva un po 'titubante. Onestamente però, è stato incredibilmente facile da raccogliere, e mi sto davvero divertendo. La documentazione è un fattore enorme nell'adozione di una nuova tecnologia e Git ha tonnellate di documentazione ridicolmente semplice che è chiara e disponibile. Le altre alternative come SVN e Bazaar erano fantastiche, semplicemente non lo rendevano abbastanza facile come Git. Github è anche un grande fattore, dal momento che è diventato così centrale per il movimento open source al momento. Avere una posizione (ironicamente) centralizzata per scambiare codice e progetti è un cambiamento di gioco in sé.

Solo il mio 2 ¢ - Ho scelto git oltre le alternative perché è scritto in Do piuttosto che in un linguaggio radtool o in un linguaggio di alto livello eccessivamente accademico. I vantaggi sono che è veloce ed efficiente e che posso effettivamente fare RTFS se trovo bug o comportamenti che non riesco a spiegare. Rende anche possibile utilizzare su piccoli ambienti di sviluppo self-hosted che non includono giganteschi interpreti / runtime, il che significa che posso prelevare direttamente da un repository git e compilare 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 a pochi anni fa. Ci sono state molte discussioni religiose accese lungo il percorso, naturalmente, ma questa pagina Wiki di GNOME riassume bene i pro e i contro come si applicavano a questo particolare comunità.

Per non parlare del fatto che Apple ora è stata coinvolta nella promozione della community obiettiva, se hai recentemente creato una nuova applicazione in Xcode 4, avresti notato che ti chiede automaticamente se desideri creare un Git pronti contro termine.

Garantito Xcode 4 è in circolazione solo da alcuni mesi e non influenza il precedente successo di Gits, ma sappiamo tutti quanto Apple sia in grado di fare le cose in un breve lasso di tempo.

Attualmente sto passando da hg (kiln) 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 in questo momento?

Al momento ci sono solo tre ragioni.

1. gitHub offre gli elenchi che sono grandi
2. gitHub offre grandi funzioni sociali
3. Durante le presentazioni e i workshop degli sviluppatori ho sempre pubblicato i miei campioni su hg e git. In git ho circa 10 volte più visitatori che in hg !!

Penso che il terzo sia il più importante.

Thorsten

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