Un'introduzione al controllo della versione e Git

Hai familiarità con Google Documenti? Bene, se lo sei, è lecito ritenere che tu sia a conoscenza della piccola scheda "Cronologia delle versioni" che consente agli autori e alle persone coinvolte di controllare e tenere traccia di tutte le modifiche apportate nel documento. in un dato momento. Uno strumento utile, vero?

Immagina ora invece di un foglio pieno di paragrafi, ci sono file pieni di centinaia di righe di codici. E a differenza di un singolo documento, ci sono tonnellate di file diversi, costantemente aggiornati.

In uno scenario come questo, in cui ci sono migliaia di righe di codici in gioco e il risultato finale, ovvero l'app mobile è ciò da cui dipende il futuro di un'azienda, diventa ancora più importante avere un software che tenga sotto controllo tutte le modifiche fatto nei file di codice.

È qui che entra in gioco un software di controllo della versione.

Perché il controllo della versione è importante nello sviluppo di software

Come suggerisce il nome, un software di controllo della versione consente agli sviluppatori di app mobili di tenere traccia delle diverse versioni del ciclo di sviluppo del software e di apportarvi modifiche. Questa capacità di tenere traccia di tutte le modifiche che si verificano nel codice e quindi l'opzione di annullare le modifiche è ciò che rende Controllo versione una parte importante del processo di un'azienda di sviluppo di app mobili che coinvolge più sviluppatori.

Ora, quando si tratta di Version Control, ci sono un certo numero di software disponibili sul mercato al momento attuale. Diamo un'occhiata ad alcuni di loro -

Software disponibile per il controllo della versione

Sebbene nel suo sondaggio GitLab, il leader del software distribuito abbia rilevato che il 98% degli utenti utilizza gli strumenti open source Git e oltre il 92% degli sviluppatori utilizza Git come linguaggio di controllo della versione nel processo di sviluppo dell'app, ci sono un certo numero di dei motivi per cui gli sviluppatori potrebbero considerare l'alternativa Git. Alcuni di questi motivi possono variare da: la struttura dei prezzi di GitHub e il fatto che Github viene lanciato sia su iOS che su Android, un'avversione per Octocat o un semplice livello di comodità con il linguaggio di controllo della versione che non è Git.

Qualunque sia la tua ragione, ecco l'alternativa di Git per il controllo della versione:

Ora, anche quando ci sono una serie di alternative disponibili per Version Control e Appinventiv, abbiamo un'esperienza diretta nel lavorare su molte di esse, a causa delle diverse esigenze dei clienti, siamo davvero parziali nei confronti di Git. Lascia che ti dica perché.

Perché Appinventiv usa Git per il controllo della versione

1. Per la sua velocità fulminea

Tra tutti i software di controllo della versione sul mercato, la velocità con cui funzionano gli elementi Git log e Commit è ineguagliabile. E quando il tuo team di sviluppatori lavora su una piattaforma, diventa assolutamente necessario che il software sia veloce.

2. Per la possibilità di lavorare offline

Quando lavori su un software che si basa su Internet, può essere rischioso quando sei in movimento e perdi la connessione con il repository centrale. Ma questo non è il caso di Git. Con Git, puoi eseguire quasi tutte le attività sul tuo computer locale: eseguire il commit, sfogliare la cronologia del progetto, creare branch o unire.

3. Per il sollievo dall'annullamento

Git viene fornito con un comando "annulla" che ti consente di correggere e ripristinare l'intero commit. In effetti, ti dà anche la possibilità di ripristinare il commit "cancellato" tramite la sua opzione Reflog.

4. Per il backup

Quando il team lavora su Git, ogni singolo clone che il team ha sul proprio computer viene fornito con un backup utilizzabile. In aggiunta a ciò, quasi ogni singola azione Git aggiunge solo i dati e non li elimina.

5. Per prendere impegni utili

Quando il team dei nostri sviluppatori esegue una serie di modifiche non correlate, prendendo alcune funzionalità da A, apportando alcune correzioni di bug in un'altra, può essere molto difficile per gli altri membri del team dare un senso a ciò che è successo e può essere difficile per loro tornare indietro Funzionalità di A se sta causando problemi.

Git risolve questo pasticcio creando un commit granulare. Attraverso il suo concetto di "area di staging", si può facilmente scoprire quali modifiche sarebbero incluse nel prossimo commit, anche quando si è costretti a guardare le singole righe.

Quindi questi erano i cinque motivi principali per cui utilizziamo Git qui su Appinventiv. Ora che abbiamo esaminato il perché, è tempo di guardare al Come. Come incorporiamo Git nel nostro processo di controllo della versione.

Andiamo a questo ora.

Processo di controllo della versione quando si utilizza Git

Creazione repository

Lo scopo di Git è gestire un insieme di file, alias Project. Per fare ciò, Git salva tutte le informazioni nella struttura dei dati nota come Repository. Un repository è costituito dai codici sorgente dell'app, dalle risorse e dai set di dati. Fondamentalmente, ha tutto ciò che definisce il progetto dell'app.

Ora, ci sono due modi per ottenere un repository su Git. Puoi utilizzare una directory locale e convertirla in un repository Git utilizzando la riga di comando oppure puoi copiare un repository Git già caricato nel tuo.

