Close

Da SVN a Git: preparazione alla migrazione

In Perché scegliere Git? abbiamo parlato dei molti modi in cui Git può aiutare il team a diventare più Agile. Una volta deciso di effettuare il passaggio, la fase successiva è capire come migrare il flusso di lavoro di sviluppo esistente a Git.

Questo articolo illustra alcune delle principali modifiche che incontrerai durante la transizione del team da SVN a Git. La cosa più importante da ricordare durante il processo di migrazione è che Git non è SVN. Per sfruttare appieno il potenziale di Git, impegnati al massimo per aprirti a nuovi modi di pensare al controllo delle versioni.


Per gli amministratori


A seconda delle dimensioni del team, possono essere necessari da alcuni giorni a diversi mesi per portare a termine l'adozione di Git. In questa sezione vengono affrontate alcune delle principali preoccupazioni dei responsabili tecnici relativamente alla formazione dei dipendenti su Git e alla migrazione dei repository da SVN a Git.

Comandi Git di base


Una volta c'era la convinzione che Git avesse una curva di apprendimento ripida. Tuttavia, i responsabili di Git hanno rilasciato costantemente nuovi miglioramenti (come le intuitive impostazioni predefinite e i messaggi di assistenza contestuali) che hanno reso il processo di onboarding molto più agevole.

Atlassian offre una serie completa di tutorial Git autogestiti, oltre a webinar e sessioni di formazione dal vivo. Insieme, questi materiali dovrebbero sopperire a tutte le esigenze di formazione del tuo team per aiutarlo a iniziare a usare Git. Ecco una lista di alcuni comandi Git di base per iniziare a utilizzare Git:

Database
materiale correlato

Come spostare un repository Git completo

Logo di Bitbucket
Scopri la soluzione

Impara a utilizzare Git con Bitbucket Cloud

Task Git

Note

Comandi Git

Comunicare a Git la propria identità

Note

Per configurare il nome e l'indirizzo e-mail dell'autore da utilizzare con i commit. Tieni presente che Git rimuove alcuni caratteri (ad esempio i punti finali) da user.name.

Comandi Git

git config --global user.name "Sam Smith"git config --global user.email sam@example.com

Creare un nuovo repository locale

Notes

 

Comandi Git

git init

Estrarre un repository

Note

Per creare una copia di lavoro di un repository locale:

Comandi Git

git clone /percorso/a/repository

 

Note

Per i server remoti, usa:

Comandi Git

git clone username@host:/percorso/a/repository

Aggiungere dei file

Note

Per aggiungere uno o più file allo staging (indice):

Comandi Git

git add *

Commit

Note

Per eseguire il commit delle modifiche all'head (ma non ancora al repository remoto):

Comandi Git

git commit -m "Commit message"

 

Note

Per eseguire il commit dei file che hai aggiunto con git add e anche dei file che hai modificato da allora:

Comandi Git

git commit -a

Effettua il push

Note

Per inviare le modifiche al branch principale del repository remoto:

Comandi Git

git push origin main

Stato

Note

Per elencare i file che hai modificato e quelli che devi ancora aggiungere o sottoporre a commit:

Comandi Git

git status

Collegarsi a un repository remoto

Note

Se non hai collegato il repository locale a un server remoto, aggiungi il server per potervi eseguire il push:

Comandi Git

git remote add origin

 

Note

Per elencare tutti i repository remoti attualmente configurati:

Comandi Git

git remote -v

Branch

Note

Per creare un nuovo branch e passare a quest'ultimo:

Comandi Git

git checkout -b

 

Note

Per passare da un branch all'altro:

Comandi Git

Git checkout

 

Note

Per elencare tutti i branch del repository e indicare inoltre in quale branch ti trovi attualmente:

Comandi Git

git branch

 

Note

Per eliminare il branch di funzioni:

Comandi Git

git branch -d

 

Note

Per eseguire il push del branch al repository remoto per consentire agli altri di usarlo:

Comandi Git

git push origin

 

Note

Per inviare tutti i branch al repository remoto:

Comandi Git

git push --all origin

 

Note

Per eliminare un branch nel repository remoto:

Comandi Git

git push origin :

