Git Best Practices – Come ottenere il massimo da (g)it

Pull, Fetch, Commit, Push, Merge, Rebase: questi termini sono già riusciti a farsi strada nella tua vita di tutti i giorni? Quando Linus Torvalds ha creato la sua prima versione di Git, lo ha descritto come "lo stupido tracker di contenuti". Avanti veloce fino ad oggi, questo software open source gratuito è ora il sistema di controllo delle versioni più popolare.

Cos'è Git?

Non vorresti poter tornare indietro nel tempo a volte, così avresti potuto prendere una decisione migliore o fare le cose in modo diverso? Bene, nel mondo della tecnologia e della codifica, puoi farlo. Git è un sistema di controllo della versione distribuito open source che salva le versioni del tuo prezioso codice ogni volta che apporti modifiche/aggiunte ad esso. Quindi, ogni volta che devi eseguire il rollback, scegli semplicemente la versione funzionante e voilà! Git consente inoltre di lavorare senza interruzioni all'interno dei team poiché gli sviluppatori lavorano contemporaneamente sulle singole copie locali. Ogni modifica di ogni membro del team viene tracciata, mantenendo così la trasparenza in un flusso organizzato. Allora, cos'è GitHub? GitHub è un servizio di hosting di repository per Git che ha anche molte funzionalità per ottimizzare il tuo sistema di controllo della versione.
Flusso di lavoro Git

Ogni organizzazione ha un flusso di lavoro Git diverso. Il flusso di lavoro Git di maggior successo è quello che offre al tuo team spazio sufficiente per la produttività massimizzando l'efficacia dei loro risultati. Dovrebbe essere scalabile con le dimensioni del tuo team e dovrebbe ridurre al minimo il numero di conflitti che possono sorgere. Il flusso di lavoro Git centralizzato è la base su cui sono costruiti altri flussi di lavoro Git, come il flusso di lavoro di ramificazione delle funzionalità, il flusso di lavoro di fork, il flusso di lavoro Gitflow, ecc. Un flusso di lavoro dovrebbe essere pianificato per migliorare e integrare la cultura della tua organizzazione. Ad ogni Team, il proprio flusso di lavoro Git.

Perché usare Git?

1. L'architettura distribuita

A differenza dei sistemi di controllo delle versioni centralizzati che obbligano gli sviluppatori ad accedere al singolo repository centrale per poter "estrarre" e confermare le modifiche ai singoli file, Git segue un approccio distribuito. Nell'architettura distribuita, ogni sviluppatore ha le proprie copie locali dell'intero repository centrale, che gli consente di lavorare offline, accedere alla cronologia completa delle revisioni e semplificare la diramazione e l'unione.

2. Prestazioni potenti

Branching, fusione, commit, ecc. sono davvero facili e veloci con il flusso di lavoro Git grazie ai suoi algoritmi intelligenti di conoscenza approfondita che comprendono i modelli di accesso al T.

3. È sicuro

Git memorizza tutto il contenuto del file, comprese le relazioni tra versioni e directory, utilizzando crittograficamente un SHA1 come algoritmo di hashtag. Qualsiasi modifica del codice accidentale o dannoso è completamente tracciabile.

4. Open-source

Essendo open-source, Git è gratuito, gode di un buon supporto da parte della comunità, continuamente controllato per la qualità ed è supportato da un sacco di documentazione e tutorial per gli studenti.

5. Rilasci più veloci

Lo sviluppo distribuito di Git e la facile ramificazione e la creazione di nuove funzionalità incoraggiano gli sviluppatori ad apportare modifiche più frequenti in un flusso di lavoro agile

Best practice per Git

• Nuovo progetto? Nuovo deposito

Ha solo senso organizzativo creare un nuovo repository per ogni nuovo progetto su cui vuoi iniziare a lavorare. Una volta fatto, invialo a GitHub.

• Nuova caratteristica? Diramarsi