Quando crei un repository, di solito ottieni due opzioni: Pubblico e Privato. Il repository pubblico è quello che può essere visualizzato da altri sviluppatori che usano Git e quello privato, d'altra parte, è quello che può essere visualizzato solo da poche persone.

Ramificazione

Accanto a Creazione repository c'è Branching. In un'azienda come Appinventiv, in cui in un dato momento oltre 15-20 sviluppatori stanno lavorando a un progetto, non è raro che gli sviluppatori condividano lo stesso codice sorgente e ci lavorino. Quello che succede è che poiché alcuni sviluppatori sono impegnati a risolvere i problemi, altri potrebbero implementare alcune funzionalità.

In una situazione come questa, abbiamo bisogno di un sistema che renda facile gestire diverse versioni di codice nella stessa base di codice.

È qui che entra in gioco Gitflow. Gitflow è un framework utilizzato per ramificare in modo sistematico ed efficiente.

Prima di procedere con il funzionamento del processo Branching su Gitflow, consentitemi di spiegare il concetto con un esempio.

Supponiamo che ci siano 5 sviluppatori nel tuo team e stiano lavorando allo sviluppo di un'app simile a Instagram. Ora le singole funzionalità dell'app come supponiamo Feed e Notifiche sono indicate come Modulo 1, Modulo 2 e così via. Ora questi diversi moduli sono rami di sviluppo, che dopo aver lavorato vengono uniti al ramo padre o Master.

Nel momento in cui uno sviluppatore aggiunge un ramo, crea una linea di sviluppo indipendente, che isola il proprio lavoro da quello dei membri del proprio team. I diversi rami vengono quindi uniti nel ramo padre.

Il branching è il metodo che consente ai membri del team di identificare quali cambiamenti dovrebbero aspettarsi ed è ciò che rende facile il backtracking.

Nei nostri progetti, di solito manteniamo questi rami –

• Ramo maestro
• Ramo di sviluppo
• Ramo di funzionalità
• Ramo di rilascio
• Correzioni rapide e correzioni di bug

Commettere

Le modifiche apportate da uno sviluppatore al singolo file sono note come Commit. Le modifiche o il commit vengono aggiunti nel repository locale e non nel server. Successivamente, i nostri sviluppatori seguono l'abitudine di scrivere un messaggio di commit, in cui viene pubblicata la descrizione del commit (modifiche apportate al file), in modo che anche gli altri sviluppatori conoscano i dettagli delle modifiche apportate al file.

Spingere

Quando esegui il commit nel repository Git locale, ciò che accade dopo è che le modifiche vengono quindi inviate al server, noto come Push .

È abbastanza facile inviare la cronologia dei commit al server quando sei l'unico a lavorare su un file, ma nel caso ci siano anche altri sviluppatori coinvolti nel processo, dovrai estrarre le modifiche prima di poter inviare il tuo set di impegnarsi con Git.

Successivamente, esamineremo ciò che viene fatto nel passaggio Pull Change.

Tirare la richiesta

Quando più di uno sviluppatore sta lavorando sullo stesso file, ciò che accade è che alcuni commit potrebbero essere inviati sul server dall'altro sviluppatore prima di inviarli. E quando ciò accade, si verifica il conflitto (ne parleremo più avanti).

Per evitare di caricare la stessa codebase due volte sul server, gli sviluppatori prima estraggono le modifiche dal repository e si assicurano che i codici siano diversi. Ora, generalmente, quando due o più sviluppatori lavorano sullo stesso file e inviano il loro commit sul server, arriva l'opzione "Unisci".

Parliamo di Merge dopo.

Unisci

Unisci è il passaggio in cui gli sviluppatori raggruppano tutti i rami prima l'uno con l'altro e poi con il ramo principale o principale.

Ogni volta che una consegna immette un comando Push, ottiene un'opzione Unisci, che quindi chiede loro il ramo con cui desiderano unire il commit.

Ora nella fase di fusione, il verificarsi di Conflitto è molto comune. Il conflitto di solito si verifica quando i due rami che si intende unire vengono modificati nella stessa parte nello stesso file. Quello che succede qui è che Git non è in grado di capire quale versione dovrebbe essere utilizzata.

Quando si verifica questo problema di conflitto, Git offre due soluzioni: automatica e manuale.

Come dice il nome, uno è dove Git scopre il problema stesso e in quest'ultimo gli sviluppatori devono farlo manualmente. In Appinventiv, ci concentriamo sulla risoluzione manuale dei conflitti poiché elimina anche le minime possibilità che si verifichino bug.

Mentre utilizziamo Git per eseguire il controllo della versione del nostro processo di sviluppo delle app, ciò che accade contemporaneamente è il rilevamento dei problemi.

Poiché siamo un grande seguace di Agile e ci fidiamo di Agile per il nostro processo di sviluppo di app mobili , comprendiamo l'importanza di gestire più processi di sviluppo contemporaneamente. E con la funzione di rilevamento dei problemi, diventa molto più facile per i tester tenere sotto controllo in tempo reale il codice scritto e inviato al server Git.

Utilizziamo la scheda ZenHub per monitorare il flusso di lavoro in ogni repository. La bacheca ci consente di tenere traccia della priorità della modifica suggerita e aiuta anche gli sviluppatori ad aggiornare i loro commenti sulla bacheca in tempo reale.