Bitbucket è una piattaforma Atlassian per ospitare repository Git, collaborare sul codice e collegare sviluppo, revisione e CI/CD. Puoi usarla semplicemente come repository remoto, ma fermarsi a questa definizione significa descrivere solo una parte del prodotto.
Il motivo più concreto per valutarla emerge quando il codice deve entrare in un workflow più ampio: branch e pull request, controlli prima del merge, pipeline automatiche, Jira, package registry e regole di accesso per il team.
È anche un servizio cambiato parecchio negli ultimi anni. Alcune informazioni ancora presenti in guide e confronti online non sono più valide: Mercurial è stato rimosso, la linea Server è fuori supporto, le app password hanno lasciato il posto agli API token e nel 2026 sono scomparsi anche i vecchi Issues e Wiki nativi.
In questa guida vediamo quindi cos’è Bitbucket oggi, come funziona davvero e in quali scenari può avere più senso rispetto a GitHub o GitLab.
Bitbucket oggi: cos’è e a cosa serve
La piattaforma nasce intorno ai repository Git, ma oggi va letta come uno dei componenti del più ampio ecosistema Atlassian. Il repository rimane il punto di partenza; intorno trovi collaborazione sul codice, automazione CI/CD, integrazione con Jira, governance e servizi destinati ai team di sviluppo.
Questa distinzione è importante perché consente di capire subito quando il prodotto aggiunge valore e quando, invece, stai semplicemente cercando un posto dove salvare un repository remoto.
Bitbucket Cloud come piattaforma per repository Git
Bitbucket Cloud è il servizio SaaS gestito da Atlassian.
Il codice viene versionato localmente con Git e sincronizzato con il repository remoto. Il servizio aggiunge il livello collaborativo necessario per lavorare con altre persone: accessi, branch, pull request, code review e automazioni.
Puoi creare repository pubblici o privati, organizzare i membri del team e collegare il progetto agli altri strumenti Atlassian.
Il piano gratuito è attualmente disponibile fino a cinque utenti; per tariffe e condizioni aggiornate conviene verificare direttamente la pagina ufficiale dei prezzi.
Se invece vuoi confrontare più servizi di hosting del codice, trovi un approfondimento separato sui migliori repository di codice sorgente.
Git e Bitbucket non sono la stessa cosa
La distinzione più importante per chi parte da zero è tra Git e il servizio che ospita il repository.
Git è il sistema di controllo versione distribuito. Registra commit, branch e cronologia del progetto e può funzionare anche senza una piattaforma cloud.
Il servizio Atlassian è invece uno dei possibili remote Git e aggiunge collaborazione, interfaccia web e automazione.
In pratica il flusso è questo:
codice locale → Git → repository remoto → pull request → review → merge → build o deployment
Questa differenza ha una conseguenza utile: il repository Git non è tecnicamente vincolato alla piattaforma. Puoi cambiare remote e spostare il codice altrove.
La parte più delicata di una migrazione è generalmente ciò che vive intorno al repository: pipeline, permessi, pull request, integrazioni e processi interni.
Perché l’ecosistema Atlassian è il vero elemento distintivo
Il vantaggio più riconoscibile non deriva da una diversa implementazione di Git.
Deriva soprattutto dal collegamento con strumenti come Jira.
Quando Jira Cloud e il repository sono integrati, una chiave del work item inserita nel nome del branch, in un commit o nel titolo di una pull request permette di collegare sviluppo e pianificazione. La documentazione Atlassian sull’integrazione con Jira mostra anche come creare work item e aggiornare il loro stato durante il ciclo di sviluppo.
Per un team che usa già Jira ogni giorno, questa continuità può pesare più di una singola funzione tecnica.
Per un freelance o un piccolo progetto che non utilizza l’ecosistema Atlassian, lo stesso vantaggio può invece essere marginale.
Cosa è cambiato in Bitbucket e quali informazioni non sono più valide
Prima di valutare il prodotto è utile eliminare alcune informazioni legacy che continuano a comparire nei tutorial. In questo caso la freschezza non è un dettaglio: può cambiare concretamente la scelta della piattaforma e le procedure da seguire.
Quattro aree meritano particolare attenzione: sistemi di versionamento supportati, issue tracking, autenticazione e modello di deployment.
Mercurial non è più supportato: oggi il servizio è basato su Git
Il prodotto nacque con un forte legame con Mercurial e molte guide storiche continuano a presentarlo come piattaforma compatibile sia con Git sia con Mercurial.
Non è più così.
Atlassian ha disabilitato la creazione di repository Mercurial nel 2020 e ne ha successivamente rimosso il supporto dal servizio.
Se stai valutando la piattaforma oggi, quindi, Git è il sistema di controllo versione rilevante.
Issues e Wiki native sono state rimosse da Bitbucket Cloud
Anche il vecchio issue tracker integrato non può più essere considerato una funzionalità attuale.
Il 20 agosto 2026 Atlassian ha completato la rimozione dei vecchi Issues e Wiki nativi, eliminandoli sia dall’interfaccia sia dalle API.
Per issue tracking e documentazione, la direzione indicata dal vendor è usare strumenti dedicati come Jira e Confluence.
La conseguenza è significativa: il prodotto è oggi meno orientato a concentrare project management e repository nella stessa applicazione e più integrato nella piattaforma Atlassian complessiva.
Dalle app password agli API token
Anche l’autenticazione è cambiata.
Dal 9 settembre 2025 non è più possibile creare nuove app password e quelle esistenti sono state disabilitate il 9 giugno 2026.
Per script, API e integrazioni Atlassian indica ora gli API token con scope come soluzione a lungo termine.
Un token può avere permessi limitati e può essere circoscritto a uno specifico workspace. Va comunque trattato come una credenziale: non inserirlo nel repository e non condividerlo tra utenti.
Se una guida ti chiede ancora di creare una app password per autenticare uno script, è quindi probabilmente datata.
Bitbucket Server è legacy, ma Data Center non è scomparso
Il supporto per Bitbucket Server è terminato il 15 febbraio 2024.
Atlassian non fornisce più supporto e bug fix per quella linea, come specificato nella pagina ufficiale dedicata alla fine del supporto dei prodotti Server.
Questo non significa però che ogni soluzione self-managed sia stata eliminata.
Data Center continua a esistere per organizzazioni che necessitano di gestire direttamente l’infrastruttura.
La distinzione corretta è quindi:
Server → legacy e fuori supporto
Cloud → SaaS gestito da Atlassian
Data Center → deployment self-managed per esigenze specifiche
Come funziona Bitbucket nella pratica
Una volta chiariti i cambiamenti recenti, il funzionamento quotidiano è relativamente lineare per chi conosce già Git. La piattaforma aggiunge una struttura organizzativa sopra repository, branch e pull request e permette di applicare controlli progressivamente più rigidi quando il team cresce.
Non serve utilizzare fin dall’inizio ogni funzione disponibile. Conviene partire dal normale workflow Git e aggiungere governance e automazione solo dove risolvono un problema reale.
Workspace, progetti e repository
Il workspace è il contenitore collaborativo principale.
Al suo interno puoi organizzare utenti, gruppi, progetti e repository.
Un progetto serve a raggruppare repository correlati, mentre il repository contiene il codice e la cronologia Git.
Questa gerarchia diventa particolarmente utile quando non devi più gestire un singolo sito o una sola applicazione, ma molti repository con utenti e permessi differenti.
Branch, commit, pull request e code review
Il normale workflow rimane quello di Git.
Crei un branch per una modifica, registri i commit, esegui il push e apri una pull request verso il branch di destinazione.
La pull request diventa il punto in cui il team può verificare il codice, commentare le modifiche, richiedere approvazioni, controllare le build e decidere se effettuare il merge.
Se vuoi approfondire questi concetti dal punto di vista di un’altra piattaforma, nella nostra guida a GitHub trovi una spiegazione più estesa di repository, commit, branch e pull request.
Merge checks, permessi e controllo del workflow
Quando aumentano sviluppatori e repository, il problema non è più soltanto condividere il codice.
Devi anche stabilire chi può modificare determinati branch e quali condizioni devono essere soddisfatte prima di un merge.
Le branch permissions consentono di controllare quali utenti o gruppi possono scrivere o effettuare merge su branch specifici o pattern di branch.
A queste regole si aggiungono i merge checks, che possono verificare condizioni come approvazioni, build superate o task ancora aperti.
Qui emerge una differenza importante tra semplice collaborazione e governance: sapere che una piattaforma supporta la code review non basta. Per un’organizzazione conta anche capire quali controlli possono essere resi obbligatori e con quale piano.
Come si integra con Jira
L’integrazione con Jira diventa utile quando viene incorporata nel processo di sviluppo, non semplicemente attivata.
Puoi, per esempio, collegare un branch a un work item, associare commit e pull request allo stesso lavoro e aggiornare lo stato del ticket durante il merge.
Questo crea una traccia più chiara tra richiesta, implementazione e rilascio.
Per i team già centrati su Jira è uno dei motivi più concreti per mantenere codice e pianificazione nello stesso ecosistema.
Bitbucket Pipelines, Packages e AI
Il repository rappresenta solo una parte dell’offerta corrente. Atlassian sta ampliando sempre più il prodotto verso automazione, gestione degli artefatti e funzioni AI integrate nel ciclo di sviluppo.
Queste componenti non hanno tutte lo stesso peso: Pipelines può modificare concretamente l’architettura CI/CD di un progetto, mentre le funzioni AI sono più recenti e molto più soggette a cambiamenti.
Come funziona Bitbucket Pipelines per CI/CD
Bitbucket Pipelines è il sistema CI/CD integrato.
La configurazione viene normalmente definita nel file bitbucket-pipelines.yml, che descrive gli step da eseguire.
La reference ufficiale di Pipelines permette di configurare immagini Docker, cache, servizi, stage, step paralleli e altre opzioni.
Un workflow tipico può seguire questa sequenza:
push → installazione dipendenze → lint → test → build → staging → produzione
Il vantaggio principale è che repository e automazione vivono nello stesso ambiente.
Lo stesso meccanismo può essere applicato anche allo sviluppo di siti: nella nostra guida allo staging WordPress mostriamo perché strumenti di CI/CD possono essere utili per collegare branch, test, ambiente di staging e rilascio.
Build minutes, runner e limiti da controllare
I minuti di esecuzione inclusi dipendono dal piano e vengono condivisi all’interno del workspace.
La documentazione di billing di Bitbucket Cloud indica attualmente:
| Piano | Build minutes al mese | Git LFS incluso |
|---|---|---|
| Free | 50 | 1 GB |
| Standard | 2.500 | 5 GB |
| Premium | 3.500 | 10 GB |
Per carichi superiori puoi acquistare utilizzo aggiuntivo sui piani compatibili oppure ricorrere a runner self-hosted.
Un team con pochi sviluppatori ma pipeline molto frequenti può quindi avere esigenze diverse da un’organizzazione con molti utenti e poca automazione.
Bitbucket Packages per container e librerie
La piattaforma non gestisce più soltanto codice sorgente.
Nel 2026 Atlassian ha ampliato Packages fino a coprire container, Maven, npm, PyPI e NuGet, come descritto nell’annuncio dedicato ai nuovi registry.
Questo permette di mantenere più vicini repository e artefatti prodotti dal software.
Il vantaggio aumenta nei team che vogliono evitare un servizio separato per ogni registry, ma va comunque confrontato con i package registry già utilizzati nel proprio stack.
Rovo e le funzionalità AI nel workflow di sviluppo
Atlassian sta integrando Rovo e Rovo Dev nelle attività di sviluppo.
Le funzioni AI associate a Bitbucket includono scenari come code review assistita, comprensione del codice e analisi dei problemi delle pipeline.
Rovo è disponibile nei piani Cloud compatibili, mentre Rovo Dev ha packaging distinto.
È una distinzione importante: non tutte le capacità AI presentate dal vendor appartengono necessariamente allo stesso abbonamento.
Non sceglierei comunque una piattaforma Git soltanto per questo elemento. L’AI è una delle aree più volatili del mercato e anche GitHub e GitLab stanno modificando rapidamente le rispettive offerte.
Prezzi Bitbucket: Free, Standard e Premium
Il confronto economico richiede più attenzione di quanto sembri, perché Atlassian sta aggiornando anche i propri sistemi di billing. I prezzi pubblici e quelli visualizzati per alcuni account possono quindi non coincidere perfettamente.
Per questo considero il listino un dato da verificare al momento dell’acquisto, non una caratteristica evergreen del prodotto.
Cosa include il piano Free
La pagina pubblica dei prezzi Bitbucket mostra attualmente Free a 0 dollari fino a cinque utenti.
Il piano gratuito consente repository pubblici e privati e include 50 minuti mensili di Pipelines.
Per un repository personale o un piccolo progetto può essere sufficiente, soprattutto se l’automazione CI/CD è limitata.
Il vincolo dei cinque utenti diventa invece rilevante quando il workspace cresce.
Cosa cambia con Standard
Sul listino pubblico Atlassian, Standard è indicato a 3,65 dollari per utente al mese.
Aumentano in modo sostanziale build minutes e spazio Git LFS e viene rimosso il limite di cinque membri tipico del piano gratuito.
C’è però una particolarità da conoscere: la documentazione del nuovo sistema di billing mostra, per alcuni account gestiti tramite il nuovo motore, valori diversi da quelli della pagina pubblica.
Per questo, prima dell’acquisto, è più corretto controllare il prezzo effettivamente proposto al proprio workspace anziché affidarsi a una cifra letta in un confronto online.
Quando servono le funzioni Premium
Il listino pubblico indica Premium a 7,25 dollari per utente al mese.
Il salto di valore non riguarda soltanto le quote.
Questo livello aggiunge controlli pensati per organizzazioni con maggiori esigenze di governance, sicurezza e amministrazione, come merge checks più avanzati, deployment permissions e controlli di accesso.
Se lavori da solo o in un piccolo team, queste funzioni potrebbero non giustificare il costo superiore.
Per un’organizzazione che deve far rispettare policy precise, invece, possono diventare parte essenziale del workflow.
Perché utenti, build minutes e storage contano più del solo prezzo per utente
Il costo reale non coincide necessariamente con il numero mostrato nella colonna “per utente”.
Prima di confrontare i piani conviene considerare insieme:
- numero di membri del workspace;
- frequenza e durata delle pipeline;
- Git LFS e package storage;
- eventuali runner;
- controlli amministrativi e di sicurezza.
Un team piccolo con build molto pesanti può consumare più risorse di uno molto più grande che utilizza il repository quasi esclusivamente per versionare codice.
Bitbucket Cloud, Data Center e Hybrid License
Cloud e Data Center non sono semplicemente due piani dello stesso servizio: rappresentano modelli operativi differenti. Uno delega l’infrastruttura ad Atlassian, l’altro mantiene il codice e il prodotto in un ambiente gestito dall’organizzazione.
Per questo la scelta va fatta partendo dai requisiti di deployment, sicurezza e compliance, non dal numero di funzioni mostrate in una tabella.
Quando scegliere Bitbucket Cloud
La versione Cloud è il percorso più semplice quando non esiste un requisito specifico per mantenere direttamente l’infrastruttura.
Aggiornamenti e gestione del servizio restano ad Atlassian, mentre il team può concentrarsi sul flusso di sviluppo.
È anche l’ambiente in cui vengono rese disponibili più direttamente funzioni recenti come Pipelines, Packages e diverse integrazioni AI.
Per piccoli team e software house che possono utilizzare SaaS, è quindi il punto di partenza naturale da valutare.
A chi serve ancora Bitbucket Data Center
Data Center rimane rivolto a organizzazioni con esigenze particolari di controllo, sicurezza o regolamentazione.
C’è inoltre una differenza importante rispetto agli altri prodotti Atlassian: la pagina ufficiale sulla fine vita di Data Center specifica che Bitbucket Data Center non terminerà il proprio ciclo di vita nel marzo 2029 insieme agli altri prodotti interessati.
Questa eccezione esiste perché il codice sorgente può avere requisiti di gestione differenti rispetto ad altri dati aziendali.
Come cambia lo scenario con Bitbucket Hybrid License
Atlassian sta affiancando al modello self-managed una Hybrid License destinata ai clienti Data Center e Server esistenti.
L’idea è consentire di mantenere il codice sul deployment self-managed e, contemporaneamente, utilizzare determinate innovazioni Cloud.
La pagina dedicata alla Bitbucket Hybrid License la presenta come il futuro modello commerciale per i clienti Data Center.
La stessa pagina pubblica contiene ancora riferimenti temporali al rollout “mid-2026”, quindi la disponibilità effettiva e le condizioni applicabili al singolo contratto vanno verificate direttamente con Atlassian.
Questa è una delle aree in cui eviterei di basare una decisione su un articolo statico.
Cosa fare se utilizzi ancora Bitbucket Server
Una installazione Server non dovrebbe più essere trattata come un normale ambiente supportato.
Le opzioni da valutare sono Cloud, Data Center, il percorso Hybrid quando applicabile oppure la migrazione verso un’altra piattaforma.
Continuare a utilizzare una linea fuori supporto senza una strategia di uscita espone soprattutto a un problema progressivo di manutenzione e sicurezza, indipendentemente dal fatto che l’installazione continui tecnicamente a funzionare.
Bitbucket vs GitHub e GitLab: le differenze che contano davvero
Un confronto utile non consiste nel contare quante caselle vengono spuntate in una tabella. Le tre piattaforme coprono ormai molti fondamentali comuni: repository Git, pull request o merge request, CI/CD, package management, automazione e funzioni AI.
La differenza emerge soprattutto dal sistema di lavoro che vuoi costruire intorno al codice.
| Criterio | Bitbucket | GitHub | GitLab |
|---|---|---|---|
| Posizionamento naturale | codice e workflow Atlassian | collaborazione sul codice ed ecosistema pubblico | piattaforma DevSecOps integrata |
| CI/CD | Pipelines | GitHub Actions | GitLab CI/CD |
| Tracking del lavoro | forte integrazione Jira | Issues e Projects | pianificazione integrata |
| Package registry | Packages | GitHub Packages | Package e Container Registry |
| Self-managed | Data Center / strategia Hybrid | GitHub Enterprise Server | GitLab Self-Managed |
| Scenario tipico | team Atlassian e Jira | community, open source, ampio ecosistema | consolidamento DevSecOps |
Bitbucket vs GitHub: Atlassian workflow, community ed ecosistema
Il confronto Bitbucket vs GitHub diventa più semplice se parti dall’organizzazione del team.
Se utilizzi già Jira in modo esteso e vuoi collegare strettamente work item, branch, commit, pull request e delivery, la soluzione Atlassian ha una coerenza naturale.
GitHub ha invece costruito un ecosistema molto forte intorno a community, open source e automazione. Anche GitHub Actions copre nativamente build, test e deployment attraverso workflow associati al repository.
Questo non significa che una piattaforma sia universalmente migliore dell’altra.
Significa che il contesto di partenza cambia il valore delle stesse funzioni.
Bitbucket vs GitLab: toolchain modulare o piattaforma DevSecOps
GitLab segue una logica ancora diversa.
La sua piattaforma DevOps concentra source code management, CI/CD, sicurezza, compliance e altre fasi del ciclo di sviluppo in un sistema più unitario.
L’approccio Atlassian è maggiormente distribuito fra componenti collegati: repository, Jira, Confluence e altri servizi.
Il criterio di scelta diventa quindi:
vuoi una piattaforma DevSecOps più concentrata oppure preferisci collegare il repository allo stack Atlassian che utilizzi già?
Repository, CI/CD, AI, self-hosting e governance a confronto
Sul repository puro le differenze sono meno nette di qualche anno fa.
Tutte le principali alternative supportano workflow Git maturi.
La distanza aumenta quando consideri il resto:
Pipelines vs Actions vs GitLab CI/CD
Rovo/Rovo Dev vs Copilot vs GitLab Duo
Data Center vs Enterprise Server vs Self-Managed
integrazione Jira vs project management interno
Per un’organizzazione questi elementi possono essere molto più importanti della semplice interfaccia del repository.
Come scegliere in base al team invece che alla lista delle feature
Se usi Jira in modo esteso e vuoi collegare pianificazione e codice, la soluzione Atlassian merita particolare attenzione.
Se il progetto dipende molto da community, contributori esterni e visibilità pubblica, GitHub può offrire un ecosistema più coerente con quell’obiettivo.
Se invece vuoi concentrare molte fasi DevSecOps in una sola piattaforma e ridurre una toolchain frammentata, GitLab parte da una filosofia differente.
La scelta ha quindi più senso quando viene fatta sul workflow del team che sulla quantità di feature.
Come iniziare con Bitbucket senza complicare il workflow
Una nuova piattaforma di sviluppo diventa rapidamente complessa se provi ad attivare contemporaneamente permessi, pipeline, runner, package registry e integrazioni.
Per iniziare è più efficace costruire prima un workflow Git semplice e comprensibile e aggiungere automazione solo quando sai esattamente quale attività vuoi rendere ripetibile.
Creare workspace e repository
Il primo passo è scegliere o creare un workspace e aggiungere il repository.
Puoi poi associarlo a un progetto e definirne la visibilità.
All’inizio è sufficiente far funzionare correttamente questa sequenza:
repository → branch → commit → pull request → review → merge
Solo dopo ha senso aggiungere regole più sofisticate.
Collegare il repository Git con HTTPS o SSH
Puoi clonare e utilizzare un repository tramite HTTPS oppure SSH.
Con SSH devi configurare correttamente la coppia di chiavi. Con HTTPS utilizzi i sistemi di autenticazione attualmente supportati.
La scelta tra i due approcci è soprattutto operativa.
L’errore da evitare è affidarsi a tutorial che utilizzano password dell’account o vecchie app password ormai dismesse.
Usare correttamente gli API token
Per script e integrazioni crea token con i soli permessi necessari.
Un token deve avere uno scopo specifico e una durata coerente con l’utilizzo.
Non inserirlo nel codice, in file di configurazione versionati o direttamente nei comandi salvati nella cronologia del progetto.
Se una credenziale viene accidentalmente inserita in un commit, cancellarla dall’ultima versione del file non è sufficiente: devi revocarla e sostituirla.
Quando ha senso attivare una Pipeline
La prima pipeline dovrebbe automatizzare qualcosa che già sai eseguire manualmente.
Un buon esempio è:
push → dipendenze → lint → test → build → staging
Quando questo percorso è stabile puoi aggiungere deployment di produzione, step paralleli, runner self-hosted e controlli sulle pull request.
Automatizzare subito un processo non ancora definito rischia semplicemente di rendere più difficile capire dove si trova il problema.
Quando Bitbucket conviene e quando scegliere un’alternativa
La decisione finale dipende meno dal repository in sé e più dal modo in cui il team sviluppa, revisiona e distribuisce software. Lo stesso prodotto può risultare molto coerente per un’organizzazione già basata su Jira e poco interessante per un progetto che cerca soprattutto community pubblica.
Per questo conviene partire dallo scenario operativo e non dal nome della piattaforma.
Team già organizzati intorno a Jira e Atlassian
Questo è probabilmente il caso d’uso più evidente.
Se pianificazione, ticket, documentazione e altri processi passano già attraverso l’ecosistema Atlassian, portare anche il codice nello stesso ambiente può ridurre passaggi e duplicazioni.
Il vantaggio cresce quando più persone devono seguire il percorso da richiesta a sviluppo e rilascio.
Progetti orientati a community e open source
La piattaforma Atlassian permette repository pubblici, quindi non esiste un impedimento tecnico all’open source.
Se però discovery del progetto, contributori esterni e community sono elementi centrali, GitHub merita un confronto particolarmente attento.
Qui il fattore discriminante è l’ecosistema che si è sviluppato intorno ai repository, non la possibilità di impostarli come pubblici.
Team che cercano una piattaforma DevSecOps più monolitica
Se vuoi concentrare pianificazione, repository, CI/CD, registry, sicurezza e compliance nel minor numero possibile di componenti, GitLab segue un modello più esplicitamente unitario.
L’ecosistema Atlassian arriva a coprire un workflow molto ampio attraverso più servizi integrati.
Sono due architetture organizzative differenti, entrambe plausibili a seconda del contesto.
Organizzazioni con requisiti self-managed o ibridi
In questo scenario non basta confrontare le versioni SaaS.
Devi valutare requisiti normativi, residenza e controllo dei dati, gestione dell’infrastruttura, CI/CD e licensing.
La permanenza di Data Center e la strategia Hybrid rendono l’offerta Atlassian particolare rispetto al resto del portafoglio dell’azienda.
Per organizzazioni che devono mantenere il codice self-managed ma vogliono gradualmente accedere a funzioni Cloud, è un elemento da seguire con attenzione.
Conclusione
Bitbucket rimane una piattaforma costruita intorno ai repository Git, ma la ragione per sceglierla oggi non è semplicemente avere un posto dove salvare codice privato.
Il valore emerge soprattutto dal sistema che costruisci intorno al repository.
Per team già dentro Jira e nell’ecosistema Atlassian, può creare un percorso coerente fra pianificazione, sviluppo, code review, CI/CD e governance. Pipelines, Packages e le nuove capacità AI ne hanno inoltre ampliato il ruolo rispetto al semplice hosting Git.
È però importante valutarlo sulla base del prodotto attuale: Mercurial non è più supportato, Issues e Wiki native sono state rimosse, le app password sono state sostituite, Server è fuori supporto e la strategia self-managed sta evolvendo verso Data Center e Hybrid.
Se il tuo progetto ruota soprattutto attorno alla community open source, GitHub offre un contesto diverso. Se vuoi concentrare molte funzioni DevSecOps in un’unica piattaforma, GitLab segue un’altra impostazione.
La domanda più utile, quindi, non è “qual è il miglior servizio Git?”.
È questa:
dove deve vivere il codice e quali processi devono avvenire prima e dopo ogni modifica?