-
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.