Aggiornare dal repository remoto

Note

Per recuperare ed eseguire il merge delle modifiche dal server remoto alla directory di lavoro:

Comandi Git

git pull

 

Note

Per eseguire il merge di un branch diverso nel branch attivo:

Comandi Git

Git merge

 

Note

Per visualizzare tutti i conflitti di merge: Per visualizzare i conflitti con il file di base: Per visualizzare in anteprima le modifiche, prima del merge:

Comandi Git

git diff
git diff --base
git diff

 

Note

Per contrassegnare il file modificato dopo aver risolto manualmente gli eventuali conflitti:

Comandi Git

git add

Tag

Note

Puoi usare i tag per contrassegnare un set di modifiche significativo, ad esempio un rilascio:

Comandi Git

git tag 1.0.0

 

Note

L'ID del commit corrisponde ai caratteri principali dell'ID del set di modifiche, fino a un massimo di 10, ma deve essere univoco. Ottieni l'ID utilizzando:

Comandi Git

Git log

 

Note

Per eseguire il push di tutti i tag al repository remoto:

Comandi Git

git push --tags origin

Annullare le modifiche locali

Note

Se sbagli, puoi sostituire le modifiche nell'albero di lavoro con l'ultimo contenuto di head: Le modifiche già aggiunte all'indice, così come i nuovi file, verranno mantenute.

Comandi Git

git checkout --

 

Note

Invece, per eliminare tutte le modifiche e i commit locali, recuperare la cronologia più recente dal server e puntare il branch principale locale a quest'ultimo, procedi come segue:

Comandi Git

git fetch origingit reset --hard origin/main

Cerca

Note

Per cercare foo() nella directory di lavoro:

Comandi Git

git grep "foo()"

Strumenti per la migrazione a Git


Sono disponibili diversi strumenti per aiutarti a migrare i progetti esistenti da SVN a Git, ma prima di decidere quali usare è necessario capire come vuoi migrare il codice. Le opzioni a tua disposizione sono:

  • Migrare l'intera base di codice su Git e smettere del tutto di usare SVN.
  • Non migrare alcun progetto esistente su Git, ma usare Git per tutti i nuovi progetti.
  • Migrare alcuni dei progetti su Git continuando a utilizzare SVN per gli altri progetti.
  • Usare SVN e Git contemporaneamente negli stessi progetti.

Una transizione completa a Git limita la complessità del flusso di lavoro di sviluppo, quindi questa è l'opzione preferita. Tuttavia, non è sempre possibile procedere in questo modo nelle aziende più grandi con decine di team di sviluppo e potenzialmente centinaia di progetti. In queste situazioni, un approccio ibrido è l'opzione più sicura.

La varietà di strumenti per la migrazione a tua disposizione dipende in gran parte da quale strategia scegli tra quelle descritte sopra. Di seguito sono presentati alcuni degli strumenti per la migrazione da SVN a Git più comuni.

Script di migrazione di Atlassian

Se ti interessa effettuare una transizione subitanea a Git, gli script di migrazione di Atlassian sono una buona scelta. Questi script ti forniscono tutti gli strumenti necessari per trasformare in modo affidabile i repository SVN esistenti in repository Git. La cronologia nativa Git risultante garantisce che non sarà necessario affrontare alcun problema di interoperabilità da SVN a Git dopo il processo di conversione.

Abbiamo creato una guida tecnica completa per l'utilizzo di questi script per la conversione dell'intera base di codice in una raccolta di repository Git. In questa procedura dettagliata sono spiegati tutti i passaggi, dall'estrazione delle informazioni sull'autore in SVN alla riorganizzazione delle strutture di repository SVN non standard.

Plug-in SVN Mirror for Stash (ora Bitbucket)

SVN Mirror for StashSVN Mirror for Stash è un plug-in di Bitbucket che consente di mantenere agevolmente una base di codice ibrida che funziona sia con SVN che con Git. A differenza degli script di migrazione di Atlassian, SVN Mirror for Stash consente di utilizzare Git e SVN contemporaneamente sullo stesso progetto per tutto il tempo che desideri.

Questo compromesso è un'ottima opzione per le aziende più grandi perché consente l'adozione incrementale di Git permettendo ai diversi team di migrare i flussi di lavoro a loro piacimento.

