-
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 Ihre 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 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 Ihre 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.4 Anhang C: Git Kommandos - Branching und Merging
Branching und Merging
Es gibt nur eine Handvoll Befehle, die die meisten Branching- und Merging-Funktionen in Git bereitstellen.
git branch
Der git branch
Befehl ist eigentlich so etwas wie ein Branch-Management-Tool.
Er kann die von Ihnen vorhandenen Branches auflisten, einen neuen Branch erstellen, Branches löschen und umbenennen.
Der größte Teil von Git Branching ist dem Befehl branch
gewidmet und wird im gesamten Kapitel verwendet.
Wir stellen ihn zuerst in Erzeugen eines neuen Branches vor und betrachten die meisten seiner anderen Funktionen (das Auflisten und Löschen) in Branch-Management.
In Tracking-Branches verwenden wir die Option git branch -u
, um einen Tracking-Branch einzurichten.
Schließlich werden wir einige der Funktionen, die im Hintergrund ausgeführt werden, in Git Referenzen durchgehen.
git checkout
Der git checkout
Befehl wird benutzt, um Branches zu wechseln und Inhalte in Ihr Arbeitsverzeichnis auszuchecken.
Wir sind in Wechseln des Branches zum ersten Mal dem git branch
Befehl begegnet.
Wir zeigen in Tracking-Branches, wie man das Tracking von Branches mit dem --track
Flag startet.
Wir verwenden ihn in Die Konflikte austesten, um Dateikonflikte mit --conflict=diff3
wieder zu integrieren.
Wir gehen auf die Beziehung zu git reset
in Reset entzaubert näher ein.
Abschließend gehen wir auf einige Details der Umsetzung in HEAD ein.
git merge
Das git merge
Tool wird benutzt, um einen oder mehrere Branches in den von in den ausgecheckten Branch zusammenzuführen.
Es wird dann der aktuelle Branch zum Ergebnis des Merge-Vorgangs weitergeführt.
Der Befehl git merge
wurde zunächst in Einfaches Branching vorgestellt.
Obwohl er an verschiedenen Stellen im Buch verwendet wird, gibt es nur sehr wenige Variationen des Befehls merge
. In der Regel nur git merge <branch>
mit dem Namen des einzelnen Branches, in dem Sie zusammenführen möchten.
Wir haben am Ende von Verteiltes, öffentliches Projekt beschrieben, wie man ein Squashed Merge macht (bei dem Git die Arbeit zusammenführt, sich aber so verhält, als wäre es nur ein neuer Commit, ohne die Historie des Branches, in dem man zusammenführt, aufzuzeichnen).
Wir haben in Fortgeschrittenes Merging viel über den Merge-Prozess und -Befehl berichtet, einschließlich des Befehls -Xignore-space-change
und des Flags --abort
, um ein Merge-Problem abzubrechen.
Wir haben in Commits signieren gelernt, wie man Signaturen vor dem Zusammenführen überprüft, wenn Ihr Projekt GPG-Signaturen verwendet.
Schließlich haben wir in Subtree Merging das Mergen von Sub-Trees kennengelernt.
git mergetool
Der git mergetool
Befehl startet lediglich einen externen Merge-Helfer, falls Sie Probleme mit einer Zusammenführung in Git haben.
Wir erwähnen ihn kurz in Einfache Merge-Konflikte und gehen ausführlich in Externe Merge- und Diff-Tools darauf ein, wie Sie Ihr eigenes externes Merge-Tool integrieren können.
git log
Der git log
Befehl wird verwendet, um den verfügbaren, aufgezeichneten Verlauf eines Projekts, ab des letzten Commit-Snapshots, rückwärts anzuzeigen.
Standardmäßig wird nur die Historie des Branchs angezeigt, in dem Sie sich gerade befinden, kann aber mit verschiedenen oder sogar mehreren Heads oder Branches belegt werden, mit denen Sie Schnittmengen haben können.
Er wird häufig verwendet, um Unterschiede zwischen zwei oder mehr Branches auf der Commit-Ebene anzuzeigen.
Dieses Kommando wird in fast jedem Kapitel des Buches verwendet, um die Verlaufshistorie eines Projekts zu demonstrieren.
Wir stellen den Befehl in Anzeigen der Commit-Historie vor und gehen dort etwas ausführlicher darauf ein.
Wir betrachten die Option -p
und --stat
, um eine Übersicht darüber zu erhalten, was in jedem Commit enthalten ist, und die Optionen --pretty
und --oneline
, um die Historie, zusammen mit einigen einfachen Datums- und Autoren-Filteroptionen, übersichtlicher wiederzugeben.
In Erzeugen eines neuen Branches verwenden wir ihn mit der Option --decorate
, um leichter zu verdeutlichen, wo unser Branch-Pointer sich gerade befindet und wir benutzen auch die --graph
Option, um zu sehen, wie die unterschiedlichen Verläufe aussehen.
In Kleines, privates Team und Commit-Bereiche behandeln wir die Syntax branchA..branchB
, um mit dem git log
Befehl zu überprüfen, welche Commits, relativ zu einem anderen Branch, eindeutig sind.
In Commit-Bereiche gehen wir ausführlicher darauf ein.
In Merge-Protokoll und Dreifacher Punkt wird das Format branchA…branchB
und die Syntax --left-right
verwendet, um zu sehen, was in dem einen oder anderen Branch vorhanden ist, aber nicht in beiden.
In Merge-Protokoll untersuchen wir auch, wie Sie die Option --merge
verwenden können, um beim Debugging von Merge-Konflikten zu helfen, sowie die Option --cc
, um Merge-Commit-Konflikte in Ihrem Verlauf zu betrachten.
In RefLog Kurzformen benutzen wir die Option -g
, um den Git-RefLog über dieses Tool anzuzeigen, anstatt eine Branch-Überquerung durchzuführen.
In Suchen schauen wir uns die Verwendung der -S
und -L
Optionen an, um eine relativ komplexe Suche nach etwas durchzuführen, was während der Entwicklung des Codes passiert ist, wie z.B. den Fortschritt in einer Funktion wahrzunehmen.
In Commits signieren sehen wir, wie man mit Hilfe der Option --show-signature
jedem Commit in der git log
Ausgabe eine Validierungs-Zeichenkette hinzufügt, abhängig von der Gültigkeit der Signatur.
git stash
Der Befehl git stash
wird verwendet, um nicht fertiggestellte Arbeit vorübergehend zu speichern, um Ihr Arbeitsverzeichnis aufzuräumen, ohne unfertige Arbeit auf einem Branch committen zu müssen.
Im Wesentlichen wird dieses Thema in Stashen und Bereinigen vollständig behandelt.
git tag
Der Befehl git-tag
wird verwendet, um ein permanentes Lesezeichen an einen bestimmten Punkt in der Code-Historie zu setzen.
Im Allgemeinen wird das für die Erstellung von Releases verwendet.
Dieser Befehl wird in Taggen eingeführt und ausführlich behandelt; wir benutzen ihn in der Praxis in Tagging ihres Releases.
Wir behandeln in Ihre Arbeit signieren auch, wie man einen GPG-signierten Tag mit dem -s
Flag erstellt und einen mit dem -v
Flag verifiziert.