Der GitLab CI Server – auch Koordinator genannt – führt selbst keine Builds aus. Er delegiert dies an sogenannte Runner. Ein Runner ist ein Prozess, der den Koordinator pollt, um anstehende Jobs abzuholen und zu bearbeiten. Beim Prinzip von GitLab CD spricht man von einer GitLab Pipeline. Diese GitLab Pipeline definiert, unter welcher Bedingung welche Validierung geprüft wird, um entsprechende Software-Teile zu veröffentlichen. Dabei spielen die Code-Versionierung und damit verbundene Techniken wie Branching eine wichtige Rolle bei CD.
GitLab lässt sich als webbasierte Anwendung nutzen oder kann auf dem eigenen Server (GitLab self-hosted) installiert werden. Mit GitLab Pages können statische Websites gehostet und Projektdokumentationen erstellt werden.

Ein GitLab-Tutorial umfasst folgende Inhalte:

• Nutzer in GitLab via «New User» erstellen
• Ein neues Projekt mit «New Project» erstellen
• Mit GitLab zusammen im Team arbeiten mit Berechtigungen und Zugriffsrechten

Auch Wissen über GitLab kann mit einem Git-Kurs angeeignet werden.

TortoiseGit oder «Git Tortoise» ist eine freie grafische Benutzeroberfläche für die Versionsverwaltungs-Software Git unter Windows. Es steht unter General Public License (GNU). «Git Tortoise» ist als Shell-Erweiterung implementiert und integriert sich in den Windows-Explorer. Sie ist unabhängig von einer integrierten Entwicklungsumgebung verwendbar. Icons stellen den jeweiligen Status wie versioniert, unverändert, modifiziert oder ignoriert dar. Die Hauptinteraktion erfolgt über das Kontextmenü. Dort werden diverse Aktionen mit Commit, Push oder Pull ausgeführt sowie TortoiseGit-Dialoge geöffnet. Die Software hat Versions-, Revisions- und Sourcekontrolle als Kernaufgaben. Technisch basiert «Git Tortoise» auf TortoiseSVN – erweitert mit Git-spezifischen Aspekten.

Beim Arbeiten in Git ist «Speichern» nuancierter als in einem Textverarbeitungsprogramm und umfasst eine Sammlung von Dateien und Verzeichnissen. Speichern ist ein Synonym für den Git-Begriff «Comitten» - bei Speicherung ist es «Commit». Mit dem Git Befehl «Git Commit» kann ein Snapshot der aktuell bereitgestellten Änderungen des Projekts erfasst werden. Solche Committete Snapshots gelten als sichere Versionen, da hier Git nur auf explizite Anweisung Änderungen vornimmt. Vor dem Befehl «Git Commit» braucht es noch den Befehl «Git Add», um in einem Commit Änderungen zu speichern, in das Projekt in die Staging-Umgebung zu befördern oder zu «stagen». Dadurch gehören die Git-Commands (Befehle) «Git Commit» in Kombination mit dem Befehl «Git Add» zu den häufigsten genutzten und bilden den grundlegenden Git-Workflow. Danach folgt noch der Befehl «Git Status», um den Status des Arbeitsverzeichnisses und der Staging-Umgebung abzurufen. Der Befehl «Git Stash» hingegen bewirkt, dass Änderungen an der Arbeitskopie zeitweise zurückgestellt (oder auch gestasht) werden. So kann der Programmierer sich anderen Aufgaben widmen und die Änderungen später aufspielen kann. Das ist praktisch, wenn er mitten in einer Codeänderung steckt, zum Committen noch nicht bereit ist und schnell an etwas ganz anderem weiterarbeiten muss.

Ein kurzes Git Tutorial erklärt die Funktionsweise von Git:

• ein Projekt «Repository» mit einem Git-Hosting-Tool wie z. B. Bitbucket erstellen
• das Repository auf dein lokales System kopieren respektive klonen
• eine Datei dem lokalen Repository hinzufügen und einen «Commit» für die Änderungen zum «Speichern» durchführen
• Änderungen per «Push» in deinen Master-Branch verschieben
• mit einem Git-Hosting-Tool eine Änderung an der Datei vornehmen und einen Commit dafür durchführen
• einen «Pull» durchführen, um die Änderungen auf dein lokales System zu übernehmen
• einen «Git Branch» (eine Git Version) erstellen, eine Änderung vornehmen und einen Commit dafür durchführen
• eine «Pull-Anfrage» (Änderungsvorschläge für den Master-Branch) öffnen
• einen «Merge» der Änderungen in den Master-Branch durchführen

Git-Einführung, Git-Befehle und Git installieren werden an einem Git-Kurs vermittelt.