Cos'è Git-SVN?

Lo strumento git-svn è un'interfaccia tra un repository Git locale e un repository SVN remoto. git-svn consente agli sviluppatori di scrivere codice e creare commit in locale con Git e quindi eseguirne il push a un repository SVN centrale con un comportamento in stile commit svn. Questa dovrebbe essere una procedura temporanea, ma è utile quando si deve decidere se effettuare il passaggio da SVN a Git.

git-svn è una buona opzione se non sei sicuro di passare a Git e vuoi dare ad alcuni degli sviluppatori la possibilità di esplorare i comandi Git senza impegnarsi in una migrazione completa. È la soluzione perfetta anche per la fase di formazione: invece di una transizione repentina, il team può procedere con calma usando i comandi Git locali prima di pensare ai flussi di lavoro di collaborazione.

Tieni presente che git-svn dovrebbe essere solo una fase temporanea del processo di migrazione. Poiché dipende ancora da SVN per il "backend", questo strumento non è in grado di sfruttare le funzioni Git più potenti come la creazione di branch o i flussi di lavoro di collaborazione avanzati.

Strategie di implementazione

La migrazione della base di codice è solo un aspetto dell'adozione di Git. Occorre anche considerare in che modo presentare Git alle persone dietro questa base di codice. I consulenti esterni, gli esperti Git interni e i team pilota sono le tre strategie principali per affrontare il passaggio del team di sviluppo a Git.

Consulenti Git esterni

I consulenti Git possono sostanzialmente gestire il processo di migrazione per tuo conto dietro pagamento di una tariffa nominale. In questo modo, avrai il vantaggio di disporre di un flusso di lavoro Git in grado di adattarsi perfettamente al team senza dover investire del tempo per crearlo in autonomia. Con questa soluzione, avrai inoltre a disposizione risorse di formazione avanzate per supportare l'apprendimento di Git da parte del team. Gli Atlassian Partner sono professionisti della migrazione da SVN a Git e rappresentano un'ottima risorsa per trovare un consulente Git.

D'altra parte, progettare e implementare un flusso di lavoro Git in autonomia è un ottimo modo per il team di comprendere il funzionamento interno del nuovo processo di sviluppo. In questo modo si evita il rischio che il team si ritrovi a brancolare nel buio quando il consulente se ne va.

Esperti interni di Git

Un esperto di Git è uno sviluppatore interno all'azienda che è entusiasta di iniziare a usare Git. Servirsi degli esperti di Git è una buona opzione per le aziende con una solida cultura incentrata sugli sviluppatori e con programmatori motivati che si sentono a proprio agio a provare per primi lo strumento. L'idea è consentire a uno degli ingegneri di diventare un esperto di Git in modo che possa progettare un flusso di lavoro Git su misura per la tua azienda e fungere da consulente interno quando è il momento di far passare il resto del team a Git.

Rispetto a un consulente esterno, questa soluzione presenta il vantaggio di mantenere le competenze su Git all'interno dell'azienda. Richiede tuttavia un investimento di tempo maggiore per formare l'esperto di Git, con il rischio di scegliere il flusso di lavoro Git sbagliato o di implementarlo in modo errato.

Team pilota

La terza opzione per affrontare il passaggio a Git è testare lo strumento con un team pilota. Questa soluzione è adatta se hai un team di piccole dimensioni che lavora su un progetto relativamente isolato. Oppure, ancora meglio, potresti affiancare i consulenti esterni e gli esperti interni di Git al team pilota per ottenere una combinazione vincente.

Il lato positivo di questo scenario è che rende necessaria l'approvazione di tutto il team, limitando anche il rischio di scegliere un flusso di lavoro sbagliato dal momento che tutti i membri del team possono dare il proprio contributo durante la progettazione del nuovo processo di sviluppo. In altre parole, in questo modo ci si assicura che gli eventuali pezzi mancanti vengano individuati già nelle prime fasi, a differenza di quando il nuovo flusso di lavoro viene progettato in autonomia da un consulente o da un esperto.

