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
|
Du kannst lange Optionen abkürzen.
Zum Beispiel kannst du |
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 kannst du Git anweisen, sie auf eine andere Weise auszuführen oder deine persönlichen Einstellungen vorzunehmen. Das reicht von der Angabe deines Namens bis hin zu bestimmten Terminal-Farbeinstellungen oder dem von dir verwendeten Editor. Bei diesem Befehl werden mehrere Dateien gelesen und beschrieben, so dass du Werte global oder bis zu einem bestimmten Repository festlegen kannst.
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 du git pull ausführst.
In Anmeldeinformationen speichern haben wir damit einen Standard-Speicherservice für deine HTTP-Passwörter eingerichtet.
In Schlüsselwort-Erweiterung haben wir gezeigt, wie du Smudge- und Clean-Filter für Inhalte einrichten kannst, die in Git ein- und ausgelesen werden.
Im Prinzip ist der gesamte Abschnitt Git Konfiguration dem Befehl gewidmet.
Neben den Konfigurationsanweisungen in Dein 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 du einen 32-Bit-Editor auf einem Windows 64-Bit-System verwendest, wird das Programm in |
Der git help Befehl zeigt dir 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, erhältst du jederzeit, für jeden Befehl eine komplette Aufstellung aller möglichen Optionen und Flags, wenn du git help <command> ausführst.
Wir haben den git help Befehl in Hilfe finden vorgestellt und dir gezeigt, wie du damit mehr Informationen über git shell in Einrichten des Servers erhalten kannst.
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 du die Versionskontrolle starten kannst, musst du 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 du den Standard-Branch-Namen „master“ ändern kannst.
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 dein 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 deinen 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 dein 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 du dir vorstellen kannst, was er im Hintergrund bewirkt.
Der git status Befehl wird dir die verschiedenen Dateizustände in deinem 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 dir auch einige grundlegende Tipps gegeben, wie du Dateien zwischen diesen Stufen verschieben kannst.
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 du Unterschiede zwischen zwei beliebigen Bäumen feststellen möchtest.
Das könnte der Unterschied zwischen deiner Arbeitsumgebung und deiner Staging-Area (git diff an sich), zwischen deiner Staging-Area und deinem 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 dir den Unterschied zwischen zwei Bäumen zu zeigen, falls du einen anderen Befehl als das eingebaute git diff bevorzugst.
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 du --hard verwendest.
Bei falscher Verwendung der letzten Option kann mit diesem Befehl auch Arbeit verloren gehen, vergewissere dich daher, dass du ihn verstehst, bevor du ihn verwendest.
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 deinem 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 du den clean-Befehl verwenden könntest 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 dir 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 dein 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 du zusammenführen möchtest.
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 dein 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 du Probleme mit einer Zusammenführung in Git hast.
Wir erwähnen ihn kurz in ch03-git-branching.asc und gehen ausführlich in ch08-customizing-git.asc darauf ein, wie du dein eigenes externes Merge-Tool integrieren kannst.
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 du dich gerade befindest. Er kann aber mit verschiedenen oder sogar mehreren Heads oder Branches belegt werden, mit denen du Schnittmengen bilden kannst.
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 du die Option --merge verwenden kannst, um beim Debugging von Merge-Konflikten zu helfen, sowie die Option --cc, um Merge-Commit-Konflikte in deinem 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 dein 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 du deine Arbeit freigeben oder Änderungen von anderswo beziehen willst, gibt es eine kleine Anzahl von Befehlen, die sich mit Remote-Repositorys beschäftigen.
Der Befehl git fetch kontaktiert das entfernte Repository und lädt alle neuen Commits, Branches und Tags herunter, die in deinem lokalen Repository noch nicht vorhanden sind. Diese Informationen werden in der lokalen Git-Datenbank gespeichert, ohne deinen aktuellen Arbeitsstand zu verändern.
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 Befehl git pull kombiniert die Funktionen von git fetch und git merge: Git ruft die neuesten Änderungen aus dem angegebenen Remote-Repository ab und versucht anschließend, diese direkt in den aktuellen Branch 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 du ihn benutzt.
Wir erfahren in ch03-git-branching.asc auch, wie du damit bei Schwierigkeiten während des Rebasings umgehen kannst.
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 du die Option --verify-signatures verwenden kannst, um beim Abrufen/Pullen von Commits überprüfen kannst, 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 kannst du einige Beispiele für die Verwendung von git push finden,wie du deine Arbeit an Branches mit mehreren Remotes teilen kannst.
Wir sehen in ch02-git-basics-chapter.asc, wie du diesen Befehl benutzen kannst, um Tags, die du mit der --tags Option erstellt hast, 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 dir helfen, sehr spezifisch zu entscheiden, welche Arbeit du teilen möchtest.
Der Befehl git remote ist ein Management-Tool für die Verwaltung deiner Datensätze in Remote-Repositorys.
Er erlaubt dir, lange URLs als kurze Handles zu speichern, wie z.B. „origin“, damit du diese nicht ständig abtippen musst.
Du kannst 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ürdest du 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 dir 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 dir, denjenigen zu ermitteln, der weitere Angaben zu einem bestimmten Abschnitt deines Codes machen kann.
Er wird in ch07-git-tools.asc behandelt und nur in diesem Kapitel beschrieben.
Der Befehl git grep kann dir bei der Suche nach einer beliebigen Zeichenfolge oder einem regulären Ausdruck in irgendeiner der Dateien deines Quellcodes behilflich sein, selbst in älteren Fassungen deines 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 dir, deine 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 du dich gerade befindest, 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 deines 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 du gerade zugreifst, 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 du einfach per E-Mail versenden kannst, 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 dir die Handhabung und die Bedingungen, unter denen du das tun solltest.
Der Befehl git am wird für die Übernahme von Patches aus einem Email-Postfach verwendet, konkret aus einem mbox-formatierten Email-Postfach.
Dadurch kannst du Patches per E-Mail erhalten und sie einfach in deinem 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 du zur Vereinfachung des Workflows rund um git am verwenden kannst, 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 du an eine Mailingliste, korrekt formatiert, senden kannst.
Wir zeigen anhand eines Beispiels in ch05-distributed-git.asc wie du mit dem Tool git format-patch zu einem Projekt beitragen kannst .
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 du durch Senden von Patches mit dem Tool git imap-send zu einem Projekt beitragen kannst.
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 du einen Branch auf einem öffentlichen Server hast und jemanden wissen lassen willst, wie man diese Änderungen integriert, ohne dass die Patches per E-Mail verschickt werden, kannst du 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.
Der Befehl git svn wird verwendet, um als Client mit dem Versionskontrollsystem Subversion (SVN) zu kommunizieren.
Das bedeutet, du kannst Git verwenden, um ein Repository von einem Subversion-Server auszuchecken und Änderungen wieder dorthin zu übertragen (commiten).
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 kannst du git fast-import verwenden. So kannst du 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 du ein Git-Repository verwaltest oder etwas in größerem Umfang reparieren musst, bietet Git eine Reihe von Verwaltungsbefehlen, die dich dabei unterstützen.
Der Befehl git gc führt „garbage collection“ (dt. Speicherbereinigung) auf deinem Repository aus. Er entfernt unnötige Dateien aus deiner Datenbank und packt die verbleibenden Dateien in ein effizientes Format.
Dieser Befehl läuft normalerweise im Hintergrund ab. Wenn du willst, kannst du 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 deiner Branches aufgezeichnet sind, während du daran gearbeitet hast. So kannst du Commits finden, die du durch das Umschreiben der Historie verloren haben könntest.
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 wird verwendet, um eine große Anzahl von Commits nach bestimmten Mustern neu zu schreiben – zum Beispiel, um eine Datei aus der gesamten Historie zu entfernen oder das Repository auf ein bestimmtes Unterverzeichnis zu reduzieren, um daraus ein separates Projekt zu erstellen.
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 den Abschnitten ch07-git-tools.asc, ch07-git-tools.asc und ch07-git-tools.asc, um einen direkteren bzw. roheren Blick darauf zu werfen, wie dein Staging-Bereich aussieht.
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.