GitHub si è affermato come l’hosting di progetti open source più apprezzato, superando sia SourceForge, sia Google Code. È il risultato di due studi: il primo di Black Software e il secondo di RedMonk. Le statistiche si riferiscono al periodo tra gennaio e maggio di quest’anno, sulla base dei commit ricevuti dalle varie piattaforme.
Secondo la ricerca di Black Duck, GitHub ha ricevuto il 54% dei commit (oltre un milione), SourceForge il 30% (600.000 circa) e Google Code il 14% (attorno ai 280.000). CodePlex di Microsoft è sotto i 50.000 commit col 2% del totale. GitHub supera quindi il doppio dell’attività di tutti gli altri hosting messi insieme, per il 2011.
Il linguaggio più utilizzato su GitHub è Ruby, nonostante C++ guidi la classifica generale davanti a Java e Python. C Sharp è ovviamente il più sfruttato su CodePlex, tuttavia la percentuale dei commit su GitHub è di poco inferiore a quella del portale di Microsoft. Stephen O’Grady di RedMonk sottolinea come Perl sia il meno usato.
Via | ReadWriteWeb
Seguici
ossblog è un supplemento alla testata Blogo.it registrata presso il Tribunale di Milano n. 487/06, P. IVA 04699900967. Contatti, Chi siamo, Condizioni di utilizzo, Privacy.
© 2004-2012 Blogo.it, alcuni diritti riservati sotto licenza Creative Commons.
Per informazioni pubblicitarie e progetti speciali su Ossblog.it contattare la concessionaria esclusiva Populis Engage.
bouch
03 giu 2011 - 13:18 - #1Sbagliato: il numero di commit è maggiore, ma la quantità di codice totale ospitato è ancora parecchio inferiore a quella di sourceforge (non so rispetto a google code).
amaretti fedroco
03 giu 2011 - 13:22 - #2Si ma quanti di questi commit sono effettuati a causa di fork, ricordiamo bene anche il funzionamento diverso delle piattaforme.
GitHub pone proprio l’enfasi sul modello di sviluppo a fork
sherpya
03 giu 2011 - 18:03 - #3beh google code non ha git (ma perche’?)
e sourceforge e’ abbastanza ostico da usare
per fare un repo su github ci metti tre secondi
Kim Allamandola
03 giu 2011 - 20:40 - #4Sperando di evitare flame stile miei commenti precedenti:
* sf offre uno spazio per un sito-vetrina ed accesso ssh
* google code offre mercurial
* github offre git
* launchpad offre bazaar e un bugzilla web integrato con bazaar
* BerliOS, Savannah ecc non hanno peculiarità tecniche appetitose…
Il resto sono caratteristiche comuni a tutti o IMVHO non rilevanti…
Il successo di mercurial, bazaar e git è il successo dei dCVS rispetto alle
soluzioni client-server legacy. Git è molto diffuso perché ha un grande
sponsor: Linus Torvalds ma è il più scomodo dei dCVS sulla piazza; mercurial
era molto amato nei lidi Sun che purtroppo non esistono quasi più oggi; bazaar
è il più comodo offrendo la possibilità d’uso distribuito e client-server alla
SVN anche mescolate sullo stesso tree, e l’integrazione con launchpad,
accidentalmente è poco sponsorizzato e quindi lo conoscono in pochi. Da
monothone in giù sono soluzioni poco diffuse.
Quando qualcuno offrirà il launchpad, magari non Ubuntu-centrico, con la
possibilità di avere un decente sito-vetrina quello supererà tutti gli altri…
GitHub è diffuso perché tanti passano da SVN (o add. CVS e sw proprietario)
a git non conoscendo altri dCVS…
@sherpya #3
git è “un mostro” sia sul piano del setup che sul piano dell’uso e i repo git
hanno un discreto bisogno di essere ri-pack-ati di tanto in spesso per restare
efficienti in termini d’uso dello storage… Le uniche caratteristiche che ha
git in più rispetto e mercurial o bazaar interessano, se interessano qualcuno,
solo progetti enormi…
ekerazha
04 giu 2011 - 09:44 - #5Per piccoli progetti con pochissimi sviluppatori, git e Mercurial sono inutilmente complessi… Google Code offre sia Subversion sia Mercurial.
Kim Allamandola
04 giu 2011 - 10:10 - #6@ekerazha #5
Concordo per git ma non per mercurial e bazaar:
* non c’è nessun server da setup-are
* uso pressoché uguale a subversion
* merge e branching molto più facili
scusa ma per un progetto piccolo quanto vuoi dov’è la complessità, git a parte
dei dCVS?
I passi per iniziare da source esistenti sono:
hg init
Kim Allamandola
04 giu 2011 - 10:12 - #7Pare che ossblog abbia problemi col post…
I passi per iniziare da source esistenti sono:
hg init # crea .hd nella root del progetto (la dir corrente)
hg add . # aggiunge tutto ciò che c’è al controllo versione
hg commit -m “Primo import” # primo commit, ora si può lavorare
hgserve ti permette di condividere al volo, senza setup, il tuo repo in una
LAN, hg push e pull permettono la condivisione dei commit. Il 90% dei comandi
sono gli stessi di svn. Con bazaar:
bzr init
bzr add .
bzr commit -m “Primo import”
per fare un branch
cd tuo_progetto && bzr branch ../nuovo_branch
setuppando il tuo account lanchpad puoi anche inviare direttamente a lanchpad
le tue source, come faresti con qualsiasi altro repo o collaboratore singolo:
bzr push lp:/tuo/progetto
hai anche bzr viz per una view grafica della tua history, bzr-gtk bzr-explorer
ecc se vuoi le GUI. Mercurial ha TortoiseHg ecc. Sono integrati sia con
NetBeans che con Eclipse ecc ecc ecc
Hai tutte le comodità di un dCVS *distribuito* non hai la necessità di un
server, puoi mantenere un repo centrale come con svn ma puoi committare per
i fatti tuoi offline e solo dopo push-are le tue modifiche sul repo comune,
se già conosci svn puoi iniziare leggendo un quickstart di 5 pagine
http://bazaar.canonical.com/en/
http://mercurial.selenic.com/wiki/QuickStart
ekerazha
04 giu 2011 - 11:47 - #8bazaar non l’ho menzionato e non l’ho mai usato, per piccoli progetti con pochi sviluppatori, un DCVS con repository locali da sincronizzare ecc. è inutilmente complesso, con SVN hai i file, li modifichi, commit, fine… banale, immediato, ne più ne meno di ciò che serve. Io avevo alcuni progetti su Mercurial e li ho recentemente convertiti a Subversion.
Mariastella Gelmini
05 giu 2011 - 09:19 - #9@Kim Allamandola
setuppando?
E poi vi lamentate se vi chiudo le sQuole
dino da perugia
05 giu 2011 - 09:48 - #10Se posso permettermi, visto che la discussione è virata dal fatto che molto piu codice subisca commit sotto github che sotto altri sistemi.
Il punto cenrale è dovuto ad alcuni fattori novità notorietà semplicità. Tutavia ci sono delle limitazioni per progetti professionali di cui tener conto.
Per quanto riguarda la semplicità d’uso econdo me mercurial è primo poi viene bazaar git svn.
Mercurial vince perchè lo install , imposti lo username, e poi puoi inizializzzare qualsiasi cartella. Bisogna evitare il più possibile di porre file binari el repo.
Infine il vantagio di usare un sistema ad esempio Mercurial anche in un piccolo progetto e monosviluppatore è di poter tenere traccia delle modifiche del perchè esse sono state effettuate e dell’evoluzione del progetto
Kim Allamandola
05 giu 2011 - 21:42 - #11@ekerazha #8
Hai convertito dei progetti da mercurial a subversion? Una domanda senza
polemica: hai mai usato, oltre alla prova da 2″, mercurial o bazaar? No
perché dire che “sono inutilmente complessi” vuol dire non sapere cosa si
stà dicendo… Hai *gli stessi* comandi di svn ed in più non hai bisogno
di un server centrale, sempre disponibile per poter commit-are…
@Mariastella Gelmini #9
Ha anche ragione, per quanto la Sua carriera scolastica faccia venir voglia
di citare il famoso: “da qual pulpito…” ugualmente, si, un po’ di neologismi
e/o anglicismi sono oramai divenuti d’uso comune e l’Accademia della Crusca
prima o poi dovrà riconoscerlo :D. Se non altro la parlata informatica fa un
uso di anglicismi decisamente più accettabile di certi markettari e
sedicenti economisti… :D :D
@dino da perugia #10
posso chiederti perché mercurial lo indichi come più semplice di bazaar? Per
la facilità di creare repo non posso essere daccordo: i comandi sono gli stessi
posto che $mioProgetto abbia già un contenuto e sia da mettere sotto controllo
versione con mercurial dai:
cd $mioProgetto
hg init
hg add .
hg commit
con bazaar:
bzr init
bzr add .
bzr commit
con git:
git init
git add .
git commit
con subversion (repo sulla macchina locale, il setup più semplice)
svnadmin create NuovoRepo
svn import $mioProgetto file:///path/verso/NuovoRepo
rm -fr $mioProgetto
svc co file:///path/verso/NuovoRepo $mioProgetto
cd $mioProgetto
bazaar ti permette di scegliere sia una gestione totalmente distribuita che
una legacy alla svn, che una ibrida; mercurial è solo distribuito; git ha un
po’ di caratteristiche avanzate utili (?) per progetti mastodontici e la noia
di dover repack-rare il tree con regolarità…
ekerazha
06 giu 2011 - 08:04 - #12Inizio a dubitare delle tue capacità di lettura (su quelle tecniche ci abbiamo già messo una croce sopra da tempo). Ti ho già detto che avevo dei progetti su Mercurial e che non ho mai usato Bazaar (il giocattolo di Canonical). Confermo che ho recentemente migrato alcuni progetti da Mercurial a Subversion, per le ragioni già illustrate. Per quanto riguarda l’ultimo caso specifico da te menzionato, il problema non si pone visto che il server SVN è sempre disponibile e tutti i miei sistemi sono sempre online, oltre al fatto che in piccoli progetti con pochi sviluppatori, non è necessario fare un commit per ogni sciocchezza.
Kim Allamandola
06 giu 2011 - 12:25 - #13@ekerazha #12
Cosa vuoi che ti dica? È più semplice installare e configurare un server (che
magari deve essere raggiungibile anche via internet per chi sviluppa fuori da
una LAN/VPN) che magari includa apache ed openssl giusto da evitare sorpresine
sgradite, magari non si committ-a se sei connesso via GSM, magari è mooolto
difficile fare dei branch diversi condivisi (e poi merge-arli nel trunk) se
vuoi fare qualche esperimento ecc ecc ecc
Sia con mercurial che con bazaar (che consiglio a chiunque sviluppi di provare)
la complessità di gestire una soluzione full p2p, senza quindi installare e
configurare un server, gestire l’autenticazione ecc si riduce a:
commit verso il tree principale:
hg/bzr push
“co” dal tree principale:
hg/bzr pull
Certo, è più semplice installare Apache+OpenSSL+ (ev.) MySQL per una gestione
completa degli accessi o dare accesso ssh ristretto a tutti, distribuire le
chiavi ecc ecc ecc… Tutto stà al significato della parola “semplice”. Ah,
certo, fare branch “di test”, poter committ-are ad ogni passo giusto da aver
un rollback rapido ecc (cosa sconsigliata e mooolto difficile con cvs/svn) non
è poi molto importante…
Se mi chiederanno un programmatore farò il tuo nome!
Kim Allamandola
06 giu 2011 - 12:29 - #14Errata corrige (’nasidente a blogo e al modo in cui zappa il testo…)
dentro la workDir
hg push $RepoDiUnCollega e/o $Repo”Ufficiale”
hg pull $RepoDiUnCollega e/o $Repo”Ufficiale”
Ovviamente ognuno commit-a come vuole in maniera del tutto indipendente dai
sync push/pull.
ekerazha
06 giu 2011 - 16:59 - #15Per un progetto di piccole dimensioni e con pochi sviluppatori, non serve fare alcun branch e come già detto non serve fare un commit per ogni sciocchezza, si possono fare commit più corposi che, proprio per la natura del progetto, non sono comunque difficili da seguire.
Ti ringrazio per volermi tenere in considerazione in caso di richieste, ma purtroppo sono già occupato. Mi scuserai inoltre se non ricambierò il favore, considerando le sciocchezze che continui a propinarci in ogni articolo, non me la sento proprio :)
Kim Allamandola
06 giu 2011 - 20:33 - #16Un piccolo progetto gestito tra amici non ha bisogno di branch? Ne hai mai
fatto uno? No perché quando si è in pochi e non si ha un design blindato, cosa
che si verifica nella stragrande maggioranza dei casi, ognuno vuole seguire una
propria idea.
In genere si segue un più o meno definito design di base e poi ognuno si fa per
i fatti proprio alcune cose personali (un branch appunto) che fa vedere ai
colleghi e se piacciono le inserisce nel repo “ufficiale” (merge del/dei branch
la cosa più difficile con cvs/svn).
Quanto ai commit: più commit fai più tracci ogni cosa fai, più puoi tornare sui
tuoi passi se sbagli qualcosa. Prova a tornare sui tuoi passi dopo aver
modificato 600 righe di codice sparse in n file e prova a far lo stesso quando
né hai solo modificate 4 o 5 e scritte ex-novo una ventina, poi ne parliamo.
Certo con subversion avendo *solo* un repo condiviso non puoi: devi committare
solo quando sei più che sicuro che il truck sia funzionante. È un problema
sbizzarrirsi a sperimentare ecc ecc ecc. Questione di scelte, c’è gente a cui
piacciono le manette e piace star scomodi e c’è gente a cui piace la libertà…
ekerazha
06 giu 2011 - 21:53 - #17Evidentemente tu ed i tuoi amici non siete in grado di fare un minimo di pianificazione. A casa mia prima si discute e poi eventualmente si implementa, si usa il cervello e non si picchiano i tasti come farebbero delle scimmie.
Non c’è nemmeno bisogno di una nuova risposta, ti basta rileggere le ultime 3 righe del mio precedente intervento.
ekerazha
06 giu 2011 - 21:56 - #18Pardon… le *prime* 3 righe :)
Kim Allamandola
07 giu 2011 - 10:04 - #19Vabbé, inutile discutere, probabilmente sei un esponente degli immobilisti:
coloro che pensano in teoria (la pratica non funziona mai, ma è colpa di
altri…) e che vorrebbero tutto fermo ai loro anni d’oro “che allora si, le cose
funzionavano”…
Non ho *mai* visto un progetto dove *tutto* il design viene fatto ed ultimato
prima di scrivere la prima riga di codice e da allora non si cambia nulla non
si esperimenta nulla ecc; ci si limita alla pura implementazione del design di
partenza. Queste cose le ho lette sui libri, e quelli più seri (chesò, Brooks)
non si fan pudore a dire che tra teoria e pratica c’è una certa sostanziale
differenza.
Nel Mondo Reale®, quello cui sostieni io non appartenga, di deciso, quando va
bene, c’è il design di base: il “telaio”, il resta cambia n volte in corso
d’opera (e spesso si aggiusta pure il design di base) e si fanno n-mila rami
più o meno privati parti dei quali si uniscono al tree principale. I dCVS sono
nati proprio per facilitare questo. La stessa evoluzione di Darwin descrive
come nel Mondo Reale® ci siano “prove” e “passi falsi”; forse anche Darwing
viveva in un mondo immaginiario…
guiodic
07 giu 2011 - 14:33 - #20usare launchpad con bazaar è macchinoso, l’unico vantaggio è la possibilità di creare i PPA daily che sono molto comodi. Per il resto tutti gli altri servizi sono molto più semplici e spesso e volentieri con più funzionalità.
apeacox
07 giu 2011 - 14:39 - #21@Kim #4: qualche correzione su github:
* offre la gestione di bugs, features, commenti sul codice, etc.. anzi, è più avanzato e comdo di launchpad in questo (almeno imho);
* offre la possibilità di pubblicare pagine statiche (ed esistono decine di tools per gestire un blog staticamente, quindi non trovo che sia un grosso problema)
* il fatto che sia diffuso, non vuol dire che che la gente lo usa solo perchè non conosce gli altri. personalmente ho sempre evitato i vari SVN/CVS finchè possibile. bazaar non mi è piaciuto, mercurial non lo conosco perchè statisticamente mi capita di trovare i progetti che mi interessano su git.
infine, non riesco a capire perchè molte persone trovano che git sia complesso. personalmente lo trovo molto immediato, anche quando mi capita di usare features più avanzate (rebase, reset, etc..).
Kim Allamandola
07 giu 2011 - 20:56 - #22Grazie per le precisazioni su GitHub, non l’ho mai considerato granché non
usando Git; non sapevo offrisse la possibilità di mini siti-vetrina statici,
non né ho mai visti per i progetti GitHub che uso, come non sapevo fosse
integrato con git a-la-bazaar (es. registrare un branch, annotare un fix nel
bugzilla ecc).
Sulla complessità di git, bé quanti binari ha git rispetto a mercurial/bazaar?
Git sono sui 140+ binari contro 1, già questo è una certa complessità :-)
Al di la di ciò perché non mi basta “git add .” come faccio con bazaar/mercurial
perché i branch devono essere “view”, perché non posso avere numeri di versione
ma solo hash, perché ho pezzi di sintassi invertita rispetto agli altri dCVS (es
pull vs fetch) ecc.
Non è l’unico outsider, anche monotone ha una sintassi “sui generis”, però è
assai meno noto di git, cosa che mi porta a pensare che git sia noto più grazie
al suo sviluppatore principale che non grazie alle sue caratteristiche, anche
se ovviamente è solo un’opinione estemporanea senza prove :-)
Certo git per progetti come Linux avrà i sui vantaggi ma per la maggior parte
dei progetti non credo (e progetti grossi come IllumOS o il vecchio OSol con
mercurial stan benissimo, cosiccome Ubuntu o MySQL o Inkscape stan bene con
bazaar) in più chi viene da svn/cvs sia con mercurial che sopratutto con bazaar
si trova “subito” a casa.
La cosa che più m’ha colpito cmq è la posizione di ekerazha su svn, che tanti
siano ancora su svn perché “migrare è faticoso” l’ho sentita spesso, che si
torni da mercurial al vecchio svn è la prima volta che lo sento!
ekerazha
08 giu 2011 - 08:22 - #23Blah blah blah… non so se l’hai notato, ma te la canti e te la suoni da solo.
Vorresti fare sofismi sulla differenza tra la teoria e la pratica e mi vieni a dire che è in un certo modo perché l’hai letto su un libro? Si parla di piccoli progetti con pochi sviluppatori e mi vieni a parlare di n-mila rami? Cosa fai, un ramo per ogni riga di codice? Inoltre, nessuno ha detto che non si possa cambiare nulla in corsa, ma anche eventuali modifiche vanno discusse prima di picchiare i tasti. Questo è un modo intelligente di operare.
apeacox
08 giu 2011 - 17:04 - #24@kim #22 : grazie a te per la risposta ;)
per quel poco che posso dire in merito a git (e github), lavorando nel mondo ruby/rails, per me è praticamente una scelta obbligata (il 99% dell’ecosistema è su git). avendo provato in modo superficiale altri VCS (svn e bazaar), stranamente ho notato che con git mi sono trovato subito a mio agio, con gli altri mi sentivo troppo *legato*.
apprezzo molto il fatto che sia abbastanza immediato forkare un progetto, creare/modificare branch e fare una pull-request senza troppi sbattimenti.
usandolo quotidianamente, almeno nel mio caso, non mi limito al semplice “git init .”, anzi… :P
ovviamente è anche questione di gusti ed abitudini ;)
Kim Allamandola
08 giu 2011 - 23:27 - #25@apeacox #24
Mi fa piacere sentire un rubysta; sono un fan di ruby anche se per alcune sue
caratteristiche non lo uso come Linguaggio Preferito® (gestione unicode per lo
più) ma è stata la mia ancora quando decisi che era inutile restare sul Perl…
Bé se hai iniziato con git è naturale ti ci trovi: è più complesso di bazaar o
mercurial ma non è mal fatto! È solo stato pensato per le necessità di uno
specifico progetto (Linux) dopo che Linus Torvalds litigò con Larry McVoy di
BitMover per il suo vcs proprietario (BitKeeper) usato da Linus sino ad allora;
poi si è evoluto ma ha mantenuto quel suo design un po’ sui generis che per chi
come me veniva già da dCVS (Mercurial all’epoca) fa storcere il naso cosiccome
fa storcere il naso monotone :-(
Bazaar ha di suo due caratteristiche che forse ti possono interessare:
* il repo locale condiviso
* il branching senza view
puoi creare un repo con bzr init ma poniamo il caso tu abbia n branch sulla tua
macchina di sviluppo: senza deduplicazione hai molto spazio disco sprecato che
per progetti ROR grossi sui costosi ssd attuali potresti voler risparmiare; con
Bazaar puoi andare un una dir chesò “prjs” contenente tutti i progetti che hai
con Bazaar e dare bzr init-repo al suo interno: tutti i branch che creerai con
bzr init e successivi branch non occuperanno spazio disco in più, verranno
salvati solo i delta dei singoli branch. Poi non avendo view non dovrai fare
cose “curiose” come checkout HEAD ecc. :-)
Ad ogni modo oggi si può mescolare git bazaar e mercurial senza troppe
bestemmie sulle stesse source senza dover fare lunghi import di volta in volta!
@ekerazha #23
non credo abbia senso continuare, la differenza tra teoria e pratica la vedo
tutti i giorni e anche se così non fosse quando gente del calibro di Brooks o
Raymond perdono tempo a favore di una certa tesi un’occhio forse vale la pena
di darcelo. Se per i tuoi progetti riesci bene con svn, tanti auguri, sei il
primo che sento. Tieni solo presente che o svilupperai svn da solo o nel giro
di qualche anno avrai sempre più problemi a stare al passo con un mondo che
cambia…