TortoiseGit o "Git Tortoise" è un'interfaccia grafica gratuita per il software di gestione delle versioni Git in ambiente Windows. La licenza è quella della General Public Licence (GNU). "Git Tortoise" è implementato come estensione della shell ed è integrato in Windows Explorer. Può essere utilizzato indipendentemente da un ambiente di sviluppo integrato. Le icone rappresentano i rispettivi stati, come versioned, unchanged, modified o ignored. L'interazione principale avviene tramite il menu contestuale. In esso vengono eseguite varie azioni come commit, push o pull e vengono aperte le finestre di dialogo di TortoiseGit. Il software ha come compiti principali il controllo delle versioni, delle revisioni e delle fonti. Tecnicamente, "Git Tortoise" è basato su TortoiseSVN, migliorato con aspetti specifici di Git.

SVN utilizza un singolo repository centralizzato come interfaccia di comunicazione per gli sviluppatori, mentre la collaborazione avviene tramite i changeset. I changeset vengono scambiati tra le copie di lavoro degli sviluppatori e il repository centrale. Questa è la differenza più importante rispetto al modello di collaborazione distribuita di Git, dove ogni sviluppatore riceve la propria copia del repository con la propria cronologia locale e la struttura dei rami. Questo permette di condividere interi rami (invece di una serie di commit consecutivi o di singoli changeset) tra i repository. Il comando "Git Remote" fa parte di un ampio sistema di sincronizzazione delle modifiche. Git Remote" può essere usato per creare, recuperare o eliminare una connessione ad altri repository. Gli inserimenti tramite "Git Remote" vengono utilizzati insieme ai comandi "Git Fetch", "Git Push" e "Git Pull". Il comando "Git Fetch" scarica i commit, i file e i riferimenti da un repository remoto al repository locale per vedere su cosa stanno lavorando gli altri. Visualizzando i progressi nella cronologia centrale senza influenzare il lavoro di sviluppo locale. Il contenuto recuperato deve essere esplicitamente controllato con il comando "Git Checkout" per poter rivedere in sicurezza i commit prima di integrarli nel repository locale. Il comando "Git Push" è usato per caricare contenuti da un repository locale a un repository remoto. Si usa il comando "Git Push" per trasferire i commit dal repository locale a un repository remoto. La controparte è il comando "Git Fetch", che importa i commit nei rami locali. È possibile usare "Git Push" per esportare i commit nei rami remoti. I rami remoti sono configurati con il comando "Git Remote". Poiché c'è il rischio di sovrascrivere le modifiche quando si esegue il push con "Git Push", è necessario fare attenzione. Il comando "Git Pull" è necessario per scaricare contenuti da un repository remoto. Questo aggiornerà immediatamente il repository locale in modo che il contenuto corrisponda. La fusione delle modifiche a monte con il repository locale è spesso richiesta nei flussi di lavoro di collaborazione basati su Git. Il comando "Git Pull" è in realtà una combinazione di comandi "Git Fetch" seguita da "Git Merge". "Git Pull" esegue prima un "Git Fetch" che include il ramo locale e punta all'HEAD. Non appena il contenuto è stato scaricato, "Git Pull" avvia un flusso di lavoro di fusione. Viene creato un nuovo commit di unione e HEAD viene aggiornato per fare riferimento al nuovo commit. Questi e altri comandi e strumenti Git possono essere appresi in un corso Git.

Quando si lavora in Git, il termine "salvare" è più sfumato rispetto a un programma di elaborazione testi e comprende un insieme di file e directory. Salvare è un sinonimo del termine Git "commit" - per salvare è "commit". Il comando Git "Git Commit" può essere usato per catturare un'istantanea delle modifiche attualmente distribuite al progetto. Tali istantanee del comitato sono considerate versioni sicure, poiché Git apporta modifiche solo su istruzione esplicita. Prima del comando "Git Commit", è necessario il comando "Git Add" per salvare le modifiche in un commit, per promuoverle al progetto nell'ambiente di staging o per "metterle in scena". Di conseguenza, i comandi Git "Git Commit" in combinazione con il comando "Git Add" sono tra i più utilizzati e costituiscono il flusso di lavoro Git di base. A questi segue il comando "Git Status" per recuperare lo stato della directory di lavoro e dell'ambiente di staging. Il comando "Git Stash", invece, fa sì che le modifiche alla copia di lavoro vengano temporaneamente rimandate (o accantonate). Questo permette al programmatore di concentrarsi su altri compiti e di applicare le modifiche in un secondo momento. Questo è pratico se il programmatore è nel bel mezzo di una modifica del codice, non è ancora pronto per il commit e deve continuare a lavorare rapidamente su qualcosa di completamente diverso.

