Git und GitHub Anleitung: Die wichtigsten Git Befehle für Entwickler

Git Befehle sind die Anweisungen, mit denen Sie jede Änderung in einem Projekt festhalten, Fehler rückgängig machen und als Team am selben Code arbeiten. Ich betreue seit 2012 Webprojekte, und den Zustand eines Projekts erkenne ich meist zuerst an seiner Versionsgeschichte. In diesem Leitfaden erkläre ich die täglichen Befehle, Branch Strategien, Pull Requests und das Lösen von Konflikten.

Den Ablauf für Beiträge zu Open Source Projekten behandle ich hier bewusst nicht. Forks, Upstream Remotes und Beitragsrichtlinien sind ein eigenes Thema. Stattdessen geht es darum, wie Sie in Ihren eigenen Projekten oder im Firmenteam sicher mit Git und GitHub arbeiten. Weitere technische Artikel finden Sie in der Kategorie Software.

Was sind Git Befehle, und worin unterscheiden sich Git und GitHub?

Git Befehle sind Terminalanweisungen für Git, das verteilte Versionskontrollsystem: Sie speichern Stände, zeigen die Historie, legen Branches an und gleichen Ihr Repository mit einem Server ab. GitHub dagegen ist eine Plattform, die Git Repositories in der Cloud hostet und Teamfunktionen wie Pull Requests, Code Reviews und Automatisierung ergänzt.

Diese Unterscheidung ist wichtig, denn viele Einsteiger halten beides für dasselbe. Zunächst ist Git ein Programm auf Ihrem Rechner und funktioniert auch ohne Internet vollständig. GitHub ist dagegen ein Dienst, und GitLab oder Bitbucket bieten Ähnliches an. Wer Git beherrscht, kommt also auf jeder dieser Plattformen zurecht.

Linus Torvalds schrieb Git im Jahr 2005 für die Entwicklung des Linux Kernels. Die offizielle Dokumentation und das kostenlose Buch Pro Git finden Sie auf der offiziellen Website des Projekts. Dort schlagen Sie zunächst nach, wenn ein Befehl Fragen aufwirft.

Warum sollte jeder Entwickler eine Versionskontrolle nutzen?

Ohne Versionskontrolle zu arbeiten, gleicht dem Schreiben eines Romans in einem Editor ohne Speicherverlauf. Beschädigen Sie etwa eine Datei, kommen Sie nicht zum gestrigen Stand zurück. Zudem weiß niemand, wessen Änderungen verloren gingen, sobald zwei Personen dieselbe Datei bearbeiten.

Die teuersten Fehler, die ich erlebt habe, stammten aus Projekten mit Ordnern wie "final_final_v3.zip". Auf einer Kundenseite überschrieb eine alte Kopie eine bereits live gestellte Korrektur, und der Fehler tauchte unbemerkt wieder auf. In einem Team mit Git passiert so etwas kaum, weil Git festhält, wer was wann und warum geändert hat.

Konkret bringt Ihnen Versionskontrolle Folgendes:

• Eine datierte und kommentierte Historie jeder Änderung.
• Die Möglichkeit, einen Fehler in Minuten zurückzunehmen.
• Sicheres paralleles Arbeiten an mehreren Funktionen.
• Code Reviews, bevor etwas live geht.
• Eine solide Basis für automatische Deployments.

Diese Vorteile gelten auch für Freelancer, die allein arbeiten. Gefällt einem Kunden also eine Änderung nicht, dauert der Schritt zurück nur Sekunden. Außerdem bewahrt die Kopie auf dem Server Ihre Arbeit samt Historie, falls Ihr Laptop ausfällt. Kurz gesagt ist Versionskontrolle eine Versicherung, unabhängig von der Teamgröße.

Wie installieren und konfigurieren Sie Git zum ersten Mal?

Zunächst installieren Sie Git passend zu Ihrem Betriebssystem. Konkret genügen unter macOS die Xcode Command Line Tools oder Homebrew, unter Windows Git for Windows und unter Linux der Paketmanager. Danach prüfen Sie im Terminal mit git --version, ob alles funktioniert.

Als Nächstes stellen Sie sich Git vor. Git signiert jeden Commit mit diesen Angaben, deshalb sollte die E-Mail stimmen. Entspricht sie der Adresse Ihres GitHub Kontos, erscheinen Ihre Commits zudem in Ihrem Profil.

