Einführung in Git für Teams

Versionskontrolle verbindet gespeicherte Projektzustände mit einer nachvollziehbaren Historie. Sie vergleichen ein zentrales Modell mit der verteilten Architektur von Git und untersuchen die Beziehungen zwischen Working Tree, Repository, Commits und Referenzen. An einem vorbereiteten Verlauf prüfen Sie, welche Informationen lokal vorhanden sind und welche Rolle ein Remote-Repository für die Zusammenarbeit spielt.

Eine Git-Arbeitsumgebung benötigt Installation, Autorenidentität, Editor und einen passenden Zugang zum Remote-Dienst. Sie richten Git unter Windows, macOS oder Linux ein und vergleichen HTTPS mit Credential Helper sowie SSH-Schlüsseln. In der Lernumgebung prüfen Sie die Konfiguration und eine Verbindung zu GitHub, ohne Zugangsdaten im Repository abzulegen.

Git trennt den aktuellen Working Tree, den vorbereitenden Index und die gespeicherte Commit-Historie. Sie initialisieren ein Repository, ändern Dateien und wählen gezielt Inhalte für einen Commit aus. Das DevNinjas Dojo, unsere Cloud-Lernumgebung, dient zum Vergleich dieser Zustände: Sie begründen, welche Änderungen vorgemerkt sind und welche außerhalb des nächsten Snapshots bleiben.

Status, Unterschiede und Historie beantworten verschiedene Fragen zu einer Änderung. Sie untersuchen diese Perspektiven mit git status, git diff und git log und erstellen Regeln in .gitignore für erzeugte Dateien und lokale Editor-Konfiguration. Dabei diskutieren Sie auch, warum Ignorierregeln keine bereits gespeicherten Inhalte entfernen und Geheimnisse grundsätzlich nicht in die Historie gehören.

Grafische Oberflächen zeigen dieselben Git-Zustände aus einer anderen Perspektive als die Kommandozeile. Sie betrachten Commits, Diffs, Historie und Blame-Informationen in VS Code mit GitLens und gleichen die Ansicht mit dem Terminal ab. Im Vergleich entscheiden Sie, welche Darstellung eine konkrete Prüfung unterstützt und wo explizite Git-Kommandos mehr Klarheit bieten.

Ein Git-Branch ist eine bewegliche Referenz auf eine Entwicklungslinie, keine Kopie des Projekts. Sie erstellen, wechseln und entfernen Branches und beobachten, wie HEAD und der Working Tree den ausgewählten Stand abbilden. In der Lernumgebung vergleichen Sie unabhängige Änderungen und beurteilen, wann eine kurze Entwicklungslinie die spätere Integration übersichtlich hält.

Git kann Entwicklungslinien per Fast-Forward oder durch einen Merge-Commit zusammenführen; widersprüchliche Änderungen benötigen eine fachliche Entscheidung. Sie erzeugen kontrollierte Konflikte und untersuchen Basis, beide Varianten und Markierungen im Terminal sowie in VS Code. In der Lernumgebung bearbeiten Sie den Konflikt und prüfen, welche inhaltliche Entscheidung im resultierenden Stand vertreten ist.

Ein Remote verbindet das lokale Repository mit Referenzen und Objekten an einem anderen Ort. Sie klonen ein Repository, holen neue Informationen mit fetch, integrieren sie bewusst und veröffentlichen eigene Referenzen mit push. Die Lernumgebung macht den Unterschied zu pull sichtbar, sodass Sie Abruf und Integration als getrennte Entscheidungen beurteilen können.

Hosting-Plattformen ergänzen Git um Aufgaben, Diskussionen und geregelte Integrationsentscheidungen. Sie erstellen auf GitHub ein Issue, öffnen einen Pull Request, ordnen Reviewer zu und formulieren nachvollziehbares Feedback. In der Lernumgebung vergleichen Sie den technischen Branch- und Merge-Zustand mit der sozialen Review-Ebene und leiten Kriterien für eine prüfbare Änderungsbeschreibung ab.

Rebase, stash und Tags lösen unterschiedliche Probleme und verändern die Historie auf unterschiedliche Weise. Sie versetzen Commits auf eine andere Basis, legen unfertige Änderungen vorübergehend beiseite und markieren einen nachvollziehbaren Stand. An mehreren Szenarien entscheiden Sie, wann eine Umschreibung vertretbar ist, wann ein Merge die Historie besser bewahrt und welche Markierung geteilt werden soll.

Branching-Modelle strukturieren Integration, Reviews und Releases unterschiedlich. Sie vergleichen GitFlow, GitHub Flow und Trunk-Based Development anhand von Branch-Lebensdauer, Release-Takt, Automatisierung und erforderlicher Abstimmung. Für mehrere Teamszenarien bewerten Sie die jeweiligen Grenzen und formulieren Kriterien, ohne einen Workflow unabhängig vom Kontext als allgemeine Best Practice zu setzen.

Gitea stellt Repositories und Kollaborationsfunktionen als selbst gehostete Plattform bereit. Sie richten eine Instanz in der Lernumgebung ein, veröffentlichen ein Repository und vergleichen Zugriffs-, Issue- und Review-Abläufe mit GitHub. Im Mittelpunkt stehen Kriterien für Betriebsverantwortung und Zusammenarbeit; eine produktive Plattformarchitektur oder deren dauerhafter Betrieb gehört nicht zu diesem Modul.

Beiträge zu einem fremden Repository trennen die eigene Schreibberechtigung vom Integrationsrecht des Zielprojekts. Sie arbeiten mit einem Fork, richten ein upstream-Remote ein und halten die Entwicklungslinien für eine vorbereitete Änderung synchron. In der Lernumgebung formulieren Sie einen Pull Request und prüfen, welche Beschreibung und Commit-Struktur die Review-Entscheidung unterstützen.

Ein gemeinsames Repository verbindet Branching, Pull Requests, Reviews und Konfliktbearbeitung in einem zusammenhängenden Szenario. Sie übernehmen wechselnde Rollen, planen Integrationspunkte und reagieren auf parallele Änderungen in der Lernumgebung. Beobachtet wird, wie technische Git-Zustände und Teamabsprachen zusammenwirken; das Projekt schreibt weder einen universellen Workflow noch ein fertiges Ergebnis vor.

Fortgeschrittene Werkzeuge helfen, einzelne Änderungen zu übertragen und Fehlerursachen in der Historie einzugrenzen. Sie erproben cherry-pick und bisect, ordnen SHA-256 sowie reftable als alternative Hash- und Referenzformate ein und vergleichen Jujutsu (jj) und GitButler mit vertrauten Git-Abläufen. Diese Themen dienen als begrenzter Ausblick, nicht als vollständige Vertiefung.