Un breve tutorial su Git spiega come funziona Git:

• Creare un progetto "repository" con uno strumento di hosting Git come Bitbucket.
• copiare o clonare il repository nel sistema locale
• Aggiungere un file al repository locale ed eseguire un "commit" per "salvare" le modifiche.
• Spostare le modifiche al ramo master tramite "Push".
• apportare una modifica al file con uno strumento di hosting Git ed eseguire il commit
• eseguire un "pull" per applicare le modifiche al sistema locale
• Creare un "ramo Git" (una versione Git), apportare una modifica e fare il commit su di esso
• Aprire una "richiesta di pull" (proposte di modifica per il ramo master)
• Eseguire un "merge" delle modifiche nel ramo master

L'introduzione a Git, i comandi Git e l'installazione di Git sono insegnati in un corso Git.

GitHub è un servizio di gestione delle versioni basato sulla rete per progetti di sviluppo software. Questa gestione collaborativa delle versioni si basa sul sistema di gestione delle versioni Git. Ma che cos'è Git rispetto a GitHub? Git assicura che i diversi file vengano salvati come versioni durante le diverse fasi di un progetto. GitHub, invece, è un repository basato su cloud che mostra le modifiche e i cambiamenti in tempo reale. A differenza di altri fornitori di servizi software open source, GitHub non è incentrato sul progetto come raccolta di codice sorgente, ma sull'utente con i suoi database di codice sorgente, noti anche come repository. Importante è anche la creazione (GitHub branch) e la fusione (GitHub merge) di fork (GitHub forks). Ciò rende particolarmente facile il co-sviluppo di progetti di terze parti, in quanto le modifiche possono essere forzate e apportate tramite i database del codice sorgente. Queste modifiche vengono adottate solo in un secondo momento. Poiché tutti i passaggi sono possibili anche tramite l'interfaccia web e c'è un social network con accesso ai repository degli altri e un'app per smartphone, GitHub è adatto anche ai principianti come piattaforma per sviluppatori. Dal 2018 la piattaforma fa parte di Microsoft. GitHub è più grande di GitLab, ad esempio, ed è affidabile per la sua longevità e un numero maggiore di sviluppatori lavora sull'estensione della piattaforma, dando vita a un sistema molto stabile e performante.

Git Lab è un sistema di controllo delle versioni (VCS) basato su Git. Git si concentra sul salvataggio delle versioni dei file ed è il sistema di versioning più utilizzato sotto forma di software open source. GitLab, invece, è utilizzato da sviluppatori e programmatori per lavorare in modo agile ed efficiente su progetti software e web. È ospitato sul proprio server. Il lavoro quotidiano è facilitato dal fatto che diversi programmatori possono sviluppare contemporaneamente e lavorare su funzionalità diverse. Questo perché il versioning continuo assicura che tutte le modifiche vengano registrate. Ciò significa che nessun lavoro viene perso o sovrascritto accidentalmente. Le modifiche apportate al codice sono monitorate e possono essere annullate se necessario. I progetti creati sono organizzati in archivi digitali chiamati repository. Un repository contiene tutti i componenti di un progetto, compresi i file PHP, JavaScript, HTML e CSS associati. Con il check-out, i partecipanti al progetto caricano una copia di lavoro di un repository sul proprio computer e la versione modificata viene reinserita dopo la modifica. GitLab si basa su un modello di business open core, disponibile in due modelli di licenza: GitLab Community Edition (CE) e GitLab Enterprise Edition (EE).

Il server CI di GitLab, noto anche come coordinatore, non esegue autonomamente alcuna compilazione. Delega questo compito ai cosiddetti runner. Un runner è un processo che interroga il coordinatore per recuperare ed elaborare i lavori in sospeso. Il principio di GitLab CD viene definito pipeline GitLab. Questa pipeline GitLab definisce in quali condizioni viene controllata la convalida per pubblicare le parti di software corrispondenti. Il versionamento del codice e le tecniche associate, come la ramificazione, svolgono un ruolo importante nella CD.
GitLab può essere utilizzato come applicazione basata sul web o può essere installato sul proprio server (GitLab self-hosted). GitLab Pages può essere utilizzato per ospitare siti web statici e creare documentazione di progetto.

Un'esercitazione di GitLab comprende i seguenti contenuti:

• Creare utenti in GitLab tramite "Nuovo utente".
• Creare un nuovo progetto con "Nuovo progetto".
• Lavorare in team con GitLab con autorizzazioni e diritti di accesso

La conoscenza di GitLab può essere acquisita anche con un corso Git.