1. Ihren Namen setzen Sie mit git config --global user.name "Ihr Name".
2. Die E-Mail tragen Sie mit git config --global user.email "sie@beispiel.de" ein.
3. Den Standardnamen für Branches legen Sie mit git config --global init.defaultBranch main fest.
4. Alle Einstellungen zeigt Ihnen anschließend git config --list.

Die Einstellung für den Branchnamen wirkt nebensächlich. Allerdings sorgt sie für Einheitlichkeit im Team, und auch GitHub verwendet main als Standard für neue Repositories. Somit vermeiden Sie ein Namenschaos zwischen lokalem und entferntem Repository.

Welche Git Befehle brauchen Sie für ein neues Repository?

Grundsätzlich gibt es zwei Wege, denn Sie können ein Repository neu anlegen oder ein bestehendes kopieren. Für ein neues Projekt öffnen Sie den Ordner und tippen git init. Dieser Befehl legt ein verstecktes Verzeichnis namens .git an, und dort speichert Git ab sofort die gesamte Historie.

Steigen Sie in ein bestehendes Projekt ein, nutzen Sie git clone mit der Adresse des Repositorys. Der Befehl lädt Dateien, Historie und Serververbindung in einem Schritt herunter. Ein neuer Entwickler in einer Agentur führt am ersten Tag daher oft nur diesen einen Befehl aus.

Direkt danach empfehle ich eine Datei namens .gitignore. Sie listet zunächst alles auf, was Git nie verfolgen soll: Abhängigkeiten wie node_modules, Build Ergebnisse und vor allem .env Dateien mit Zugangsdaten. Ich habe Teams erlebt, die versehentlich ein Passwort hochgeladen haben. Es später aus der Historie zu entfernen, kostet weit mehr Mühe als eine saubere Vorbeugung. Starke Passwörter erstellen Sie mit dem Passwort Generator, aber sie gehören nie ins Repository.

Welche Git Befehle nutzen Sie im Arbeitsalltag?

Jede Änderung durchläuft in Git drei Bereiche: das Arbeitsverzeichnis, die Staging Area und die Historie. Sie bearbeiten eine Datei, merken die gewünschten Teile vor und speichern sie dann per Commit. Dieses Modell wirkt anfangs umständlich. In der Praxis bestimmen Sie damit allerdings genau, welche Änderung in welchen Commit gehört.

Aus Gewohnheit führe ich vor jedem Commit zuerst status und dann diff aus. So landen kaum noch Debug Zeilen oder vergessene Testdateien im Repository.

Wie schreiben Sie eine gute Nachricht zu einem Commit?

Eine Commit Nachricht ist eine Notiz an Ihr zukünftiges Ich. Nachrichten wie "Fix" oder "Update" wirken heute zwar ausreichend. Suchen Sie aber in einem halben Jahr die Ursache eines Fehlers, helfen sie Ihnen nicht. Eine gute Nachricht sagt deshalb, was sich geändert hat und warum.

In der Git Community haben sich diese Regeln etabliert:

• Halten Sie die Zusammenfassung kurz; als Richtwert gelten etwa 50 Zeichen.
• Formulieren Sie im Imperativ: "Telefonprüfung im Checkout ergänzen".
• Lassen Sie eine Leerzeile und erklären Sie Details dann im Textkörper.
• Packen Sie nur eine logische Änderung in jeden Commit.
• Verweisen Sie auf die Nummer des zugehörigen Tickets.

Manche Teams nutzen das Format Conventional Commits und stellen der Nachricht einen Typ wie feat, fix oder docs voran. Das erleichtert zum Beispiel automatische Release Notes. Ein kleines Team braucht das nicht zwingend. Mit wachsendem Projekt spüren Sie den Nutzen allerdings deutlich.

Was sind Branches in Git, und wie legen Sie sie an?

Ein Branch ist eine eigenständige Arbeitslinie, die vom Hauptcode abzweigt. Somit entwickeln Sie eine Funktion, ohne main anzufassen. Ist die Arbeit fertig, führen Sie den Branch dann zurück. Scheitert das Experiment, löschen Sie ihn einfach.

Branches kosten in Git kaum etwas, denn technisch ist ein Branch nur ein leichter Zeiger auf einen Commit. Legen Sie daher für jede Aufgabe einen eigenen Branch an. Diese Befehle nutzen Sie dabei am häufigsten:

• Vorhandene Branches listet git branch auf.
• Einen neuen Branch erstellen und wechseln Sie mit git switch -c feature/kontaktformular.
• Zurück zur Hauptlinie gelangen Sie mit git switch main.
• Erledigte Branches entfernt git branch -d mit dem jeweiligen Namen.

Ältere Anleitungen verwenden dafür git checkout. Mit Version 2.23 kamen switch und restore hinzu, die zwei bisher vermischte Aufgaben von checkout trennen. Einsteigern empfehle ich switch, weil das Risiko geringer ist, versehentlich Änderungen zu verwerfen. Für saubere Branchnamen hilft übrigens auch ein Slug Generator.

Welche Branch Strategie passt zu Ihrem Team?

Eine Branch Strategie ist die gemeinsame Regel dafür, wie ein Team Branches benennt, eröffnet und zusammenführt. Die richtige Wahl hängt von Teamgröße und Release Takt ab. Eine universell beste Lösung gibt es nicht. Eine unpassende Strategie bremst allerdings und sorgt für Verwirrung.

Für Websites und Webanwendungen setze ich meist auf GitHub Flow. Die Regeln sind nämlich einfach, weil gilt: main ist jederzeit auslieferbar, jede Aufgabe läuft in einem eigenen Branch, und zusammengeführt wird per Pull Request. Git Flow lohnt sich eher bei Produkten mit Versionsnummern, etwa bei mobilen Apps.

Egal, wofür Sie sich entscheiden: Halten Sie die Regeln schriftlich fest. Neue Kollegen sollten das Benennungsschema am ersten Tag kennen.

Sollten Sie beim Zusammenführen merge oder rebase verwenden?

Beide übertragen Änderungen von einem Branch in einen anderen, dokumentieren die Historie aber unterschiedlich. Merge erzeugt am Treffpunkt einen eigenen Merge Commit und bewahrt die tatsächliche Historie. Rebase setzt Ihre Commits dagegen neu auf die Spitze des Zielbranches, und Sie erhalten eine gerade Linie.

Der praktische Unterschied sieht so aus:

• Merge ist sicher, denn bestehende Commits bleiben unberührt.
• Rebase liefert eine saubere Historie, ändert aber die Commit IDs.
• Ein gemeinsam genutzter Branch nach einem Rebase bringt die Historie der Kollegen durcheinander.
• Für den eigenen lokalen Branch ist Rebase dagegen sehr praktisch.

Meine Regel ist deshalb einfach: Rebase nur bei Branches, die mir gehören und die noch niemand gezogen hat. Bei gemeinsamen Branches nutze ich immer merge. Das Buch Pro Git formuliert dieselbe goldene Regel: Schreiben Sie keine Commits um, auf denen andere bereits aufbauen.

Wie arbeiten Sie mit einem Remote Repository auf GitHub?

Ein Remote ist die Serverkopie Ihres Projekts, über die sich das Team abgleicht. Beim Klonen legt Git die Verbindung automatisch unter dem Namen origin an. Haben Sie lokal begonnen, erstellen Sie zunächst ein leeres Repository auf GitHub. Dann verbinden Sie es mit git remote add origin und der Adresse.

Drei Befehle geraten dabei oft durcheinander. Fetch lädt zunächst Änderungen herunter, lässt Ihre Dateien aber unberührt. Pull führt fetch aus und integriert die Änderungen anschließend. Push schickt dagegen Ihre Commits an den Server, also in die andere Richtung. Bin ich unsicher, hole ich zuerst per fetch und prüfe dann den Unterschied.

Für die Anmeldung stehen HTTPS mit persönlichem Zugriffstoken oder ein SSH Schlüssel zur Wahl. GitHub akzeptiert seit 2021 keine Kontopasswörter mehr für Git Operationen. Folglich können Sie nicht mehr mit Ihrem Login Passwort pushen. Ich bevorzuge SSH Schlüssel, denn nach der Einrichtung fragen sie nie wieder nach.

Was ist ein Pull Request, und wie eröffnen Sie ihn?

Ein Pull Request ist ein formaler Vorschlag, die Änderungen eines Branches in einen anderen zu übernehmen. GitHub zeigt die geänderten Zeilen, erlaubt Kommentare und startet automatische Prüfungen. Kurz gesagt ist der Pull Request das Tor, durch das Code vor dem Release geht.

