Was ist GitLab? Funktionen und Einstieg
Autor: Redaktion Domeny.ForSale Veröffentlicht
Kurz erklärt: GitLab ist eine Plattform zum Speichern von Code, zur Zusammenarbeit an Änderungen und zur Automatisierung von Tests und Anwendungsdeployments. Sie nutzt Git, ein System, das den Änderungsverlauf von Dateien aufzeichnet, und ergänzt es um Werkzeuge zur Arbeitsorganisation und Qualitätssicherung. Du kannst den Dienst GitLab.com nutzen oder GitLab in deiner eigenen Infrastruktur betreiben.
Wozu dient GitLab und wie unterscheidet es sich von Git?
Mit Git kannst du nachvollziehen, wer wann Dateien geändert hat, Versionen vergleichen und einen früheren Projektstand wiederherstellen. Git funktioniert auch lokal auf deinem Computer, ohne ein Konto bei einem Onlinedienst. GitLab dagegen ist eine Plattform, die Menschen, die Git nutzen, eine gemeinsame Arbeitsumgebung bereitstellt.
Die Grundlage eines Projekts ist ein Repository, also eine Sammlung von Dateien samt ihrem Änderungsverlauf. Mit GitLab kannst du das Repository im Browser durchsehen, Zugriffsrechte verwalten und vorgeschlagene Änderungen besprechen. Neben Code lassen sich darin auch Dokumentation, Serverkonfigurationen oder Textdateien einer Website speichern.
GitLab ist weder ein Code-Editor noch ein Content-Management-System wie WordPress. Entwickler schreiben ihren Code normalerweise im eigenen Editor und übertragen die Änderungen anschließend in das Repository. Die Plattform hilft dabei, diese zu prüfen und in die Umgebung zu übertragen, in der die Anwendung läuft.
Wie funktioniert die Zusammenarbeit an Änderungen?
Bei der Arbeit mit GitLabie musst du nicht direkt die Hauptversion des Projekts ändern. Ein Teammitglied erstellt einen Branch, also einen separaten Entwicklungszweig des Codes, und speichert darin Änderungen als Commits – jeweils ein Paket von Änderungen mit einer Beschreibung. So lässt sich eine neue Funktion vorbereiten, ohne sofort die Version zu beeinflussen, mit der die anderen arbeiten.
Der fertige Vorschlag wird als Merge Request eingereicht, also als Anfrage, die Änderungen mit einem ausgewählten Branch zusammenzuführen. Andere können den Code vergleichen, Kommentare hinterlassen und auf nötige Korrekturen hinweisen. Sobald die festgelegten Bedingungen erfüllt sind, werden die Änderungen zusammengeführt. Welche Freigaben erforderlich sind und welche Zugriffsregeln gelten, hängt von der Konfiguration und den verfügbaren Funktionen ab.
Ein Beispiel: Eine Agentur verbessert das Kontaktformular auf der Website eines Kunden. Ein Entwickler bereitet die Änderung in einem separaten Branch vor, eine zweite Person prüft die Fehlerbehandlung, und ein automatisierter Test kontrolliert, ob die Daten korrekt gesendet werden. Erst nach dieser Prüfung führt das Team die Änderung mit der Hauptversion zusammen und spielt sie auf der Website ein.
Zum Melden von Fehlern und Planen von Aufgaben dienen Issues: Einträge mit einer Beschreibung, einer Diskussion und einer verantwortlichen Person. Wird ein Issue mit einem Merge Request verknüpft, lässt sich leichter nachvollziehen, nicht nur was geändert wurde, sondern auch warum.
Was bringt die Automatisierung mit CI/CD?
CI/CD steht für kontinuierliche Integration sowie kontinuierliche Bereitstellung oder kontinuierliches Deployment von Änderungen. Bei der kontinuierlichen Integration wird die Arbeit des Teams häufig zusammengeführt und der Code automatisch geprüft. Die kontinuierliche Bereitstellung bereitet die Software auf eine Veröffentlichung vor. Kontinuierliches Deployment kann sie zusätzlich automatisch in der Zielumgebung veröffentlichen.
In GitLabie werden solche Abläufe normalerweise in der Datei .gitlab-ci.yml im Repository beschrieben. Sie bilden eine Pipeline, also eine Reihe von Aufgaben, die nach festgelegten Regeln ausgeführt werden. Die Aufgaben führt ein Runner aus – ein Programm, das Befehle auf der ihm zugewiesenen Infrastruktur ausführt.
Eine einfache Pipeline für eine Website kann:
- Syntax und Formatierung des Codes prüfen.
- Tests ausführen.
- Veröffentlichungsfertige Dateien erzeugen.
- Diese auf einen Testserver übertragen und nach manueller Freigabe auch auf den Produktionsserver.
Allein das Speichern eines Projekts in GitLabie setzt noch keinen vollständigen Deployment-Prozess in Gang. Du musst die Aufgaben konfigurieren, einen verfügbaren Runner bereitstellen und die nötigen Berechtigungen vergeben. Passwörter und Zugriffsschlüssel gehören nicht in den Code. Dafür dienen entsprechend geschützte CI/CD-Variablen oder ein System zur Verwaltung von Secrets. Automatisierte Tests erkennen nur Probleme, die von ihren Prüfungen abgedeckt werden. Ein grünes Ergebnis garantiert daher keine Fehlerfreiheit.
GitLab.com oder eine eigene Installation?
GitLab.com ist ein vom Anbieter betriebener Dienst. Du musst die Plattform weder installieren noch aktualisieren oder ihren Server administrieren. Für Projekteinstellungen, Benutzerkonten, Berechtigungen und den Schutz der Zugangsdaten bist du aber weiterhin verantwortlich.
Eine eigene Installation, bezeichnet als GitLab Self-Managed, gibt dir mehr Kontrolle über die Infrastruktur und den Speicherort der Daten. Dafür musst du dich um Updates, Monitoring, Backups und die Absicherung des Systems kümmern. Der Betrieb auf einem firmeneigenen Server bedeutet nicht automatisch mehr Sicherheit.
Für ein kleines Team ohne Administrator ist ein gehosteter Dienst meist der praktischere Einstieg. Eine eigene Installation kann bei besonderen Anforderungen an das Netzwerk, an Integrationen oder an Daten sinnvoll sein. Prüfe vor der Entscheidung in der offiziellen Dokumentation und der Preisübersicht von GitLaba die aktuellen Speicherlimits, die Abrechnungsregeln für CI/CD-Aufgaben und die Verfügbarkeit der benötigten Funktionen im jeweiligen Tarif.
GitLab im Vergleich zu GitHub und erste Schritte
GitLab und GitHub sind unterschiedliche Plattformen, die Git nutzen. Beide ermöglichen das Speichern von Repositories, das Prüfen von Änderungen, die Bearbeitung von Issues und die Automatisierung von Abläufen. Bei GitHubie entspricht ein Pull Request dem Merge Request. Zur Automatisierung dient unter anderem GitHub Actions.
Orientiere dich bei der Auswahl am besten an den benötigten Integrationen, den Berechtigungen, den Automatisierungskosten und der Erfahrung deines Teams. Das Git-Repository selbst lässt sich oft relativ einfach übertragen. Die Migration von Issues, Diskussionen und Deployment-Konfigurationen muss dagegen gesondert vorbereitet werden.
Erstelle zum Einstieg ein privates Projekt mit einer README-Datei, die seinen Zweck beschreibt. Bereite anschließend eine kleine Änderung in einem separaten Branch vor und eröffne einen Merge Request. Mit diesem Test lernst du den grundlegenden Arbeitsablauf kennen, bevor du Automatisierung und Serverzugriffe hinzufügst.
Lesen Sie auch