D'altra parte, utilizzare un team pilota significa dedicare più tempo alla formazione e alla configurazione iniziali: invece di uno sviluppatore che escogita un nuovo flusso di lavoro, c'è un intero team che potrebbe potenzialmente essere temporaneamente meno produttivo mentre è impegnato ad abituarsi al nuovo flusso di lavoro. Tuttavia, vale assolutamente la pena sopportare questi fastidi a breve termine per ottenere migliori risultati nel lungo termine.

Sicurezza e autorizzazioni

Il controllo degli accessi è un aspetto di Git che richiede di rivoluzionare la modalità di gestione della base di codice.

In SVN, di solito si memorizza l'intera base di codice in un unico repository centrale, quindi si limita l'accesso a diversi team o singole persone in base alla cartella. In Git, questo non è possibile: gli sviluppatori devono recuperare l'intero repository per poterci lavorare. In genere non è possibile recuperare un sottoinsieme del repository, come con SVN. Le autorizzazioni possono essere concesse solo a interi repository Git.

Ciò significa che devi suddividere il tuo grande repository SVN monolitico in tanti piccoli repository Git. In realtà abbiamo sperimentato questa procedura in prima persona qui in Atlassian quando il nostro team di sviluppo Jira ha effettuato la migrazione a Git. Tutti i plug-in di Jira erano archiviati in un unico repository SVN, ma dopo la migrazione, ogni plug-in è finito nel proprio repository.

Tieni presente che Git è stato progettato per integrare in modo sicuro i contributi al codice di migliaia di sviluppatori Linux indipendenti, quindi di sicuro prevede un modo per configurare qualsiasi tipo di controllo degli accessi di cui il tuo team ha bisogno. Questo, tuttavia, potrebbe rendere necessario rivedere il ciclo di compilazione.

Se ti preoccupa mantenere le dipendenze tra la nuova raccolta di repository Git, potresti trovare utile aggiungere un livello di gestione delle dipendenze oltre a Git. Tale modello prevede la memorizzazione nella cache dei progetti man mano che questi aumentano di dimensioni, consentendoti quindi di accelerare i tempi di compilazione. Nell'articolo "Git e dipendenze del progetto" è disponibile una lista degli strumenti consigliati per il livello di gestione delle dipendenze per ogni stack tecnologico.

Per gli sviluppatori


Un repository per ogni sviluppatore

Il cambiamento più grande a cui dovrai adeguarti come sviluppatore è la natura distribuita di Git. Invece di un unico repository centrale, ogni sviluppatore ha la propria copia dell'intero repository. Questo cambia radicalmente le modalità di collaborazione con i colleghi programmatori.

Invece di estrarre un repository SVN con svn checkout e ottenerne una copia di lavoro, devi clonare l'intero repository Git sul computer locale con git clone.

La collaborazione avviene spostando i branch tra i repository con git push, git fetch o git pull. La condivisione in Git avviene di solito a livello di branch, ma può essere effettuata a livello di commit, in modo simile a SVN. Tuttavia in Git, un commit rappresenta l'intero stato del progetto nel suo insieme, anziché le modifiche apportate ai file. Dato che puoi usare i branch sia in Git che in SVN, la differenza importante qui è che puoi eseguire il commit in locale con Git, senza condividere il tuo lavoro. Ciò ti consente di sperimentare più liberamente, lavorare in modo più efficace offline e velocizza quasi tutti i comandi relativi al controllo delle versioni.

Tuttavia, è importante comprendere che un repository remoto non è un collegamento diretto al repository di qualcun altro. È semplicemente un segnalibro che ti evita di dover digitare nuovamente l'URL completo ogni volta che interagisci con un repository remoto. Finché non esegui esplicitamente un pull o un push di un branch in un repository remoto, lavori in un ambiente isolato.

L'altro grande cambiamento per gli utenti di SVN è la nozione di repository "locali" e "remoti". I repository locali si trovano sul computer locale, mentre tutti gli altri repository sono chiamati repository remoti. Lo scopo principale di un repository remoto è rendere il tuo codice accessibile al resto del team, e quindi al suo interno non avviene nessuna operazione di sviluppo attivo. I repository locali risiedono sul computer locale e al loro interno si svolgono tutte le operazioni di sviluppo del software.

