Git hilft Ihnen, Änderungen an Dateien nachzuvollziehen und verschiedene Entwicklungsstände zu verwalten. Die drei zentralen Begriffe dafür sind Commit, Branch und Merge: Ein Commit hält Änderungen fest, ein Branch ermöglicht eine getrennte Entwicklungslinie, und ein Merge führt solche Linien wieder zusammen.
Wer diese Grundlagen versteht, kann Änderungen gezielt speichern, neue Ideen unabhängig ausprobieren und den passenden Stand später in den Hauptzweig übernehmen. Dafür brauchen Sie zunächst keine komplexe Einrichtung. Ein kleines Projekt und einige grundlegende Befehle reichen, um die Abläufe zu lernen.
Was Git-Einsteiger über die Versionsverwaltung wissen sollten
Git ist ein Versionsverwaltungssystem. Es speichert nachvollziehbar, wie sich Dateien in einem Projekt verändern. Statt mehrere Kopien eines Ordners mit unterschiedlichen Namen anzulegen, halten Sie wichtige Projektstände in einem Repository fest.
Ein Repository ist der von Git verwaltete Bereich eines Projekts. Es enthält die Dateien und die Informationen über deren Entwicklung. Git kann auf Ihrem Rechner lokal verwendet werden. Für die grundlegenden Abläufe mit Commits, Branches und Merges ist keine Verbindung zu einem Online-Dienst erforderlich.
Git speichert Änderungen nicht einfach als fortlaufende Liste von Dateikopien. Ein Commit verweist auf einen festgehaltenen Projektstand und auf dessen Vorgänger. So lässt sich die Entwicklung nachvollziehen und bei Bedarf ein früherer Stand wieder aufrufen. Weitere Grundlagen von Schnittstellen bis zu Werkzeugen bündelt die Themenseite Softwareentwicklung.
Repository anlegen und Zustand prüfen
Um ein vorhandenes Verzeichnis zu einem Git-Repository zu machen, wechseln Sie im Terminal in den Projektordner und führen git init aus. Git richtet dort die Verwaltungsdaten ein. Die Projektdateien bleiben an ihrem bisherigen Ort.
Der Befehl git status zeigt, welche Dateien neu, verändert oder bereits für den nächsten Commit vorgemerkt sind. Diese Übersicht ist besonders am Anfang hilfreich: Sie sehen damit, welche Änderungen Git kennt und welche Schritte noch ausstehen.
Git unterscheidet dabei zwischen Ihrem Arbeitsverzeichnis und dem sogenannten Staging-Bereich. Im Arbeitsverzeichnis bearbeiten Sie die Dateien. Im Staging-Bereich sammeln Sie gezielt die Änderungen, die zum nächsten Commit gehören sollen.
Mit git add dateiname nehmen Sie eine Datei in diesen Bereich auf. Ersetzen Sie dateiname durch den tatsächlichen Namen der Datei. Wenn Sie alle aktuellen Änderungen vormerken wollen, können Sie git add . verwenden. Prüfen Sie vorher mit git status, welche Dateien dadurch berücksichtigt werden.
Commit: Änderungen nachvollziehbar speichern
Ein Commit hält eine ausgewählte Gruppe von Änderungen als neuen Projektstand fest. Er sollte einen klar umrissenen Schritt beschreiben, zum Beispiel eine angepasste Fehlermeldung oder eine ergänzte Eingabeprüfung. Große, unzusammenhängende Änderungen in einem einzigen Commit sind später schwerer zu überblicken.
Ein einfacher Ablauf sieht so aus:
- Bearbeiten Sie eine oder mehrere Dateien.
- Prüfen Sie mit
git status, was sich verändert hat. - Nehmen Sie die passenden Dateien mit
git addin den Staging-Bereich auf. - Erstellen Sie den Commit mit
git commit -m "Kurze Beschreibung der Änderung".
Die Nachricht hinter -m sollte knapp und konkret sein. Sie erklärt, was sich geändert hat, ohne den gesamten Inhalt der Änderung zu wiederholen. Eine Nachricht wie „Eingabeprüfung ergänzt“ ist aussagekräftiger als eine allgemeine Angabe wie „Änderungen“.
Ein Commit speichert nur, was zuvor in den Staging-Bereich aufgenommen wurde. Haben Sie eine Datei bearbeitet, aber nicht mit git add vorgemerkt, gehört diese Änderung nicht zum neuen Commit. Kontrollieren Sie deshalb den Status vor und nach dem Erstellen eines Commits.
Commits bilden gemeinsam die Entwicklungsgeschichte. Sie können sich die bisherigen Commits mit git log anzeigen lassen. Dort finden Sie unter anderem die Commit-Nachricht und den Zeitpunkt der Speicherung. So lässt sich nachvollziehen, wann bestimmte Arbeitsschritte in die Versionsgeschichte aufgenommen wurden.
Warum kleine Commits hilfreich sind
Kleine, thematisch zusammengehörige Commits erleichtern die Orientierung. Wenn eine Änderung später angepasst oder zurückgenommen werden muss, ist klarer, welcher Entwicklungsschritt betroffen ist. Außerdem lassen sich einzelne Beiträge einfacher nachvollziehen, ohne dass sachfremde Änderungen dazwischenliegen.
Das bedeutet nicht, dass jede einzelne Zeile einen eigenen Commit braucht. Entscheidend ist, dass die enthaltenen Änderungen einen verständlichen Zweck haben. Bei Unsicherheit hilft die Frage: Kann die Commit-Nachricht den Inhalt dieses Schritts knapp und zutreffend beschreiben?
Branch: eine getrennte Entwicklungslinie nutzen
Ein Branch ist ein beweglicher Verweis auf eine Entwicklungslinie. Der Standardzweig enthält häufig den grundlegenden Stand eines Projekts. Für eine neue Funktion oder eine gezielte Anpassung können Sie einen zusätzlichen Branch anlegen. Änderungen in diesem Zweig bleiben zunächst getrennt von anderen Entwicklungslinien.
Dadurch können Sie an einer Aufgabe arbeiten, ohne den bestehenden Stand direkt zu verändern. Commits, die Sie im neuen Branch erstellen, gehören zunächst zu dieser Linie. Der vorherige Zweig bleibt mit seinem bisherigen Stand erhalten.
Einen Branch können Sie mit git branch name anlegen. Ersetzen Sie name durch eine passende Bezeichnung, etwa fehlermeldung-anpassen. Mit git switch name wechseln Sie in den betreffenden Branch. Mit git switch -c name lässt sich ein Branch auch in einem Schritt anlegen und direkt auswählen.
Mit git branch sehen Sie die lokalen Branches. Der aktuell ausgewählte Zweig ist in der Ausgabe markiert. Vor dem Wechsel sollten Sie prüfen, ob Ihre Änderungen bereits gesichert oder bewusst noch nicht gespeichert sind. So behalten Sie den Überblick darüber, zu welcher Entwicklungslinie Ihre Arbeit gehört.
Einen Branch sinnvoll benennen
Ein Branch-Name sollte erkennen lassen, woran Sie arbeiten. Kurze Bezeichnungen wie dokumentation-aktualisieren oder formular-pruefen sind meist verständlicher als allgemeine Namen wie neu oder arbeit. Verwenden Sie eine Schreibweise, die in Ihrem Projekt einheitlich bleibt.
Wenn die Aufgabe abgeschlossen ist, können Sie den Branch in einen anderen Zweig integrieren. Bis dahin lässt sich darin weiterarbeiten und es können mehrere passende Commits entstehen. Der Branch ist also kein separater Projektordner, sondern eine Möglichkeit, eine alternative Entwicklungslinie im selben Repository zu verwalten.
Merge: Änderungen zusammenführen
Ein Merge verbindet die Entwicklung eines Branches mit einem anderen. Häufig wechseln Sie dafür zuerst in den Zielzweig und führen dort den Branch zusammen. Wenn Sie beispielsweise die Arbeit aus fehlermeldung-anpassen in den aktuellen Hauptzweig übernehmen möchten, wechseln Sie zum Zielzweig und führen git merge fehlermeldung-anpassen aus. In Teams wird ein Branch vor dem Zusammenführen häufig von anderen durchgesehen; wie das abläuft, zeigt der Beitrag Code-Reviews im Team.
Git prüft dabei die Entwicklungsgeschichte und versucht, die Änderungen automatisch zusammenzuführen. Wenn sich die betroffenen Änderungen nicht widersprechen, kann der Merge ohne weitere Eingriffe abgeschlossen werden. Je nach Verlauf entsteht dabei ein eigener Merge-Commit; in anderen Fällen kann Git die Entwicklungslinien ohne einen zusätzlichen Merge-Commit verbinden.
Merge-Konflikte verstehen
Ein Merge-Konflikt entsteht, wenn Git eine Änderung nicht eindeutig automatisch einordnen kann. Das passiert zum Beispiel, wenn dieselbe Stelle einer Datei in zwei Entwicklungslinien unterschiedlich bearbeitet wurde. Git kennzeichnet dann die betroffenen Abschnitte in der Datei.
Öffnen Sie die markierte Datei und entscheiden Sie, welcher Inhalt im Ergebnis stehen soll. Entfernen Sie anschließend die Konfliktmarkierungen und speichern Sie die Datei. Danach nehmen Sie sie mit git add in den Staging-Bereich auf und schließen den Merge mit git commit ab, sofern Git keinen Commit bereits automatisch erstellt hat.
Bei einem Konflikt sollten Sie nicht einfach Markierungen löschen, ohne den Inhalt zu prüfen. Vergewissern Sie sich, dass die gewünschte Änderung erhalten bleibt und der zusammengeführte Abschnitt sinnvoll ist. Wenn unklar ist, welche Variante gebraucht wird, klären Sie das mit den Beteiligten, bevor Sie den Merge abschließen.
Ein einfacher Ablauf für den Alltag
Die drei Grundlagen lassen sich in einem wiederkehrenden Ablauf verbinden:
- Wechseln Sie in das Projekt und prüfen Sie mit
git statusden aktuellen Zustand. - Legen Sie für eine neue, klar umrissene Aufgabe einen Branch an und wechseln Sie dorthin.
- Bearbeiten Sie die passenden Dateien und prüfen Sie die Änderungen.
- Nehmen Sie zusammengehörige Änderungen in den Staging-Bereich auf und erstellen Sie einen aussagekräftigen Commit.
- Wiederholen Sie die Schritte, wenn weitere sinnvolle Arbeitsschritte hinzukommen.
- Führen Sie den Branch in den gewünschten Zielzweig zusammen, wenn die Arbeit abgeschlossen ist.
Dieser Ablauf trennt die Bearbeitung einer Aufgabe von der Integration in einen anderen Zweig. Zugleich bleibt die Entwicklung durch einzelne Commits nachvollziehbar. Für ein kleines persönliches Projekt können Sie Git auch ohne zusätzliche Branches einsetzen; die Grundidee eines Commits bleibt dabei dieselbe. Wie Commits anschließend automatisch geprüft und ausgeliefert werden können, beschreibt der Beitrag zu DevOps und CI/CD-Pipelines.
Fazit
Commits halten ausgewählte Änderungen fest, Branches ermöglichen getrennte Entwicklungslinien und Merges führen diese Linien zusammen. Mit git status, überschaubaren Commits und sorgfältig geprüften Zusammenführungen behalten Sie auch als Git-Einsteiger den Überblick über die Entwicklung Ihres Projekts.
Häufige Fragen
Was passiert, wenn ich eine Datei ändere, aber keinen Commit erstelle?
Die Änderung bleibt zunächst in Ihrem Arbeitsverzeichnis und ist noch kein Teil der gespeicherten Entwicklungsgeschichte. Sie können sie weiter bearbeiten, in den Staging-Bereich aufnehmen oder bewusst verwerfen. Prüfen Sie den Status, bevor Sie den nächsten Schritt ausführen.
Was bewirkt eine .gitignore-Datei?
Eine .gitignore-Datei legt fest, welche Dateien Git bei der Suche nach neuen Änderungen ignorieren soll. Häufig betrifft das lokale Einstellungen oder erzeugte Dateien, die nicht zur gemeinsamen Projektgeschichte gehören. Bereits von Git verwaltete Dateien werden dadurch nicht automatisch aus dem Repository entfernt.
Was bedeutet „detached HEAD“?
Dieser Zustand bedeutet, dass Sie einen bestimmten Commit direkt ausgewählt haben, statt auf einem Branch zu arbeiten. Neue Commits entstehen dann nicht auf einem üblichen Branch-Verweis und können später schwerer wiederzufinden sein. Wenn Sie darauf weiterarbeiten möchten, legen Sie in der Regel zunächst einen Branch an.
Kann ich ein lokales Repository später mit einem entfernten Repository verbinden?
Ja. Ein lokales Repository kann mit einem entfernten Repository verknüpft werden, damit Entwicklungsstände zwischen Arbeitsumgebungen ausgetauscht werden können. Dafür kommen Befehle wie git remote, git push und git pull zum Einsatz; die genaue Einrichtung hängt davon ab, welcher Dienst und welcher Arbeitsablauf verwendet werden.