-
1. Erste Schritte
-
2. Git Grundlagen
-
3. Git Branching
- 3.1 Branches auf einen Blick
- 3.2 Einfaches Branching und Merging
- 3.3 Branch-Management
- 3.4 Branching-Workflows
- 3.5 Remote-Branches
- 3.6 Rebasing
- 3.7 Zusammenfassung
-
4. Git auf dem Server
- 4.1 Die Protokolle
- 4.2 Git auf einem Server einrichten
- 4.3 Erstellung eines SSH-Public-Keys
- 4.4 Einrichten des Servers
- 4.5 Git-Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Von Drittanbietern gehostete Optionen
- 4.10 Zusammenfassung
-
5. Verteiltes Git
-
6. GitHub
-
7. Git Tools
- 7.1 Revisions-Auswahl
- 7.2 Interaktives Stagen
- 7.3 Stashen und Bereinigen
- 7.4 Deine Arbeit signieren
- 7.5 Suchen
- 7.6 Den Verlauf umschreiben
- 7.7 Reset entzaubert
- 7.8 Fortgeschrittenes Merging
- 7.9 Rerere
- 7.10 Debuggen mit Git
- 7.11 Submodule
- 7.12 Bundling
- 7.13 Replace (Ersetzen)
- 7.14 Anmeldeinformationen speichern
- 7.15 Zusammenfassung
-
8. Git einrichten
- 8.1 Git Konfiguration
- 8.2 Git-Attribute
- 8.3 Git Hooks
- 8.4 Beispiel fĆ¼r Git-forcierte Regeln
- 8.5 Zusammenfassung
-
9. Git und andere VCS-Systeme
- 9.1 Git als Client
- 9.2 Migration zu Git
- 9.3 Zusammenfassung
-
10. Git Interna
-
A1. Anhang A: Git in anderen Umgebungen
- A1.1 Grafische Schnittstellen
- A1.2 Git in Visual Studio
- A1.3 Git in Visual Studio Code
- A1.4 Git in IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Git in Sublime Text
- A1.6 Git in Bash
- A1.7 Git in Zsh
- A1.8 Git in PowerShell
- A1.9 Zusammenfassung
-
A2. Anhang B: Git in deine Anwendungen einbetten
- A2.1 Die Git-Kommandozeile
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Anhang C: Git Kommandos
- A3.1 Setup und Konfiguration
- A3.2 Projekte importieren und erstellen
- A3.3 Einfache Snapshot-Funktionen
- A3.4 Branching und Merging
- A3.5 Projekte gemeinsam nutzen und aktualisieren
- A3.6 Kontrollieren und Vergleichen
- A3.7 Debugging
- A3.8 Patchen bzw. Fehlerkorrektur
- A3.9 E-mails
- A3.10 Externe Systeme
- A3.11 Administration
- A3.12 Basisbefehle
A3.9 Anhang C: Git Kommandos - E-mails
E-mails
Viele Git-Projekte, einschlieĆlich Git selbst, werden vollstƤndig Ć¼ber Mailinglisten verwaltet. Git hat eine Reihe von integrierten Tools, die diesen Prozess erleichtern. Angefangen bei der Erstellung von Patches, die Sie einfach per E-Mail versenden kƶnnen, bis hin zur Anwendung dieser Patches aus einem E-Mail-Postfach heraus.
git apply
Der Befehl git apply wendet einen Patch an, der mit dem Befehl git diff oder auch mit GNU diff erstellt wurde.
Das ist vergleichbar mit dem, was der Befehl patch macht, mit ein paar kleinen Unterschieden.
In Integrieren von Ćnderungen aus E-Mails zeigen wir Ihnen die Handhabung und die Bedingungen, unter denen Sie das tun sollten.
git am
Der Befehl git am wird fĆ¼r die Ćbernahme von Patches aus einem Email-Postfach verwendet, konkret aus einem mbox-formatierten Email-Postfach.
Dadurch kƶnnen Sie Patches per E-Mail erhalten und sie einfach in Ihrem Projekt einsetzen.
In Ćnderungen mit am integrieren haben wir die Bedienung und den Umgang mit git am behandelt, einschlieĆlich der Optionen --resolved, -i und -3.
Es gibt auch eine Reihe von Hooks, die Sie zur Vereinfachung des Workflows rund um git am verwenden kƶnnen, die alle in E-Mail-Workflow-Hooks behandelt werden.
Wir verwenden ihn in E-Mail Benachrichtigungen ebenfalls, um patch-formatierte Anpassungen in GitHub Pull-Request anzuwenden.
git format-patch
Der Befehl git format-patch wird verwendet, um eine Reihe von Patches im mbox-Format zu erzeugen, die Sie an eine Mailingliste, korrekt formatiert, senden kƶnnen.
Wir zeigen anhand eines Beispiels in Ćffentliche Projekte via Email wie Sie mit dem Tool git format-patch zu einem Projekt beitragen kƶnnen .
git imap-send
Der Befehl git imap-send lƤdt eine mit git format-patch erzeugte Mailbox in einen IMAP-Entwurfsordner hoch.
Wir betrachten in Ćffentliche Projekte via Email ein Beispiel, wie Sie durch Senden von Patches mit dem Tool git imap-send zu einem Projekt beitragen kƶnnen.
git send-email
Mit dem Befehl git send-email werden Korrekturen, die mit git format-patch erzeugt wurden, Ć¼ber E-Mail verschickt.
Wir sehen in Ćffentliche Projekte via Email ein Beispiel fĆ¼r einen Projektbeitrag durch das Versenden von Patches mit dem Tool git send-email.
git request-pull
Der Befehl git request-pull wird lediglich dazu verwendet, einen exemplarischen Nachrichtentext zu generieren, der an eine Person per E-Mail gesendet werden kann.
Wenn Sie einen Branch auf einem ƶffentlichen Server haben und jemanden wissen lassen wollen, wie man diese Ćnderungen integriert, ohne dass die Patches per E-Mail verschickt werden, kƶnnen Sie diesen Befehl ausfĆ¼hren und die Ausgabe an die Person senden, die die Ćnderungen einspielen soll.
Wir zeigen in Verteiltes, ƶffentliches Projekt, wie man git request-pull verwendet, um eine Pull-Nachricht zu erzeugen.