Non aver paura della creazione di branch o del merge

In SVN, si esegue il commit del codice modificando i file nella propria copia di lavoro ed eseguendo quindi svn commit per inviare il codice al repository centrale. Tutti gli altri sviluppatori possono quindi eseguire un pull di queste modifiche nelle proprie copie di lavoro con svn update. I branch di SVN sono generalmente riservati agli elementi di grandi dimensioni e di lunga esecuzione di un progetto, perché il merge è una procedura pericolosa che potrebbe danneggiare il progetto.

Il flusso di lavoro di sviluppo di base di Git è molto diverso. Invece di essere legato a un'unica linea di sviluppo (ad esempio, trunk/), il ciclo di vita ruota attorno alla creazione di branch e al merge.

Quando vuoi iniziare a lavorare in Git, crei ed estrai un nuovo branch con git checkout -b . Con questo comando ottieni una linea di sviluppo dedicata in cui puoi scrivere codice senza preoccuparti di influire sul lavoro degli altri membri del team. Se danneggi qualcosa in modo irreparabile, basta eliminare il branch con il comando git branch -d . Se invece compili qualcosa di utile, presenti una richiesta di pull chiedendo di eseguirne il merge nel branch principale.

Potenziali flussi di lavoro Git

Quando si sceglie un flusso di lavoro Git è importante tenere presenti le esigenze del team. Un flusso di lavoro semplice può massimizzare la velocità e la flessibilità dello sviluppo, mentre un flusso di lavoro più complesso può garantire maggiore coerenza e controllo del lavoro in corso. Puoi adattare e combinare gli approcci generali elencati di seguito in base alle esigenze e ai diversi ruoli del tuo team. Ad esempio, lo sviluppatore principale potrebbe utilizzare i branch di funzioni, mentre i collaboratori esterni lavorano da un fork.

  • Un flusso di lavoro centralizzato è l'opzione più simile ai processi SVN più comuni, quindi è un buon punto di partenza.
  • Partendo da questa idea, l'utilizzo di un flusso di lavoro del branch di funzioni consente agli sviluppatori di mantenere isolato il lavoro in corso e protetti i branch condivisi importanti. I branch di funzioni costituiscono anche la base per la gestione delle modifiche tramite pull request.
  • Un flusso di lavoro Gitflow è un'estensione più formale e strutturata della creazione di branch di funzioni, il che la rende un'ottima opzione per i team di maggiori dimensioni con cicli di rilascio ben definiti.
  • Infine, prendi in considerazione il flusso di lavoro di fork se hai bisogno del massimo isolamento e controllo sulle modifiche o se vi sono molti sviluppatori che contribuiscono a un repository.

Ma se vuoi davvero ottenere il massimo da Git come team di professionisti, dovresti prendere in considerazione il flusso di lavoro del branch di funzioni. Si tratta di un flusso di lavoro realmente distribuito e assolutamente sicuro, incredibilmente scalabile e Agile per antonomasia.

Conclusione


La transizione del team a Git può presentare delle difficoltà, ma non deve essere obbligatoriamente un compito arduo. In questo articolo sono state descritte alcune delle opzioni più comuni per la migrazione della base di codice esistente, l'implementazione di Git nei team di sviluppo e la gestione della sicurezza e delle autorizzazioni. Sono state inoltre presentate le maggiori sfide a cui gli sviluppatori dovrebbero essere preparati durante il processo di migrazione.

Spero che tu ora abbia una solida base per introdurre lo sviluppo distribuito nella tua azienda, indipendentemente dalle sue dimensioni o dalle pratiche di sviluppo attuali.


Condividi l'articolo
Argomento successivo

Letture consigliate

Aggiungi ai preferiti queste risorse per ricevere informazioni sui tipi di team DevOps e aggiornamenti continui su DevOps in Atlassian.

Le persone collaborano utilizzando una parete piena di strumenti

Blog di Bitbucket

Illustrazione su Devops

Percorso di apprendimento DevOps

Funzione Demo Den per demo con esperti Atlassian

Come Bitbucket Cloud funziona con Atlassian Open DevOps

Iscriviti alla nostra newsletter DevOps

Thank you for signing up