Ein typischer Ablauf sieht so aus:

1. Sie legen einen Branch an und committen Ihre Arbeit dort.
2. Den Branch schicken Sie mit git push -u origin branchname zum Server.
3. Auf GitHub klicken Sie auf "Compare and pull request".
4. Titel und Beschreibung erklären, was Sie geändert haben und warum.
5. Danach weisen Sie Reviewer zu und warten auf die Prüfungen.
6. Nach der Freigabe führen Sie zusammen und löschen den Branch.

Lassen Sie die Beschreibung außerdem nie leer. Wissen Reviewer, worauf sie achten sollen, wird das Review schneller und gründlicher. Bei Änderungen an der Oberfläche helfen zudem Screenshots. Alle Optionen erklärt die GitHub Dokumentation zu Pull Requests.

Worauf sollten Sie beim Code Review achten?

Ein Code Review dient weniger der Fehlerjagd als dem gemeinsamen Verständnis. Die prüfende Person schaut, ob der Code funktioniert, gut lesbar ist und den Projektregeln folgt. Gute Kommentare richten sich deshalb an den Code, nicht an die Person.

Beim Review stelle ich mir diese Fragen: Löst die Änderung wirklich das beschriebene Problem? Hat die Autorin an Randfälle gedacht? Gibt es Tests? Versteht jemand den Code auch in sechs Monaten noch? Zudem achte ich auf Änderungen mit Einfluss auf die Performance, denn schon eine Kleinigkeit kann eine Seite bremsen. Wie Sie das messen, zeigt mein Beitrag zum Performance Test mit Google Lighthouse.

Auch die Größe eines Pull Requests bestimmt die Qualität des Reviews. Einen Vorschlag, der Hunderte Dateien berührt, liest niemand sorgfältig. Teilen Sie die Arbeit deshalb in kleine Stücke und eröffnen Sie für jedes einen eigenen Pull Request.

Warum entstehen Konflikte beim Zusammenführen?

Ein Konflikt entsteht, wenn zwei Branches dieselben Zeilen derselben Datei unterschiedlich ändern. Git kann nicht entscheiden, welche Version gilt, und überlässt Ihnen die Wahl. Ebenso entsteht ein Konflikt, wenn ein Branch eine Datei löscht, die der andere bearbeitet.

Ein Konflikt ist kein Fehler, sondern eine natürliche Folge paralleler Arbeit. Trotzdem können Sie Konflikte seltener machen:

• Halten Sie Branches kurzlebig und führen Sie sie binnen weniger Tage zusammen.
• Holen Sie jeden Morgen die Änderungen aus main in Ihren Branch.
• Sprechen Sie sich mit Kollegen ab, die an denselben Dateien arbeiten.
• Nutzen Sie im ganzen Team denselben Formatierer mit denselben Einstellungen.

Der letzte Punkt wirkt zwar klein, löst aber ein häufiges Problem. Formatiert der Editor eines Entwicklers eine ganze Datei neu, gilt plötzlich jede Zeile als geändert. Dann folgen sinnlose Konflikte.

Wie lösen Sie einen Konflikt Schritt für Schritt?

Meldet Git einen Konflikt, ist Panik unnötig. Zunächst zeigt Ihnen git status, welche Dateien betroffen sind. Öffnen Sie diese, sehen Sie Markierungen von Git: Die Zeile mit Kleiner Zeichen leitet Ihre Version ein, die Reihe aus Gleichheitszeichen trennt beide Seiten, und die Größer Zeichen schließen die eingehende Version ab.

1. Sie öffnen die Datei und lesen beide Versionen sorgfältig.
2. Das richtige Ergebnis schreiben Sie von Hand; mal gewinnt eine Seite, mal kombinieren Sie beide.
3. Alle Markierungszeilen löschen Sie vollständig.
4. Mit git add kennzeichnen Sie die Datei als gelöst.
5. Abschließend nutzen Sie git commit beim Merge oder git rebase --continue beim Rebase.

Wird es unübersichtlich, ziehen Sie sich zurück: git merge --abort stellt den Zustand vor dem Merge wieder her. Nach der Lösung sollten Sie die Anwendung unbedingt starten und testen, denn korrekte Syntax schützt nicht vor kaputter Logik. Für einfache Konflikte bietet GitHub einen Editor im Browser. Komplexe Fälle lösen Sie dagegen besser lokal.

