Einführung in Git und GitLab

Versionskontrolle macht Änderungen, Zustände und Zusammenhänge eines Projekts dauerhaft nachvollziehbar. Sie unterscheiden Working Directory, Staging Area und Repository und untersuchen, wie Git Inhalte als Snapshots referenziert. Ein Vergleich mit zentralen Systemen wie SVN verdeutlicht, welche Aufgaben lokal stattfinden und wie das verteilte Modell Zusammenarbeit vorbereitet.

Ein Repository benötigt eine nachvollziehbare Identität und bewusst ausgewählte Inhalte. Das DevNinjas Dojo, unsere Cloud-Lernumgebung, bietet die Umgebung, um Git zu installieren, user.name und user.email zu konfigurieren und ein Repository zu initialisieren; Sie bearbeiten Dateien und erproben add sowie commit. Mit einer .gitignore schließen Sie generierte Dateien aus und besprechen, warum Geheimnisse unabhängig davon nicht in die Versionshistorie gehören.

Eine lesbare Historie verbindet Änderungen mit ihrem Kontext. Sie verwenden log mit Formatierungsoptionen, diff und show, um Commits sowie Arbeitsstände zu vergleichen, und markieren Releases mit tag. Mit blame verfolgen Sie die Herkunft einzelner Zeilen und grenzen technische Zuordnung von der fachlichen Ursache einer Änderung ab.

Branches trennen Arbeitsstände, ein Merge führt ausgewählte Entwicklungen wieder zusammen. Sie erstellen und wechseln Branches mit branch sowie switch, vergleichen Fast-Forward und 3-Way-Merge und lesen den entstehenden Graphen. Anschließend erzeugen Sie einen kontrollierten Merge-Konflikt und untersuchen, welche fachliche Entscheidung Git beim Auflösen nicht übernehmen kann.

Remotes verbinden die lokalen Historien mit gemeinsam erreichbaren Repositories. Sie klonen ein GitLab-Projekt, unterscheiden fetch, pull und push und verfolgen Remote-Tracking Branches im Commit-Graphen. Danach vergleichen Sie kontrolliertes Zusammenführen mit erzwungenem Push und leiten Regeln dafür ab, wann das Umschreiben geteilter Historie andere Beteiligte gefährdet.

Gruppen bündeln Projekte und können Mitgliedschaften sowie Rollen an untergeordnete Bereiche weitergeben. Sie richten ein vorbereitetes Gruppenmodell ein, hinterlegen einen SSH-Schlüssel und einen begrenzten Personal Access Token und vergeben Rollen auf Gruppen- und Projektebene. Mit getrennten Nutzerprofilen prüfen Sie, wie Zugangsdaten, Geltungsbereich und Vererbung gemeinsam mögliche Aktionen bestimmen.

Merge Requests bündeln Änderung, Diskussion und Freigabe vor dem Zusammenführen. Sie eröffnen einen Merge Request, weisen Reviewer zu, kommentieren im Diff und vergleichen Merge Commit, Squash sowie Fast-Forward. Anschließend konfigurieren Sie verfügbare Approval-Regeln in der Lernumgebung und unterscheiden eine dokumentierte Zustimmung von technisch erzwungenen Freigabebedingungen.

Schutz entsteht erst aus dem Zusammenspiel präziser Branch-Regeln, Berechtigungen und Freigaben. Sie konfigurieren einen Protected Branch, ordnen Dateien mit CODEOWNERS zu und prüfen, wann Code-Owner-Freigaben wirksam werden. Anschließend untersuchen Sie Merge Trains in der vorbereiteten Instanz und grenzen Warteschlangenprüfung von einer Garantie konfliktfreier Änderungen ab.

Issues erfassen Arbeit, Boards visualisieren Zustände und Milestones gruppieren einen gemeinsamen Zeitraum oder ein Ziel. Sie verwenden Labels, Gewichtung sowie Zeitschätzung, ordnen Issues auf einem Board an und verknüpfen eines mit einem Merge Request samt Schließreferenz. Danach bewerten Sie, welche Projektarbeit GitLab abbildet und wann ein separates Planungssystem sinnvoll bleibt.

Wiki und Snippets adressieren unterschiedliche Formen des projektbezogenen Wissens. Sie strukturieren Wiki-Seiten mit GitLab Flavored Markdown, Tabellen, Task-Listen und Mermaid-Diagrammen und untersuchen das Wiki als eigenes Git-Repository. Mit Snippets teilen Sie begrenzte Text- oder Codeausschnitte und vergleichen beide Werkzeuge mit Dokumentation im Hauptrepository anhand von Pflege und Zugriff.

Rebase, Cherry-Pick und Stash lösen unterschiedliche Aufgaben beim Ordnen und Unterbrechen von Arbeit. Sie integrieren Änderungen mit rebase, bearbeiten Commits mit Interactive Rebase und übertragen eine ausgewählte Änderung per cherry-pick. Mit stash parken Sie einen Zwischenstand und prüfen bei jedem Werkzeug, wann es nur lokale oder bereits geteilte Historie verändert.

Wiederherstellung beginnt mit der Frage, ob eine Änderung lokal oder bereits geteilt ist. Sie lokalisieren verlorene Commits mit reflog, vergleichen reset in den Modi soft, mixed und hard und untersuchen veränderte Zustände. Für veröffentlichte Commits verwenden Sie revert und begründen, warum ein neuer Gegen-Commit die gemeinsame Historie anders behandelt als Umschreiben.

Branching-Modelle verteilen Integration, Releases und Hotfixes unterschiedlich über Branches und Zeit. Sie vergleichen Git Flow, GitHub Flow und Trunk-Based Development anhand von Teamabhängigkeiten, Release-Rhythmus und Automatisierungsgrad. Für vorgegebene Szenarien entwerfen Sie passende Protected-Branch-Regeln und begründen, warum kein Modell allein durch Teamgröße oder Werkzeugwahl bestimmt wird.

Eine CI/CD-Pipeline übersetzt versionierte Konfiguration in automatisierte Jobs auf einem Runner. Sie lesen eine .gitlab-ci.yml, definieren die Stages Build und Test und ergänzen je einen Job mit Scripts. In der Lernumgebung verfolgen Sie Ausführung und Logs und grenzen diesen Einstieg von Runner-Betrieb, Deployment-Architektur und umfassender Pipeline-Sicherheit ab.

Um wiederkehrende Aktionen und Navigation zu verkürzen, erproben Sie Tastaturkürzel, Quick Actions in Issues sowie Merge Requests und ausgewählte Befehle mit glab. Anschließend vergleichen Sie die in der vorbereiteten Instanz verfügbaren Suchwege; Exact Code Search beziehen Sie nur ein, wenn die Funktion dort aktiviert ist. Abschließend ordnen Sie Git-Aliase, Shell-Konfiguration und persönliche GitLab-Einstellungen nach ihrem Einsatzbereich.