Im Laufe des Buches haben wir Dutzende von Git-Befehlen vorgestellt und uns bemüht, sie in eine Art Erzählung einzuführen und der Handlung langsam weitere Befehle hinzuzufügen. Das führt jedoch dazu, dass wir Beispiele für die Verwendung der Befehle im ganzen Buch verstreut wiederfinden.
In diesem Anhang werden die im gesamten Buch behandelten Git-Befehle genauer beschreiben, grob gruppiert nach ihren Einsatzgebieten. Wir werden darüber reden, was jeder Befehl ganz allgemein tut, und dann darauf hinweisen, wo wir ihn im Buch benutzt haben.
|
Tip
|
Sie können lange Optionen abkürzen.
Zum Beispiel können Sie |
Es gibt zwei Befehle, die von den ersten Git-Aufrufen bis hin zum täglichen Optimieren und Referenzieren wirklich oft verwendet werden: die config und help Befehle.
Git hat eine Standard-Methode, um Hunderte von Aufgaben zu erledigen. Für viele dieser Aufgaben können Sie Git anweisen, sie auf eine andere Weise auszuführen oder Ihre persönlichen Einstellungen vorzunehmen. Das reicht von der Angabe Ihres Namens bis hin zu bestimmten Terminal-Farbeinstellungen oder dem von Ihnen verwendeten Editor. Bei diesem Befehl werden mehrere Dateien gelesen und beschrieben, so dass Sie Werte global oder bis zu einem bestimmten Repository festlegen können.
Der git config Befehl wird in fast jedem Kapitel des Buches benutzt.
In ch01-getting-started.asc haben wir ihn verwendet, um unseren Namen, unsere E-Mail-Adresse und unsere Editor-Einstellung zu bestimmen, bevor wir mit Git anfangen konnten.
In Git Aliases haben wir gezeigt, wie man damit Kurzbefehle erstellen kann, die sich zu langen Optionssequenzen ausbauen, damit man sie nicht jedes Mal eingeben muss.
In Rebasing haben wir ihn verwendet, um --rebase zum Standard der Anwendung zu machen, wenn Sie git pull ausführen.
In Anmeldeinformationen speichern haben wir damit einen Standard-Speicherservice für Ihre HTTP-Passwörter eingerichtet.
In Schlüsselwort-Erweiterung haben wir gezeigt, wie Sie Smudge- und Clean-Filter für Inhalte einrichten können, die in Git ein- und ausgelesen werden.
Im Prinzip ist der gesamte Abschnitt Git Konfiguration dem Befehl gewidmet.
Neben den Konfigurationsanweisungen in Ihr Editor können viele Editoren wie folgt eingerichtet werden:
core.editor configuration commands
| Editor | Configuration command |
|---|---|
Atom |
|
BBEdit (Mac, mit Befehlszeilen-Tools) |
|
Emacs |
|
Gedit (Linux) |
|
Gvim (Windows 64-bit) |
|
Kate (Linux) |
|
nano |
|
Notepad (Windows 64-bit) |
|
Notepad++ (Windows 64-bit) |
|
Scratch (Linux) |
|
Sublime Text (macOS) |
|
Sublime Text (Windows 64-bit) |
|
TextEdit (macOS) |
|
Textmate |
|
Textpad (Windows 64-bit) |
|
UltraEdit (Windows 64-bit) |
|
Vim |
|
Visual Studio Code |
|
VSCodium (Free/Libre Open Source Software Binaries of VSCode) |
|
WordPad |
|
Xi |
|
|
Note
|
Wenn Sie einen 32-Bit-Editor auf einem Windows 64-Bit-System verwenden, wird das Programm in |
Der git help Befehl zeigt Ihnen zu einem beliebigen Befehl die gesamte Dokumentation, wie sie mit Git ausgeliefert wird.
Während wir in diesem Anhang nur einen groben Überblick über die meisten der gängigsten Befehle geben können, erhalten Sie jederzeit, für jeden Befehl eine komplette Aufstellung aller möglichen Optionen und Flags, wenn Sie git help <command> ausführen.
Wir haben den git help Befehl in Hilfe finden vorgestellt und Ihnen gezeigt, wie Sie damit mehr Informationen über git shell in Einrichten des Servers erhalten können.
Es gibt zwei Möglichkeiten, ein Git-Repository zu erhalten. Der eine ist, es aus einem bestehenden Repository im Netzwerk oder von irgendwo her zu kopieren und der andere ist, ein eigenes in einem existierenden Verzeichnis zu erstellen.
Um ein Verzeichnis zu übernehmen und es in ein neues Git-Repository umzuwandeln, so dass Sie die Versionskontrolle starten können, müssen Sie nur git init ausführen.
Wir haben das erstmals in ch02-git-basics-chapter.asc präsentiert, wo wir zeigen, wie ein neues Repository erstellt wird, mit dem man dann arbeiten kann.
Wir besprechen in ch03-git-branching.asc kurz, wie Sie den Standard-Branch-Namen „master“ ändern können.
Mit diesem Befehl erstellen wir für einen Server ein leeres Bare-Repository in ch04-git-on-the-server.asc.
Zum Schluss werden wir in ch10-git-internals.asc einige Details der Funktionsweise im Hintergrund erläutern.
Der git clone Befehl ist in Wahrheit ein Art Wrapper für mehrere andere Befehle.
Er erstellt ein neues Verzeichnis, wechselt dort hin und führt git init aus. So wird es zu einem leeren Git-Repository umgewandelt. Dann fügt er zu der übergebenen URL einen Remote (git remote add) hinzu (standardmäßig mit dem Namen origin). Er ruft ein git fetch von diesem Remote-Repository auf und holt mit git checkout den letzten Commit in Ihr Arbeitsverzeichnis.
Der git clone Befehl wird an Dutzenden von Stellen im ganzen Buch verwendet, wir werden aber nur ein paar interessante Stellen auflisten.
Er wird im Wesentlichen in ch02-git-basics-chapter.asc eingeführt und beschrieben, wobei wir einige Beispiele durchgehen.
In ch04-git-on-the-server.asc untersuchen wir die Verwendung der Option --bare, um eine Kopie eines Git-Repository ohne Arbeitsverzeichnis zu erstellen.
In ch07-git-tools.asc verwenden wir ihn, um ein gebündeltes Git-Repository zu entpacken.
Schließlich lernen wir in ch07-git-tools.asc die Option --recurse-submodules kennen, die das Klonen eines Repositorys mit Submodulen etwas einfacher macht.
Obwohl der Befehl noch an vielen anderen Stellen im Buch verwendet wird, sind das jene, die etwas eigenständig sind oder bei denen er auf eine etwas andere Weise verwendet wird.
Für den grundlegenden Workflow der Erstellung von Inhalten und dem Committen in Ihren Verlauf gibt es nur wenige einfache Befehle.
Der git add Befehl fügt, für den nächsten Commit, Inhalte aus dem Arbeitsverzeichnis der Staging-Area (bzw. „Index“) hinzu.
Bei der Ausführung des Befehls git commit wird standardmäßig nur diese Staging-Area betrachtet, so dass mit git add festgelegt wird, wie Ihr nächster Commit-Schnappschuss aussehen soll.
Dieser Befehl ist ein unglaublich wichtiges Kommando in Git und wird in diesem Buch mehrfach erwähnt oder verwendet. Wir werden kurz auf einige der einzigartigen Verwendungen eingehen, die es gibt.
Wir stellen git add zunächst in ch02-git-basics-chapter.asc vor und beschreiben ihn ausführlich.
Wir besprechen in ch03-git-branching.asc, wie man damit Konflikte beim Mergen löst.
Wir fahren in ch07-git-tools.asc damit fort, bestimmte Teile einer modifizierten Datei interaktiv zur Staging-Area hinzuzufügen.
Schließlich emulieren wir ihn in ch10-git-internals.asc auf einem unteren Level, so dass Sie sich vorstellen können, was er im Hintergrund bewirkt.
Der git status Befehl wird Ihnen die verschiedenen Dateizustände in Ihrem Arbeitsverzeichnis und der Staging-Area anzeigen.
Er zeigt welche Dateien modifiziert und nicht bereitgestellt und welche bereitgestellt (eng. staged), aber noch nicht committet sind.
In seiner üblichen Form werden Ihnen auch einige grundlegende Tipps gegeben, wie Sie Dateien zwischen diesen Stufen verschieben können.
Wir behandeln status zunächst in ch02-git-basics-chapter.asc, sowohl in seinen grundlegenden als auch in seinen kompakten Formen.
Im Buch wird so ziemlich alles angesprochen, was man mit dem Befehl git status machen kann.
Der git diff Befehl wird verwendet, wenn Sie Unterschiede zwischen zwei beliebigen Bäumen feststellen möchten.
Das könnte der Unterschied zwischen Ihrer Arbeitsumgebung und Ihrer Staging-Area (git diff an sich), zwischen Ihrer Staging-Area und Ihrem letzten Commit (git diff --staged) oder zwischen zwei Commits (git diff master branchB) sein.
In ch02-git-basics-chapter.asc betrachten wir zunächst die grundsätzliche Anwendung von git diff und zeigen dort, wie man feststellen kann, welche Änderungen bereits der Staging-Area hinzugefügt wurden und welche noch nicht.
Wir verwenden ihn mit der Option --check in ch05-distributed-git.asc, um nach möglichen Leerzeichen-Problemen zu suchen, bevor wir committen.
Wir sehen, wie man die Unterschiede zwischen Branches mit der Syntax git diff A…B in ch05-distributed-git.asc effektiver überprüfen kann.
Wir verwenden ihn, um Leerzeichen-Differenzen mit -b herauszufiltern und wie man verschiedene Stufen von Konfliktdateien mit --theirs, --ours und --base in ch07-git-tools.asc vergleicht.
Zuletzt verwenden wir ihn, um Submodul-Änderungen effektiv mit --submodule in ch07-git-tools.asc zu vergleichen.
Der Befehl git difftool startet ein externes Tool, um Ihnen den Unterschied zwischen zwei Bäumen zu zeigen, falls Sie einen anderen Befehl als das eingebaute git diff bevorzugen.
Das erwähnen wir nur kurz in ch02-git-basics-chapter.asc.
Der git commit Befehl erfasst alle Dateiinhalte, die mit git add zur Staging-Area hinzugefügt wurden und speichert einen neuen permanenten Schnappschuss in der Datenbank. Anschließend bewegt er den Branch-Pointer der aktuellen Branch zu diesem hinauf.
Wir erklären zunächst die Grundlagen des Commitings in ch02-git-basics-chapter.asc.
Dort zeigen wir auch, wie man mit dem -a Flag den Schritt git add im täglichen Arbeitsablauf überspringt und wie man mit dem -m Flag eine Commit-Meldung in der Kommandozeile übergibt, anstatt einen Editor zu starten.
In ch02-git-basics-chapter.asc befassen wir uns mit der Verwendung der Option --amend, um den letzten Commit wieder herzustellen.
In ch03-git-branching.asc gehen wir sehr viel detaillierter darauf ein, was git commit bewirkt und warum es das so macht.
In ch07-git-tools.asc haben wir uns angesehen, wie man Commits kryptographisch mit dem -S Flag signiert.
Schließlich werfen wir einen Blick darauf, was der Befehl git commit im Hintergrund macht und wie er tatsächlich eingebunden ist in ch10-git-internals.asc.
Der git reset Befehl wird in erster Linie verwendet, um Aktionen rückgängig zu machen, wie man am Kommando erkennen kann.
Er verschiebt den HEAD Pointer und ändert optional den index oder die Staging-Area und kann optional auch das Arbeitsverzeichnis ändern, wenn Sie --hard verwenden.
Bei falscher Verwendung der letzten Option kann mit diesem Befehl auch Arbeit verloren gehen, vergewissern Sie sich daher, dass Sie ihn verstehen, bevor Sie ihn verwenden.
Wir befassen uns zunächst mit der einfachsten Anwendung von git reset in ch02-git-basics-chapter.asc. Dort benutzen wir es, um eine Datei, die wir mit git add hinzu gefügt haben, wieder aus der Staging-Area zu entfernen.
Wir gehen dann in ch07-git-tools.asc detailliert auf diesen Befehl ein, der sich ganz der Beschreibung dieses Befehls widmet.
Wir verwenden git reset --hard, um einen Merge in ch07-git-tools.asc abzubrechen, wo wir auch git merge --abort verwenden, das eine Art Wrapper für den git reset Befehl ist.
Der git rm Befehl wird verwendet, um Dateien aus dem Staging-Bereich und dem Arbeitsverzeichnis von Git zu entfernen.
Er ähnelt git add dahingehend, dass er das Entfernen einer Datei für den nächsten Commit vorbereitet.
Wir behandeln den Befehl git rm in ch02-git-basics-chapter.asc ausführlich, einschließlich des rekursiven Entfernens von Dateien und des Entfernens von Dateien aus der Staging-Area, wobei sie jedoch, mit --cached, im Arbeitsverzeichnis belassen werden.
Die einzige andere abweichende Verwendung von git rm im Buch ist in ch10-git-internals.asc beschrieben, wo wir kurz die --ignore-unmatch beim Ausführen von git filter-branch verwenden und erklären, was es einfach nicht fehlerfrei macht, wenn die Datei, die wir zu entfernen versuchen, nicht existiert.
Das kann bei der Erstellung von Skripten nützlich sein.
Der git mv Befehl ist ein schlanker komfortabler Befehl, um eine Datei zu verschieben und dann git add für die neue Datei und git rm für die alte Datei auszuführen.
Wir beschreiben diesen Befehl nur kurz in ch02-git-basics-chapter.asc.
Der Befehl git clean wird verwendet, um unerwünschte Dateien aus Ihrem Arbeitsverzeichnis zu entfernen.
Dazu kann das Entfernen von temporären Build-Artefakten oder das Mergen von Konfliktdateien gehören.
Wir behandeln viele der Optionen und Szenarien, in denen Sie den clean-Befehl verwenden könnten in ch07-git-tools.asc.
Es gibt nur eine Handvoll Befehle, die die meisten Branching- und Merging-Funktionen in Git bereitstellen.
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 ch03-git-branching.asc ist dem Befehl branch gewidmet und wird im gesamten Kapitel verwendet.
Wir stellen ihn zuerst in ch03-git-branching.asc vor und betrachten die meisten seiner anderen Funktionen (das Auflisten und Löschen) in ch03-git-branching.asc.
In ch03-git-branching.asc 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 ch10-git-internals.asc durchgehen.
Der git checkout Befehl wird benutzt, um Branches zu wechseln und Inhalte in Ihr Arbeitsverzeichnis auszuchecken.
Wir sind in ch03-git-branching.asc zum ersten Mal dem git branch Befehl begegnet.
Wir zeigen in ch03-git-branching.asc, wie man das Tracking von Branches mit dem --track Flag startet.
Wir verwenden ihn in ch07-git-tools.asc, um Dateikonflikte mit --conflict=diff3 wieder zu integrieren.
Wir gehen auf die Beziehung zu git reset in ch07-git-tools.asc näher ein.
Abschließend gehen wir auf einige Details der Umsetzung in ch10-git-internals.asc ein.
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 ch03-git-branching.asc 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 ch05-distributed-git.asc 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 ch07-git-tools.asc 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 ch07-git-tools.asc gelernt, wie man Signaturen vor dem Zusammenführen überprüft, wenn Ihr Projekt GPG-Signaturen verwendet.
Schließlich haben wir in ch07-git-tools.asc das Mergen von Sub-Trees kennengelernt.
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 ch03-git-branching.asc und gehen ausführlich in ch08-customizing-git.asc darauf ein, wie Sie Ihr eigenes externes Merge-Tool integrieren können.
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 ch02-git-basics-chapter.asc 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 ch03-git-branching.asc 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 ch05-distributed-git.asc und ch07-git-tools.asc 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 ch07-git-tools.asc gehen wir ausführlicher darauf ein.
In ch07-git-tools.asc und ch07-git-tools.asc 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 ch07-git-tools.asc 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 ch07-git-tools.asc benutzen wir die Option -g, um den Git-RefLog über dieses Tool anzuzeigen, anstatt eine Branch-Überquerung durchzuführen.
In ch07-git-tools.asc 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.
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 ch07-git-tools.asc vollständig behandelt.
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 ch02-git-basics-chapter.asc eingeführt und ausführlich behandelt; wir benutzen ihn in der Praxis in ch05-distributed-git.asc.
Wir behandeln in ch07-git-tools.asc auch, wie man einen GPG-signierten Tag mit dem -s Flag erstellt und einen mit dem -v Flag verifiziert.
Es gibt nicht besonders viele Befehle in Git, die auf das Netzwerk zugreifen, fast alle Befehle arbeiten mit der lokalen Datenbank. Wenn Sie Ihre Arbeit freigeben oder Änderungen von anderswo beziehen wollen, gibt es eine kleine Anzahl von Befehlen, die sich mit Remote-Repositorys beschäftigen.
Der Befehl git fetch kommuniziert mit einem entfernten Repository und holt alle Informationen, die sich in diesem Repository befinden, aber nicht in Ihrem aktuellen Repository und speichert sie in Ihrer lokalen Datenbank.
Wir sehen uns diesen Befehl zunächst in ch02-git-basics-chapter.asc an und betrachten anschließend weitere Beispiele für seine Verwendung in ch03-git-branching.asc.
Wir benutzen ihn auch bei einigen Beispielen in ch05-distributed-git.asc.
Wir verwenden ihn in ch06-github.asc, um eine einzelne konkrete Referenz zu beziehen, die außerhalb des standardmäßigen Bereichs liegt und wir sehen, in ch07-git-tools.asc, wie man sie aus einem Packet herausholen kann.
Wir richten in ch10-git-internals.asc eigene Referenzspezifikationen ein, damit git fetch etwas anderes als die Standardeinstellung macht.
Der git pull Befehl ist im Grunde eine Kombination aus den git fetch und git merge Befehlen, wobei Git von dem angegebenen Remote holt und dann sofort versucht, es in den Branch, auf dem Sie gerade sind, zu integrieren.
Wir führen ihn in ch02-git-basics-chapter.asc ein und zeigen in ch02-git-basics-chapter.asc auf, was alles gemerged wird, wenn Sie ihn benutzen.
Wir erfahren in ch03-git-branching.asc auch, wie Sie damit bei Schwierigkeiten während des Rebasings umgehen können.
Wir zeigen in ch05-distributed-git.asc, wie man ihn mit einer URL verwendet, um Änderungen einmalig einzupflegen.
Schließlich erwähnen wir in ch07-git-tools.asc noch kurz, wie Sie die Option --verify-signatures verwenden können, um beim Abrufen/Pullen von Commits überprüfen können, ob diese mit GPG signiert wurden.
Der git push Befehl wird benutzt, um mit einem anderen Repository zu kommunizieren, zu ermitteln, was die lokale Datenbank enthält, die die entfernte nicht hat und dann die Differenz in das entfernte Repository zu pushen.
Es erfordert Schreibzugriff auf das entfernte Repository und wird daher in der Regel auf irgend eine Weise authentifiziert.
Wir sehen uns zuerst den git push Befehl in ch02-git-basics-chapter.asc an.
Hier beschreiben wir die grundlegenden Aspekte des Pushens einer Branch zu einem Remote-Repository.
In ch03-git-branching.asc gehen wir ein wenig detaillierter auf das Pushen bestimmter Branches ein und in ch03-git-branching.asc sehen wir, wie man Tracking-Branches einrichtet, um dorthin automatisch zu pushen.
In ch03-git-branching.asc benutzen wir die Option --delete, um einen Branch auf dem Server mit git push zu löschen.
Im Kapitel 5 ch05-distributed-git.asc können Sie einige Beispiele für die Verwendung von git push finden,wie Sie Ihre Arbeit an Branches mit mehreren Remotes teilen können.
Wir sehen in ch02-git-basics-chapter.asc, wie Sie diesen Befehl benutzen können, um Tags, die Sie mit der --tags Option erstellt haben, gemeinsam zu nutzen.
In ch07-git-tools.asc verwenden wir die Option --recurse-submodules, um zu überprüfen, ob alle unsere Submodule funktionieren, bevor wir zum Hauptprojekt pushen, was bei der Verwendung von Submodulen sehr hilfreich sein kann.
In ch08-customizing-git.asc sprechen wir kurz über den pre-push Hook, ein Skript, das wir so einrichten können, dass es vor dem Abschluss eines Pushs ausgeführt wird, um zu prüfen, ob es zulässig sein sollte, zu pushen.
Schließlich betrachten wir in ch10-git-internals.asc das Pushen mit einer vollständigen Referenzspezifikation (engl. refspec) anstelle der allgemeinen Abkürzungen, die normalerweise verwendet werden. Das kann Ihnen helfen, sehr spezifisch zu entscheiden, welche Arbeit Sie teilen möchten.
Der Befehl git remote ist ein Management-Tool für die Verwaltung Ihrer Datensätze in Remote-Repositorys.
Er erlaubt Ihnen, lange URLs als kurze Handles zu speichern, wie z.B. „origin“, damit Sie diese nicht ständig abtippen müssen.
Sie können auch mehrere solcher Adressen einrichten und der Befehl git remote wird verwendet, um sie hinzuzufügen, zu ändern oder zu löschen.
Dieser Befehl wird ausführlich in ch02-git-basics-chapter.asc behandelt, einschließlich des Auflistens, Hinzufügens, Entfernens und Umbenennens.
Er wird auch in fast jedem der nachfolgenden Kapitel des Buchs verwendet, aber immer im Standardformat git remote add <name> <url>.
Der Befehl git archive wird verwendet, um eine Archivdatei von einem bestimmten Snapshot des Projekts zu erstellen.
Wir benutzen git archive in ch05-distributed-git.asc, um einen Tarball eines Projektes für die gemeinsame Nutzung zu erstellen.
Der Befehl git submodule dient dazu, externe Repositorys innerhalb eines normalen Repositorys zu verwalten.
Das kann für Bibliotheken oder andere Arten von gemeinsam genutzten Ressourcen nötig sein.
Das submodule Kommando hat mehrere Unterbefehle (add, update, sync, usw.) für die Verwaltung dieser Ressourcen.
Dieser Befehl wird nur in ch07-git-tools.asc erwähnt und dort ausführlich beschrieben.
Der Befehl git show kann ein Git-Objekt auf eine einfache und für den Benutzer lesbare Weise darstellen.
Normalerweise würden Sie diesen Befehl verwenden, um die Informationen über ein Tag oder einen Commit anzuzeigen.
Wir verwenden ihn erstmals in ch02-git-basics-chapter.asc, um annotierte Tag-Informationen anzuzeigen.
Danach, in ch07-git-tools.asc, verwenden wir ihn mehrfach, um die Commits zu dokumentieren, die unsere verschiedenen Revisionsauswahlen betreffen.
Eines der interessanteren Dinge, die wir in ch07-git-tools.asc mit git show machen, ist das Extrahieren bestimmter Dateiinhalte in verschiedenen Abschnitten bei einem Merge-Konflikt.
Der Befehl git shortlog wird verwendet, um die Ausgabe von git log zu verdichten.
Dieses Kommando kennt ähnliche Optionen wie git log, aber anstatt alle Commits aufzulisten, wird eine Zusammenfassung der Commits, gruppiert nach Autor angezeigt.
Wir haben in ch05-distributed-git.asc gezeigt, wie man damit ein schönes Changelog erstellt.
Der Befehl git describe wird verwendet, um alles zu übernehmen, das zu einem Commit führt und er erzeugt eine Zeichenkette, die einigermaßen menschenlesbar ist und sich nicht ändern wird.
Es ist eine Möglichkeit, eine Beschreibung eines Commits zu erhalten, die so eindeutig wie ein Commit SHA-1 ist, dafür aber auch verständlicher.
Wir verwenden git describe in ch05-distributed-git.asc und ch05-distributed-git.asc, um einen String zu erzeugen, der unsere Release-Datei benennt.
Git hat ein paar Befehle, die Ihnen helfen, ein Problem im Code zu debuggen. Das geht vom Feststellen, wann etwas eingefügt wurde, bis zum Erkennen, wer es eingereicht hat.
Das Tool git bisect ist ein unglaublich hilfreiches Debugging-Tool, das eingesetzt wird, um mit Hilfe einer automatischen Binärsuche herauszufinden, welcher bestimmte Commit als erster einen Fehler oder ein Problem verursacht hat.
Es wird in ch07-git-tools.asc vollständig dokumentiert und nur in diesem Abschnitt behandelt.
Der Befehl git blame kommentiert die Zeilen einer Datei, bei denen ein Commit zuletzt eine Änderung vorgenommen hat. Zudem wird vermerkt, wer der Autor des Commits ist.
Das hilft Ihnen, denjenigen zu ermitteln, der weitere Angaben zu einem bestimmten Abschnitt Ihres Codes machen kann.
Er wird in ch07-git-tools.asc behandelt und nur in diesem Kapitel beschrieben.
Der Befehl git grep kann Ihnen bei der Suche nach einer beliebigen Zeichenfolge oder einem regulären Ausdruck in irgendeiner der Dateien Ihres Quellcodes behilflich sein, selbst in älteren Fassungen Ihres Projekts.
Er wird in ch07-git-tools.asc behandelt und nur dort beschrieben.
Ein paar Befehle in Git fokussieren sich um die konzeptionelle Überlegung, wie Commits sich in Bezug auf die Änderungen verhalten, die sie einführen, wenn die Commit-Serie eine Reihe von Patches wäre. Diese Befehle helfen Ihnen, Ihre Branches auf dieser Grundlage zu organisieren.
Die git cherry-pick Anweisung wird benutzt, um die Änderung, die in einem einzelnen Git-Commit vorgenommen wurde, als neuen Commit auf dem Branch, auf dem Sie sich gerade befinden, erneut vorzunehmen.
Das kann sinnvoll sein, um nur ein oder zwei Commits aus einem Branch individuell zu übernehmen, anstatt sie in den Branch einzubringen, der sämtliche geänderten Daten enthält.
Das „Kirschenpflücken“ (engl. cherry picking) wird in ch05-distributed-git.asc beschrieben und demonstriert.
Der Befehl git rebase ist im Grunde genommen ein automatisches cherry-pick.
Er ermittelt eine Reihe von Commits und nimmt sie dann nacheinander, in der gleichen Reihenfolge, an anderer Stelle wieder auf.
Rebasing wird ausführlich in ch03-git-branching.asc behandelt, einschließlich der Problematik bei der Zusammenarbeit im Zusammenhang mit Rebasing von bereits veröffentlichten Branches.
Wir verwenden ihn bei einem praktischen Beispiel in ch07-git-tools.asc für die Aufteilung Ihres Verlaufs in zwei getrennte Repositorys, wobei auch das Flag --onto benutzt wird.
In ch07-git-tools.asc kommt es bei einem Rebase zu einem Merge-Konflikt.
In ch07-git-tools.asc verwenden wir ihn auch in einem interaktiven Skripting-Modus mit der Option -i.
Der git revert Befehl ist im Prinzip ein umgekehrter git cherry-pick.
Er erzeugt einen neuen Commit, der das genaue Gegenteil der Änderung bewirkt, die in dem Commit, auf den Sie gerade zugreifen, eingeführt wurde, d.h. er macht ihn rückgängig.
In ch07-git-tools.asc verwenden wir diesen Befehl, um einen Merge-Commit rückgängig zu machen.
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.
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 ch05-distributed-git.asc zeigen wir Ihnen die Handhabung und die Bedingungen, unter denen Sie das tun sollten.
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 ch05-distributed-git.asc 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 ch08-customizing-git.asc behandelt werden.
Wir verwenden ihn in ch06-github.asc ebenfalls, um patch-formatierte Anpassungen in GitHub Pull-Request anzuwenden.
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 ch05-distributed-git.asc wie Sie mit dem Tool git format-patch zu einem Projekt beitragen können .
Der Befehl git imap-send lädt eine mit git format-patch erzeugte Mailbox in einen IMAP-Entwurfsordner hoch.
Wir betrachten in ch05-distributed-git.asc ein Beispiel, wie Sie durch Senden von Patches mit dem Tool git imap-send zu einem Projekt beitragen können.
Mit dem Befehl git send-email werden Korrekturen, die mit git format-patch erzeugt wurden, über E-Mail verschickt.
Wir sehen in ch05-distributed-git.asc ein Beispiel für einen Projektbeitrag durch das Versenden von Patches mit dem Tool git send-email.
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 ch05-distributed-git.asc, wie man git request-pull verwendet, um eine Pull-Nachricht zu erzeugen.
Git enthält einige Kommandos mit denen eine Integration mit anderen Versionskontrollsystemen möglich ist.
Mit Hilfe der Funktion git svn kann man als Client mit dem Versionskontrollsystem Subversion kommunizieren.
Das bedeutet, dass Sie Git zum Auschecken von und zum Committen an einen Subversion-Server verwenden können.
Dieser Befehl wird in ch09-git-and-other-systems.asc ausführlich erläutert.
Für andere Versionskontrollsysteme oder den Import aus beinahe jedem Format können Sie git fast-import verwenden. So können Sie das andere Format einfach auf etwas umwandeln, das Git problemlos verarbeiten kann.
In ch09-git-and-other-systems.asc wird diese Funktion eingehend untersucht.
Wenn Sie ein Git-Repository verwalten oder etwas in größerem Umfang reparieren müssen, bietet Git eine Reihe von Verwaltungsbefehlen, die Sie dabei unterstützen.
Der Befehl git gc führt „garbage collection“ (dt. Speicherbereinigung) auf Ihrem Repository aus. Er entfernt unnötige Dateien aus Ihrer Datenbank und packt die verbleibenden Dateien in ein effizientes Format.
Dieser Befehl läuft normalerweise im Hintergrund ab. Wenn Sie wollen, können Sie ihn aber auch manuell ausführen. Wir werden einige Beispiele dafür in ch10-git-internals.asc näher betrachten.
Der Befehl git fsck wird zur Überprüfung der internen Datenbank auf Probleme oder Inkonsistenzen verwendet.
Wir beschreiben ihn nur kurz in ch10-git-internals.asc, um nach verwaisten Objekten zu suchen.
Der Befehl git reflog untersucht ein Log-Protokoll, in dem alle Heads Ihrer Branches aufgezeichnet sind, während Sie daran gearbeitet haben. So können Sie Commits finden, die Sie durch das Umschreiben der Historie verloren haben könnten.
Wir beschäftigen uns mit diesem Befehl hauptsächlich in ch07-git-tools.asc. Dort zeigen wir die normale Benutzung und die Verwendung von git log -g, um die gleichen Informationen so zu formatieren damit sie wie mit der git log Ausgabe aussehen.
Wir stellen in ch10-git-internals.asc ein praktisches Beispiel für die Wiederherstellung einer derart verloren gegangener Branch vor.
Der Befehl git filter-branch dient dazu, eine Vielzahl von Commits nach bestimmten Kriterien umzuschreiben. Sie können beispielsweise eine Datei überall entfernen oder das gesamte Repository in ein einziges Unterverzeichnis filtern, zum Extrahieren eines Projekts.
In ch07-git-tools.asc erklären wir den Befehl und untersuchen verschiedene Optionen wie --commit-filter, --subdirectory-filter und --tree-filter.
In ch09-git-and-other-systems.asc verwenden wir ihn, um importierte externe Repositorys zu berichtigen.
Es gibt zudem eine ganze Reihe von Basisbefehlen, auf die wir in diesem Buch gestoßen sind.
Zuerst begegnen wir ls-remote in ch06-github.asc, das wir zum Betrachten der Rohdaten auf dem Server verwenden.
Wir verwenden ls-files in ch07-git-tools.asc, ch07-git-tools.asc und ch07-git-tools.asc, um einen groben Einblick in Ihre Staging-Area zu erhalten.
Wir beziehen uns in ch07-git-tools.asc auch auf rev-parse, um so gut wie jede beliebige Zeichenkette zu verwenden und sie in ein SHA-1 Objekt zu konvertieren.
Die meisten der von uns beschriebenen Low-Level Basisbefehle sind in ch10-git-internals.asc enthalten, worauf sich das Kapitel mehr oder weniger konzentriert. Wir haben versucht, sie im restlichen Teil des Buches nicht zu verwenden.