SVN nutzt ein einziges zentralisiertes Repository als Kommunikationsschnittstelle für Entwickler, wobei die Zusammenarbeit über Changesets erfolgt. Die Changesets werden zwischen den Arbeitskopien der Entwickler und dem zentralen Repository ausgetauscht. Dies ist der wichtigste Unterschied zum verteilten Zusammenarbeitsmodell von Git, wo jeder Entwickler eine eigene Kopie des Repositorys mit eigenem lokalem Verlauf sowie Branchen-Struktur erhält. So können ganze Branches (statt einer Reihe aufeinanderfolgende Commits oder einzelne Changesets) zwischen Respositorys teilen. Der Befehl «Git Remote» ist Teil eines breiten Systems zur Sychronisierung von Änderungen. Mit «Git Remote» kann eine Verbindung mit anderen Repositorys erstellt, abgerufen oder gelöscht werden. Einträge über «Git Remote» werden gemeinsam mit den Befehlen «Git Fetch», «Git Push» und «Git Pull» verwendet. Mit dem Befehl «Git Fetch» werden Commits, Dateien und Verweise aus einem Remote-Repository in das lokale Repository heruntergeladen, um zu sehen, woran alle anderen arbeiten. Durch das Einsehen der Fortschritte im zentralen Verlauf ohne Auswirkung auf die lokale Entwicklungsarbeit. Die abgerufenen Inhalte müssen mit dem Befehl «Git Checkout» explizit ausgecheckt werden, um Commits vor der Integration in lokale Respository sicher zu reviewen. Der Befehl «Git Push» wird verwendet, um Inhalte aus einem lokalen Repository in ein Remote-Repository hochzuladen. Per «Git Push» Befehl überträgst du Commits aus deinem lokalen Repository in ein Remote-Repository. Das Gegenstück dazu ist der Befehl «Git Fetch», der Commits in lokale Branches importiert. Denn mit «Git Push» kann man Commits in Remote-Branches exportieren. Remote-Branches werden mit dem Befehl «Git Remote» konfiguriert. Da beim Pushen mit «Git Push» das Risiko besteht, Änderungen zu überschreiben, sollte man dabei vorsichtig sein. Um Inhalte aus einem Remote-Repository herunterzuladen, braucht es den Befehl «Git Pull». Dadurch wird unverzüglich das lokale Repository aktualisiert, damit die Inhalte übereinstimmen. Upstream-Änderungen mit deinem lokalen Repository zusammenzuführen, ist in Git-basierten Workflows zur Zusammenarbeit häufig erforderlich. Der Befehl «Git Pull» ist eigentlich eine Befehlskombination aus «Git Fetch» gefolgt von «Git Merge». «Git Pull» führt zuerst einen «Git Fetch» aus, der den lokalen Branch umfasst und auf den HEAD verweist. Sobald die Inhalte heruntergeladen wurden, startet «Git Pull» einen Merge-Workflow. Es wird ein neuer Merge-Commit erstellt und HEAD wird so aktualisiert, um auf den neuen Commit zu verweisen. Diese und weitere Git Commands sowie Git-Tools können in einem Git-Kurs erlernt werden.

Bei GitHub handelt es sich um einen netzbasierten Dienst zur Versionsverwaltung für Software-Entwicklungsprojekte. Diese kollaborative Versionsverwaltung läuft auf dem Versionsverwaltungssystem Git. Was ist nun aber Git vs GitHub? Git sorgt für das Speichern verschiedener Dateien als Versionen während verschiedenen Phasen eines Projekts. Bei GitHub hingegen geht es um einen Cloud-basierten Speicher, die Bearbeitungen und Veränderungen in Echtzeit zeigt. Im Gegensatz zu anderen Dienstleistern von Open-Source Software geht es bei GitHub nicht zentral um das Projekt als Sammlung von Quellcode, sondern um den Nutzer mit seinen Quelltext-Datenbanken – auch Repositories genannt. Wichtig ist auch das Erstellen (GitHub branch) und Zusammenführen (GitHub merge) von Abspaltungen (GitHub forks). Dadurch wird das Mitentwickeln bei fremden Projekten besonders einfach, denn über die Quelltextdatenbanken können Änderungen abgespalten und vorgenommen werden. Erst später werden diese Änderungen schliesslich übernommen. Da sämtliche Schritte auch über die Weboberfläche möglich sind und es ein soziales Netzwerk mit Zugriff auf Repositories von anderen sowie Smartphone-App gibt, ist GitHub als Entwicklerplattform auch für Anfänger geeignet. Die Plattform gehört seit 2018 zu Microsoft. GitHub ist grösser als beispielsweise GitLab und geniesst Vertrauen für Langlebigkeit und es arbeiten mehr Entwickler an der Plattformerweiterung, was zu einem sehr stabilen performanteren System führt.

Git Lab ist ein Version Control System (VCS), das auf Git basiert. Git fokussiert sich auf das Speichern von Datei-Versionen und das am weitverbreitetsten Versionierungssystem in Form einer Open-Source-Software. GitLab hingegen wird von Entwicklern und Programmierern eingesetzt, um agil und effizient an Software- und Webprojekten arbeiten zu können. Es wird auf dem eigenen Server gehostet. Die tägliche Arbeit wird dadurch erleichtert, dass mehrere Programmierer zeitgleich entwickeln sowie an verschiedenen Features arbeiten können. Denn die stetige Versionierung sorgt für die Protokollierung sämtlicher Änderungen. So geht keine Arbeit verloren oder wird versehentlich überschrieben. Am Code vorgenommene Änderungen werden überwacht und können bei Bedarf rückgängig gemacht werden. Angelegte Projekte werden in digitalen Archiven organisiert, die sich Repositories nennen. Dabei beinhaltet ein Respository alle Bestandteile eines Projekts inkl. dazugehörigen PHP-, JavaScript-, HTML- und CSS-Dateien. Durch Auschecken laden sich Projektbeteiligte eine Arbeitskopie (Working Copy) eines Respository auf den Rechner und nach der Bearbeitung wird die geänderte Version wieder eingecheckt. GitLab basiert auf einem offenen Kerngeschäftsmodell, das es als zwei Lizenzmodellen gibt: GitLab Community Edition (CE) und GitLab Enterprise Edition (EE).