Die Merge-Basis zweier Commits ist ihr bester gemeinsamer Vorfahre: das Fundament, das Git für Three-Way-Merges verwendet. Die richtige Basis zu wählen ist es, was "automatische" Merges überhaupt funktionieren lässt.
Wenn Git zwei Änderungen am selben Bereich einer Datei nicht automatisch kombinieren kann, hinterlässt es Konfliktmarker in der Arbeitskopie und lässt Sie manuell auflösen. Die Marker sind keine Magie; sie zeichnen genau auf, was jede Seite relativ zu einer gemeinsamen Basis getan hat.
git push lädt Commits auf einen Remote hoch und aktualisiert dessen Refs. Anders als fetch ändert er den Zustand auf dem Server, weshalb Sicherheitsmechanismen existieren, um das Überschreiben der Arbeit anderer zu verhindern.
git pull ist Zucker für git fetch gefolgt von der Integration des Upstream-Branches in den aktuellen Branch. Der Integrationsschritt ist entweder ein Merge (Standard) oder ein Rebase.
Die zwei Schritte
git fetch <remote> <refspec>: herunterladen und Tracking-Refs aktualisieren.
git fetch ist die Netzwerkoperation, die neue Objekte herunterlädt und Remote-Tracking-Refs aktualisiert. Sie ändert Ihre Branches oder den Working Tree nicht, was sie zum sichersten "Was gibt es Neues?"-Befehl macht.
git clone sieht aus wie eine Operation, setzt sich aber tatsächlich aus mehreren zusammen. Die Schritte zu verstehen hilft beim Troubleshooting partieller Klone, langsamer Klone oder überraschender Voreinstellungen.
Git unterstützt zwei Arten von Tags: Lightweight, die nur Refs sind, die auf Commits zeigen, und Annotated, die vollständige Git-Objekte mit Metadaten sind. Verwenden Sie für Releases Annotated Tags.
Git führt mehrere spezielle "Hilfs"-Refs in .git/, um den Zustand mehrstufiger Operationen aufzuzeichnen. Sie zu kennen verwandelt beängstigende Wiederherstellungen in Einzeiler.
ORIG_HEAD
ORIG_HEAD wird gesetzt, wenn eine "gefährliche" Operation HEAD stark bewegt: merge, rebase, reset, am. Es erfasst die vorherige Spitze, sodass Sie zurücksetzen können:
Git speichert Objekte in zwei Formaten: lose (eine Datei pro Objekt unter .git/objects/xx/yyyy...) und gepackt (viele Objekte in einer einzigen .pack-Datei mit begleitender .idx). Packs sind weit effizienter auf Festplatte und im Netz.
Ein Git-Commit referenziert null, einen oder mehrere Eltern-Commits. Die gesamte Historie ist ein gerichteter azyklischer Graph (DAG) dieser Eltern-Verknüpfungen. Branches und Tags sind einfach Labels auf Knoten dieses Graphen.
Anatomie einer Eltern-Verknüpfung
git cat-file -p HEAD
# tree 9f1a...
# parent b2c3...
# parent d4e5... (nur bei Merge-Commits)
# author Ada ...
# committer Ada ...
Ein Elternteil: lineare Historie. Zwei Eltern: ein Merge. Null Eltern: ein Wurzel-Commit. Drei oder mehr: ein Octopus-Merge.