Introduzione al sistema di controllo della versione

Se sei un programmatore o uno sviluppatore e lavori su applicazioni software o qualsiasi sito Web, avrai sicuramente bisogno di un sistema di controllo delle versioni per tenere traccia delle modifiche. Il sistema di controllo della versione è anche denominato SCM (Ssource Code Management ) o RCS (Revision Control SSistema).

Il controllo della versione è un metodo o una categoria di strumenti software che aiuta a tenere traccia delle modifiche nel codice in modo che, se qualcosa va storto, possiamo fare confronti tra diverse versioni del codice e ripristinare facilmente le versioni precedenti. È molto utile quando più sviluppatori lavorano continuamente o modificano il codice sorgente.

Vantaggi del sistema di controllo della versione

Utilizzando VCS, i programmatori possono rivedere la cronologia del progetto per scoprire i seguenti dettagli:

• Quali modifiche sono state apportate al codice?
• Chi ha apportato le modifiche al codice?
• Quando sono state apportate le modifiche al codice?
• Perché erano necessari cambiamenti?

Ecco una semplice illustrazione grafica che ti dà un'idea di come funziona effettivamente VCS.

Come funziona VCS

Nella figura sopra, la prima riga con le palline azzurre rappresenta il ramo principale che è il ramo principale del codice sorgente. Quindi v0.1 e v0.2 sono le molteplici versioni create per scattare una sorta di istantanea dell'intero codice sorgente. Abbiamo creato più rami dal ramo principale come il ramo di rilascio, sviluppo e hotfix in base ai requisiti. Più sviluppatori possono lavorare sullo stesso progetto creando rami diversi e alla fine unendoli al ramo principale.

Tipi di VCS

Esistono due tipi di VCS, vale a dire:

1. Sistema di controllo della versione centralizzato (CVCS),
2. Sistema di controllo della versione distribuito (DVCS).

Innanzitutto, diamo una rapida occhiata al sistema di controllo della versione centralizzato.

Sistema di controllo della versione centralizzato

Il sistema di controllo della versione centralizzato funziona su una relazione client-server. Il server avrà tutte le informazioni che vengono trasferite al client. Si può dire che è una sorta di repository condiviso che fornisce il codice più recente agli sviluppatori. Pertanto gli sviluppatori lavoreranno ogni volta sulla copia principale. È semplice: devi estrarre l'ultima copia del codice, lavorarci sopra (applicare le modifiche) e quindi reinserire il codice nel repository.

Lo svantaggio principale del VCS centralizzato è che si tratta di un singolo punto di errore. Se il server centrale non funziona, non è possibile utilizzarlo. Se stai eseguendo il commit remoto, ci vorrà anche del tempo. Avrai bisogno della connettività Internet per confermare eventuali modifiche.

Esempi:

• Open source -> Sistema di versioni concorrenti (CVS), Subversion (SVN).
• Proprietario -> TeamCity, Vault, IBM Configuration Management Version Control (CMVC).

Sistema di controllo della versione distribuito

Il sistema di controllo della versione distribuito ha un repository centralizzato e tutti gli sviluppatori hanno una copia locale del repository.
Gli sviluppatori possono lavorare sulla propria copia locale contemporaneamente. Non richiedono la connettività Internet per funzionare sul codice. Possono fare tutto nel codice tranne spingere e tirare. Anche se il server centrale dovesse guastarsi, non ci sarà alcun impatto a causa del repository locale.

Esempi:

• Open source: Git, Mercurial, Bazaar.
• Proprietario: Visual Studio Team Services, Plastic SCM.

Differenza tra architettura SVN (VCS centralizzato) e GIT (VCS distribuito).

Il grafico seguente spiega la differenza tra CVCS e DVCS.

Differenza tra SVN e GIT

Dalla figura sopra, possiamo facilmente riconoscere che in SVN (VCS centralizzato) abbiamo solo un repository centrale ma in GIT (VCS distribuito) abbiamo un repository centrale oltre a un repository locale.

Spero che tu abbia avuto un'idea di base su VCS e sui suoi tipi. Nei prossimi giorni pubblicheremo altre guide relative a VCS. Rimani sintonizzato!

Informazioni sull'autore:

Dhruv Tiwari è un ingegnere DevOps che ama automatizzare le cose, lavorare con Linux su larga scala e sogna il giorno in cui i sistemi saranno abbastanza intelligenti da non dover mai accedere a una macchina Linux. Viaggio di CI/CD dal codice sorgente alla distribuzione del codice fino alla produzione.