Ora che hai creato un nuovo progetto, che ne dici di creare alcune nuove funzionalità di Git? Git Branching ti consente di creare e gestire un flusso di lavoro organizzato all'interno del tuo repository. Ai membri del team possono essere assegnati vari rami Git che consentono loro di lavorare contemporaneamente ma in modo isolato. Dai sempre un significato al tuo ramo git in modo che gli altri sappiano esattamente su cosa stai lavorando.

• Inizia la tua giornata rimanendo aggiornato

"Rebase" sempre o ottieni la versione più recente e più aggiornata del tuo progetto (master) prima di iniziare a lavorare sulle funzionalità che hai creato/assegnato a te. Non vuoi apportare modifiche a file obsoleti.

• Avere punti di controllo periodici

Non salvare i tuoi commit per un grande cambiamento. "Impegna" piccole modifiche frequentemente in modo che il codice sia più facile da comprendere per te e i membri del tuo team. Anche il ripristino e il monitoraggio sono più facili quando le modifiche sono piccole e frequenti.

• Metti da parte il tuo lavoro

Spesso potresti imbatterti in situazioni in cui stai lavorando su un ramo Git ma ti sei improvvisamente ricordato che hai bisogno di lavorare su un altro ramo ma non vuoi "commettere" quei cambiamenti a metà. Oppure potresti semplicemente volere una copia di lavoro pulita. "git stash" in soccorso. Stashing ti consente di salvare le modifiche non completate in una pila a cui puoi tornare in qualsiasi momento!

• Schiacciarli si impegna

Avere meno commit nella tua cronologia rende più facile monitorare e tenere traccia di dove hai sbagliato. Se vuoi mantenere una cronologia dei commit pulita, questo è per te. Schiaccia e unisci tutti i tuoi commit in uno solo quando la richiesta pull viene unita.

• Invia messaggi

Fornisci sempre informazioni chiare e comprensibili nel tuo messaggio di commit. Inizia scrivendo un breve riepilogo delle modifiche, lascia una riga vuota e seguila con una descrizione dettagliata della modifica. Non vuoi che la tua cronologia di commit finisca per assomigliare a questa :/

• Non cambiare la storia

Dopo aver eseguito il commit delle modifiche nel repository, non tornare indietro e modificare la cronologia. Sebbene Git ti permetta di farlo e riscrivere la storia pubblica, non è mai una buona pratica farlo. Sia per te che per la tua squadra.

• Applicare una patch Git

A volte quando non hai accesso in scrittura al repository ma vuoi comunque correggere un bug, applica una patch Git. Ricorda sempre di clonare il repository principale e quindi creare un ramo per la nuova funzionalità. Quando hai il tuo file .patch pronto, visualizzalo sempre in anteprima ed esegui un test per verificare la presenza di errori. Git applica la patch (git apply -R percorso/file.patch) una volta fatto. NON dimenticare di testare e controllare

• Non lasciare le richieste Pull troppo a lungo

Una richiesta "pull" aperta può creare conflitti prima o poi. Non lasciarli incustoditi per più di 2 giorni. Rivedi sempre il codice e, se va bene per la distribuzione, unisci la richiesta pull. Ciò non solo velocizzerà il processo di spedizione, ma eviterà anche conflitti di codice.

• Organizzazione migliore con gli strumenti di gestione dei progetti

Se hai utilizzato strumenti di gestione dei progetti come Redmine, è una buona pratica utilizzarlo insieme a Git per essere in grado di gestire meglio più membri del team e le loro attività. Creare i tuoi rami Git con l'attività Redmine come nome è una delle migliori pratiche Git in quanto consente una migliore trasparenza e organizzazione.

• GitLab CI/CD

L'utilizzo di uno strumento di integrazione continua/distribuzione continua come questo consente di testare e verificare la presenza di bug ed errori e garantisce la compatibilità con gli standard del codice. Questi processi vengono eseguiti dopo che il codice è stato inviato al server di staging.