Mit welchen Git Befehlen machen Sie Fehler rückgängig?

Der richtige Weg hängt davon ab, wo die Änderung liegt. Eine ungespeicherte Bearbeitung zu verwerfen, ist etwas anderes, als einen bereits geteilten Commit zurückzunehmen. Mit dem passenden Befehl bleibt somit die Historie Ihrer Kollegen intakt.

Im Team gilt bei mir: revert für gepushte Commits, reset für lokale Arbeit. Revert löscht keine Historie, sondern setzt einen korrigierenden Commit obendrauf, also bleiben alle Repositories kompatibel. Und falls Ihnen etwas verloren geht, rettet Sie oft git reflog, denn es merkt sich eine Zeit lang jede Position Ihres Branches.

Wie parken Sie unfertige Arbeit mit git stash?

Stellen Sie sich vor, Sie sind mitten in einer Funktion, als ein dringender Bug gemeldet wird. Ihr Code ist nicht bereit für einen Commit, trotzdem müssen Sie den Branch wechseln. Genau dafür gibt es stash: Der Befehl legt Ihre Änderungen beiseite und räumt das Arbeitsverzeichnis auf.

Die Bedienung ist in der Praxis einfach. Mit git stash push -m "Formularprüfung halb fertig" sichern Sie die Arbeit und beheben dann den dringenden Fehler. Danach kehren Sie in Ihren Branch zurück und holen alles mit git stash pop zurück. Liegen mehrere Einträge bereit, zeigt git stash list sie alle.

Nutzen Sie stash allerdings nicht als Langzeitlager. Änderungen, die wochenlang dort liegen, geraten in Vergessenheit und kollidieren später mit main. Dauert eine Aufgabe länger als einen Tag, ist ein eigener Branch mit einem vorläufigen Commit daher die bessere Wahl.

Wie finden Sie die Ursache eines Fehlers in der Git Historie?

Taucht ein Fehler auf, lautet die erste Frage meist: Seit wann ist das kaputt? Die Git Historie bietet dafür starke Werkzeuge. Der Befehl log zeigt, wer wann was geändert hat. Blame zeigt dagegen für jede Zeile einer Datei, wer sie zuletzt angefasst hat.

Für schwierige Fälle nutzen Sie bisect. Bisect führt eine binäre Suche zwischen einem funktionierenden und einem defekten Commit durch. Bei jedem Schritt markieren Sie die aktuelle Version als gut oder schlecht, und Git halbiert den Bereich. Somit finden Sie die schuldige Änderung unter Hunderten Commits in wenigen Schritten.

Allerdings sind diese Werkzeuge nur so gut wie Ihre Commits. Kleine, aussagekräftige Commits machen bisect schnell und präzise. Ein riesiger Commit namens "Arbeit dieser Woche" stoppt die Suche dagegen sofort. Dann bleibt Ihnen nur noch das Lesen Zeile für Zeile.

Warum sind Branch Schutz und automatische Prüfungen auf GitHub wichtig?

Regeln zum Branch Schutz verhindern direkte Pushes auf main und knüpfen das Zusammenführen an Bedingungen. Sie können etwa mindestens eine Freigabe, bestandene Tests und einen aktuellen Branch verlangen. So kann selbst der erfahrenste Entwickler an einem müden Abend keinen ungeprüften Code ausliefern.

Mit GitHub Actions laufen Tests, Formatprüfungen und Builds bei jedem Pull Request automatisch. In Webprojekten ergänze ich zudem Link und SEO Prüfungen. Ein Beispiel ist die Kontrolle, dass die robots.txt nicht versehentlich die ganze Website sperrt. Beim Erstellen dieser Datei hilft Ihnen der robots.txt Generator.

Automatische Prüfungen ersetzen kein menschliches Review. Stattdessen nehmen sie Reviewern die monotone Arbeit ab. Diese können sich dann auf Architektur und Logik konzentrieren, statt auf Kommas. Die Maschine prüft also das Langweilige, der Mensch das Wesentliche.

Wie verbinden Sie Git mit dem Deployment von Webprojekten?

Der größte Gewinn von Git ist ein wiederholbares Deployment. Statt Dateien einzeln per FTP hochzuladen, gelangt jede Änderung in main automatisch auf den Server. Das geht schnell, und Sie wissen zudem jederzeit, welche Version live ist.

Mein übliches Setup hat drei Umgebungen: lokale Entwicklung, einen Staging Server und die Live Website. Ein zusammengeführter Pull Request aktualisiert zunächst Staging. Nach bestandener Kontrolle setze ich ein Release Tag und bringe den Stand live. Tags setzen Sie mit git tag, und bei Problemen dauert der Weg zum vorherigen Tag nur Minuten.

Bei einem Relaunch zählt diese Disziplin noch mehr. Ändern sich URLs, prüfen Sie die Weiterleitungen im selben Pull Request. Dazu passt meine Checkliste zur Website Migration. Bei großen Codebasen mit unabhängigen Teilen, etwa Micro Frontends, sollten Sie die Struktur der Repositories früh planen. Für Unternehmenswebsites richte ich diese Pipeline im Rahmen meiner Webdesign Leistung von Anfang an ein.

Wie legen Sie Aliase für Git Befehle an?

Befehle, die Sie täglich dutzendfach tippen, lohnen deshalb eine Abkürzung. Git bietet dafür Aliase. Nach git config --global alias.st status erledigt zum Beispiel git st dieselbe Arbeit wie status.

Diese Aliase nutze ich am häufigsten:

• st für status, ci für commit und sw für switch.
• lg für log --oneline --graph --all, das die Historie als Graph zeichnet.
• undo für reset --soft HEAD~1, das den letzten Commit zurück in die Staging Area holt.

Bleiben Sie dennoch maßvoll. Lernen Sie zuerst die echten Git Befehle und erst dann die Abkürzungen. Auf einem fremden Rechner fehlen Ihre Aliase nämlich. Außerdem verwenden Dokumentation und Fehlermeldungen stets die vollen Befehlsnamen. Ein Alias ist also Komfort, kein Ersatz für Grundwissen.

Welche Fehler machen Einsteiger mit Git am häufigsten?

Die Fehler, die ich in Teams sehe, ähneln sich über die Jahre erstaunlich stark. Zum Glück hat jeder dann auch eine einfache Lösung. Diese begegnen mir am häufigsten:

• Direkt auf main arbeiten und alles dorthin pushen.
• Tagelang ohne Commit programmieren und dann eine riesige Änderung hochladen.
• Passwörter, API Schlüssel oder .env Dateien committen.
• Auf einen gemeinsamen Branch per Force Push schreiben und fremde Arbeit löschen.
• Ohne vorheriges pull pushen und die Warnung ignorieren.
• Vage Nachrichten schreiben, die die Historie unlesbar machen.

Beim Force Push sollten Sie besonders vorsichtig sein. Müssen Sie nach einem Rebase Ihres eigenen Branches erzwingen, nutzen Sie die abgesicherte Variante, die Git unter dem Stichwort force with lease dokumentiert. Sie bricht ab, wenn der Remote Branch Änderungen enthält, die Sie noch nicht kennen. Folglich überschreiben Sie nie unbemerkt die Arbeit eines Kollegen.

Wie lernen Sie Git Befehle am besten?

Git lernen Sie durch Anwendung, nicht durch Auswendiglernen. Beginnen Sie mit den sieben Git Befehlen des täglichen Ablaufs: status, add, commit, log, diff, pull und push. Sitzen diese, gehen Sie zu Branches über und dann zu merge und Konfliktlösung. Rebase, bisect und reflog kommen hinzu, sobald Sie sie brauchen.

Legen Sie zum Beispiel ein Übungsrepository an und erzeugen Sie absichtlich einen Konflikt. Ändern Sie dieselbe Zeile in zwei Branches und führen Sie diese zusammen. Wer eine Konfliktlösung einmal in Ruhe erlebt hat, gerät im echten Projekt nicht in Panik. Grafische Oberflächen helfen ebenfalls. Trotzdem rettet Sie das Wissen um den Befehl dahinter, wenn etwas schiefgeht.

Schreiben Sie schließlich einen kurzen Teamleitfaden zu Branchnamen, Format der Nachrichten, einer Vorlage für Pull Requests und der Merge Methode. Mehr als eine Seite braucht er selten. Dennoch erleichtert er jedem neuen Kollegen die erste Woche. Ein Team, das Git gut nutzt, hat weniger Notfälle und planbarere Releases.