GitLab vs GitHub: i due sistemi di controllo delle versioni a confronto

GitLab e GitHub sono dei sistemi di controllo della versione per la gestione del codice sorgente nello sviluppo di software. Con l’ausilio di queste due piat­ta­for­me, gli svi­lup­pa­to­ri che lavorano in team possono elaborare il codice sorgente in con­tem­po­ra­nea, ef­fet­tua­re modifiche e, cosa forse più im­por­tan­te di tutte, mantenere la visione d’insieme su tutte le modifiche apportate. Ogni modifica può essere com­ple­ta­men­te tracciata e, se ne­ces­sa­rio, annullata.

Come si può dedurre già dai loro nomi, GitLab e GitHub si basano sul software di controllo della versione Git. Quest’ultimo lavora con i co­sid­det­ti re­po­si­to­ry, in cui gli utenti caricano il codice sorgente che possono poi elaborare insieme nel browser, negli editor di codice o in un terminale.

Se non conoscete ancora Git, potete farvi ra­pi­da­men­te un’idea sull’argomento leggendo il nostro tutorial su Git che fornisce una spie­ga­zio­ne di base sul software. Chi desidera conoscere più da vicino GitLab, può inoltre dare uno sguardo al nostro det­ta­glia­to tutorial su GitLab.

Oltre ad avere in comune l’im­por­tan­te ca­rat­te­ri­sti­ca di essere basati su Git, GitLab e GitHub pre­sen­ta­no alcune dif­fe­ren­ze so­stan­zia­li. Una delle più im­por­tan­ti è ad esempio l’enorme numero di utenti di GitHub che, essendo il sistema di controllo della versione più noto al mondo, detiene una posizione pressoché di monopolio. Non a caso, nel 2018 GitHub è stato acquisito da Microsoft.

La di­men­sio­ne e la posizione di mercato di GitHub hanno ov­via­men­te anche con­se­guen­ze a livello pratico: l’immenso pool di utenti offre, so­prat­tut­to nei progetti open source, la pos­si­bi­li­tà di trovare i col­la­bo­ra­to­ri adatti per i propri progetti. Inoltre, risulta più semplice integrare i re­po­si­to­ry di altri utenti. In generale, alla piat­ta­for­ma lavorano più svi­lup­pa­to­ri che la ampliano co­stan­te­men­te. Questo fa sì che GitHub sia una piat­ta­for­ma estre­ma­men­te stabile e potente.

Sia GitLab che GitHub di­spon­go­no di una versione gratuita e di una versione En­ter­pri­se per le aziende che, a sua volta, si suddivide in alcuni modelli in ab­bo­na­men­to con diverse funzioni.

In linea generale, entrambe le piat­ta­for­me possono essere in­stal­la­te su un proprio server. Nel caso di GitHub, questo è possibile solo con la versione a pagamento En­ter­pri­se. GitLab, invece, permette l’hosting su un proprio server anche con la versione gratuita Community. La stabilità del server nella versione ospitata di GitLab è in generale meno buona rispetto a GitHub; per questo può essere si­cu­ra­men­te con­si­glia­bi­le l’in­stal­la­zio­ne sul proprio server.

In ragione dell’ampia dif­fu­sio­ne di GitHub, il servizio è com­pa­ti­bi­le con numerosi programmi che fa­ci­li­ta­no il lavoro in team, ad esempio Docker, i tool CI/CD o le ap­pli­ca­zio­ni di project ma­na­ge­ment. Questa com­pa­ti­bi­li­tà risulta utile so­prat­tut­to nell’ambito dell’in­te­gra­zio­ne continua, dato che GitHub non offre un proprio tool per questa tecnica.

Per molto tempo, un grande vantaggio di GitLab è stato co­sti­tui­to dal numero in­de­fi­ni­to di re­po­si­to­ry gratuiti a di­spo­si­zio­ne degli utenti. Su questo fronte GitHub ha re­cu­pe­ra­to terreno e ora offre anche questa fun­zio­na­li­tà. Cio­no­no­stan­te, GitHub impone nella versione gratuita più re­stri­zio­ni rispetto a GitLab.

I rami protetti, ossia i rami di sviluppo ai quali hanno accesso solo de­ter­mi­na­ti utenti, possono ad esempio essere uti­liz­za­ti sia in GitLab che in GitHub. In GitHub, tuttavia, solo in re­po­si­to­ry pubblici, mentre in GitLab questa funzione è di­spo­ni­bi­le anche con re­po­si­to­ry privati. Ancora più pesante è la li­mi­ta­zio­ne a massimo tre svi­lup­pa­to­ri per re­po­si­to­ry privato in GitHub. Chi desidera lavorare in team più grandi deve passare all’ab­bo­na­men­to e uti­liz­za­re la versione En­ter­pri­se.

In generale, GitHub offre un po’ meno permessi utente: in GitHub, una gestione dei permessi strut­tu­ra­ta in base a diversi ruoli è possibile solo con l’ab­bo­na­men­to team a pagamento, mentre in GitLab quest’opzione è standard. Inoltre, GitLab offre un Container Registry in cui gli utenti possono salvare le immagini Docker create con i tool CI e gestirle come parte del re­po­si­to­ry di GitLab.

Poiché sia GitHub che GitLab si basano su Git, la mi­gra­zio­ne da una piat­ta­for­ma all’altra avviene senza grossi problemi. I re­po­si­to­ry, i wiki, le pull request e gli issue vengono ge­ne­ral­men­te importati con facilità. Esistono tuttavia alcune dif­fe­ren­ze ter­mi­no­lo­gi­che tra GitHub e GitLab, come mostra la tabella seguente:

So­prat­tut­to l’espres­sio­ne “re­po­si­to­ry” può creare con­fu­sio­ne nel passaggio da una piat­ta­for­ma all’altra, poiché molti utenti uti­liz­za­no questo termine come sinonimo di “project” no­no­stan­te in GitHub la parola “re­po­si­to­ry” comprenda sia i “re­po­si­to­ry Git” sia i “project asset”. Per questo con­te­ni­to­re GitLab utilizza invece espres­sa­men­te la parola “project” per indicare che qui sono contenuti tutti i dati di progetto im­por­tan­ti.

Con la sua in­ter­fac­cia utente grafica ordinata, GitLab appare più chiara a un primo sguardo, tanto che molti utenti at­tri­bui­sco­no alla piat­ta­for­ma un utilizzo più semplice e intuitivo. Ad esempio, in GitLab gli issue non vengono solo vi­sua­liz­za­ti come elenco, ma possono anche essere or­ga­niz­za­ti e gestiti in una board.

Un altro grande vantaggio rispetto a GitHub consiste nel fatto che la User Interface (UI) di GitLab è scalabile e si adatta in modo fles­si­bi­le alle di­men­sio­ni dello schermo, mentre GitHub offre solo una di­men­sio­ne fissa. Per la vi­sua­liz­za­zio­ne su di­spo­si­ti­vi mobili GitLab è quindi spesso la scelta migliore rispetto all’al­ter­na­ti­va GitHub.

Anche l’ela­bo­ra­zio­ne e la creazione di codice risultano un po’ più agevoli in GitLab, poiché il tool offre un ambiente di sviluppo integrato (IDE). Al contrario, GitHub dispone soltanto di un editor di testo es­sen­zia­le.