Introduzione al sistema di controllo versione GIT

Git è uno dei termini più comuni ascoltati tra i programmatori negli ultimi quattro-cinque anni. Presenterò qui alcune informazioni su questo strumento e sul perché è così popolare tra i programmatori. In questo argomento, impareremo a conoscere il sistema di controllo versione GIT.

Che cos'è e perché controller di versione?

Linus Torvalds che ha avviato il kernel Linux è la persona che ha creato questo software per mantenere e tenere traccia delle diverse versioni del codice sorgente tra i programmatori.

Scenario 1

Immagina un team di cinque membri che stanno lavorando sul codice sorgente principale migliorandone le diverse funzionalità. Basti pensare come possono lavorare sullo stesso codice sorgente senza confusione sulle reciproche modifiche? Ognuno deve sapere cosa stanno facendo gli altri quattro e non dovrebbe esserci negligenza. E entro la fine dell'orario di lavoro, devono trascorrere un po 'di tempo a coordinarsi a vicenda per mantenere finalmente un codice sorgente. Sembra molto frenetico e sicuramente l'intervento manuale nel mantenimento del codice sorgente è più rischioso. Quindi, per aiutare o dire per automatizzare tutte queste versioni su cui lavorano tutti e cinque i programmatori, abbiamo bisogno di un controller di versione scritto correttamente e GIT è uno di questi. Esiste un termine per i passaggi precedenti e si chiama Gestione del codice sorgente o Software Configuration Management (SCM).

Scenario n. 2

Consideriamo ora un altro scenario in cui aiuta l'automazione del controller di versione. Abbiamo scritto la prima versione del codice e il client ha approvato l'installazione sulla versione di produzione. Questa è la versione 1.0. Ora, dopo alcuni mesi, il cliente offre un lavoro di miglioramento e si lavora su scritti precedentemente per sviluppare la versione 1.1 e inviarla al cliente. Ma il cliente suggerisce un approccio diverso e questa versione 1.1 non ti è utile secondo il nuovo approccio del cliente. Quindi lo scarti e lavori alla versione 1.2 che viene inviata e approvata. E così via continui a lavorare nello sviluppo di versioni diverse. Ma non pensi che salvare manualmente tutte le versioni da qualche parte e mantenere il codice sorgente non sia disordinato? Ad un certo punto, potresti dover fare riferimento alla versione 1.1 che hai scartato e che non ti è utile.

Pertanto, per mantenere versioni diverse del codice scritto da uno o più programmatori, utilizziamo i controller di versione.

Diversi tipi di controller di versione

Esistono diversi tipi di strumenti disponibili e di seguito alcuni di essi

  1. Subversion - Dal momento che sviluppato da Apache, ampiamente utilizzato dai venditori Apache.
  2. Idiota
  3. Bazar
  4. mutevole

Fondamentalmente ci sono due tipi di metodologie del sistema di controllo della versione su cui lavorano gli strumenti di cui sopra. Loro sono

Centralized Version Control System (CVCS) Distributed Version Control System (DVCS)

1. CVCS

Qui il codice scritto è archiviato nel repository centralizzato o nel server centralizzato. Nessuna copia funzionante disponibile sui computer locali, il che rappresenta un enorme svantaggio in caso di errore del server. Ho bisogno di avere una connessione server attiva sempre per lavorare sul repository. SVN utilizza questo sistema di controllo

2. DVCS

Anche qui abbiamo il codice sorgente sul server ma insieme a quello, lo abbiamo come copia locale su macchine funzionanti. Pertanto, anche se si verifica un errore a livello di server, è possibile eseguire il mirroring della copia di lavoro locale sul server al momento del ripristino. Questa disponibilità di copia di lavoro locale su ogni macchina responsabile del termine "non registrato" in DVCS. Git, Mercurial utilizza un sistema di controllo versione distribuito

Git utilizza il concetto di branching o più tecnicamente chiamato TBD di sviluppo basato su trunk. Ciò che in realtà significa è che possiamo creare più rami dal master e su questi rami, i programmatori possono lavorare e impegnare le loro modifiche su questi rami e ognuno di questi commit viene tracciato. E una volta che i clienti approvano, possiamo unire tutti i rami al codice principale nella produzione. In questo modo non influiscono direttamente sul codice sorgente principale. Lavorare direttamente sul codice sorgente principale sarà più rischioso e deve essere evitato. Siamo in grado di lavorare su filiali ed eseguire vari scenari di test e una volta che la versione finale è stabilizzata e approvata, possiamo lavorare sulla fusione del master che riduce il rischio di un importo significativo.

Git è in realtà gratuito e per gli utenti Mac, è disponibile per impostazione predefinita. In Linux, possiamo installare git e per Windows abbiamo qualcosa, Git Bash. Esistono due fonti di repository più popolari in cui possiamo lavorare con Git e sono Git Hub e Bit Bucket e l'organizzazione che sceglie di basarsi sulle sue preferenze.

Vantaggi del sistema di controllo versione GIT

  • Supporta entrambe le forme di sviluppo legacy che è una forma di sviluppo lineare e anche non lineare
  • Poiché distribuito in natura, meno preoccupazione per gli errori del server single point. Possiamo sempre eseguire il mirroring del codice dal repository locale al server.
  • Possiamo anche implementare un livello di sicurezza su git che può assegnare restrizioni di accesso in commit pull and push.
  • Può funzionare su più piattaforme come Mac, Linux, Windows, ecc
  • Assolutamente gratuito e open-source
  • Efficiente e veloce grazie alla natura distribuita
  • Tracciamento chiaro di commit, aggiornamenti, ripristini, versioni, push e pull
  • Fornisce GitBash per Windows che è facile da usare.
  • Ci sono anche diverse GUI disponibili per lavorare su GIT
  • Non richiede una connessione di rete attiva sempre dalla disponibilità del repository locale.

Lavorare con Git

  • Creare il ramo di lavoro dal master di origine o da un altro ramo in base al requisito
  • Clonare il ramo su local usando GitBash per Windows
  • Lavora sul ramo ed esegui modifiche o aggiunte di componenti
  • Conferma le modifiche e fai riferimento a commit tracker
  • Se ritieni che il commit non sia necessario, puoi ripristinare il commit a quello precedente
  • Se più programmatori lavorano sullo stesso ramo, è necessario aggiornare il repository locale prima di inviare le modifiche. Quindi esegui PULL
  • Ora sarai in grado di eseguire il PUSH
  • Una volta effettuata la revisione e l'approvazione del codice nella tua filiale, possiamo spostare il codice in produzione per risposta o in qualunque modo venga utilizzato dall'organizzazione.
  • Unisci il ramo al Master in modo da avere un codice aggiornato al suo interno.

Git è il sistema di controllo della versione distribuita più comunemente usato per la sua natura distribuita, nessun singolo punto di errore ed è open source. Puoi provare a usarlo usando il codice di esempio in GitHub e GitBash in Windows PC poiché i comandi git sono semplici e facilmente disponibili online.

Articoli consigliati

Questa è una guida al sistema di controllo versione GIT. Qui discutiamo i diversi tipi di controller di versione con vantaggi e funzionalità. Puoi anche leggere il seguente articolo per saperne di più-

  1. Comandi GIT
  2. Introduzione a GIT
  3. Git Alternative
  4. Che cos'è Git?
  5. Versioni del tableau
  6. Git Origin Master
  7. Cos'è Hub?
  8. Tre fasi del ciclo di vita di Git con il flusso di lavoro
  9. Come usare GIT Cherry-pick con Esempio?

Categoria: