Git ist ein verteiltes Versionsverwaltungssystem, das sich in einigen Eigenschaften von typischen Versionskontrollsystemen unterscheidet:
Nicht-lineare Entwicklung
Sowohl das Erstellen neuer Entwicklungszweige (branching), als auch das Verschmelzen zweier oder mehrerer Zweige (merging) sind integrale Bestandteile der Arbeit mit Git und fest in die Git-Werkzeuge eingebaut. Git enthält Programme, mit deren Hilfe sich die nicht-lineare Geschichte eines Projektes einfach visualisieren lässt und mit deren Hilfe man in dieser Geschichte navigieren kann. Branches in Git sind (im Gegensatz zu anderen SCMs) sehr performant implementiert: Ein Branch stellt nur eine Reference, kurz ref, eine Textdatei mit einer Commit-ID, dar, die in einem Repository im Verzeichnis .git/refs/heads (z. B. .git/refs/heads/master für den immer vorhandenen master-Branch) liegt und auf einen bestimmten Commit verweist. Über dessen Parental Commits, also Eltern-Commits, lässt sich die Branch-Struktur rekonstruieren. Durch diese Eigenschaften lassen sich weiterhin sehr große und effiziente Entwicklungsstrukturen, wie bei Git selbst oder dem Linux-Kernel, realisieren, bei denen jedes Feature und jeder Entwickler einen Branch oder ein eigenes Repository haben, aus dem der Maintainer dann Commits über Merge oder Cherry-pick (Nutzen einzelner Commits) in den Hauptzweig des Projekts (master) übernehmen kann.
Kein zentraler Server
Jeder Benutzer besitzt eine lokale Kopie des gesamten Repositorys, inklusive der Versionsgeschichte (history). So können die meisten Aktionen lokal und ohne Netzwerkzugriff ausgeführt werden. Es wird nicht zwischen lokalen Entwicklungszweigen und Entwicklungszweigen entfernter Repositories unterschieden. Obwohl es keinen technischen Unterschied zwischen verschiedenen Repositories gibt (außer dem zwischen normalen und bare-Repositories auf Servern, bei denen kein Working-Tree, also die echten Dateien existiert), gilt die Kopie, auf die von einer Projekt-Homepage aus verwiesen wird, häufig als das offizielle Repository, in das die Revisionen der Entwickler übertragen werden. Es existieren spezielle Remote-tracking branches, das sind Referenzen (siehe Nicht-lineare Entwicklung), die auf den Stand eines anderen Repositorys zeigen.
Datentransfer zwischen Repositorys
Daten können neben dem Übertragen auf Dateisystemebene (file://) mit einer Reihe verschiedener Netzwerkprotokolle zwischen Repositorys übertragen werden. Git hat ein eigenes sehr effizientes Protokoll, das den TCP-Port 9418 nutzt (git://), allerdings nur zum Fetchen und Clonen genutzt werden kann, also dem Lesen eines Repositorys. Ebenso kann der Transfer über SSH (ssh://, das gängigste Protokoll für Schreiboperationen), HTTP (http://), HTTPS (https://) oder über (weniger effizient) FTP (ftp://) oder rsync (rsync://) erfolgen.[8] Die Übertragung in das offizielle Repository eines Projekts erfolgt häufig in Form von Patches, die via E-Mail an den Entwickler oder eine Entwicklungs-Mailing-Liste geschickt werden. Alternativ kann auch ein Review-System wie Gerrit verwendet werden. Für Projekte, die auf Websites wie GitHub oder Bitbucket gehostet werden, kann eine Änderung einfach durch das Pushen eines Branches vorgeschlagen werden, der dann bei Bedarf durch ein Merge in das Projekt integriert wird.
Kryptographische Sicherheit der Projektgeschichte
Die Geschichte eines Projektes wird so gespeichert, dass der Hash einer beliebigen Revision (commit) auf der vollständigen Geschichte basiert, die zu dieser Revision geführt hat. Dadurch ist es nicht möglich, die Versionsgeschichte nachträglich zu manipulieren, ohne dass sich der Hash der Revision ändert. Einzelne Revisionen können zusätzlich markiert (tagging) und optional mit GPG digital signiert werden (signed tag), beispielsweise um den Zustand zum Zeitpunkt der Veröffentlichung einer neuen Version der Software zu kennzeichnen.
Speichersystem und Dateiversionierung
Es gibt Versionsverwaltungssysteme (beispielsweise CVS), die für jede Datei (und jedes Verzeichnis) eigene, von allen anderen Dateien unabhängige Revisionsnummern verwalten. Für eine Datei wird nur dann eine neue Nummer erzeugt, wenn die jeweilige Datei Teil einer Commit-Operation ist. Im Gegensatz dazu weist Git bei jedem Commit allen im Repository verwalteten Dateien (und Verzeichnissen) eine neue, für alle Dateien gleiche Revisionsnummer zu. Das Abspeichern selbst erfolgt, indem im Commit-Objekt ein Verweis auf die Projektwurzel als tree-Objekt gespeichert wird, das wiederum Verweise auf blobs (binary large objects, die reinen Inhalte der Dateien ohne Identifizierung) und weitere trees (Verzeichnisse) enthält. Ein tree-Objekt verweist (wie ein Verzeichnis-Inode) mit seinen Einträgen auf SHA1-Checksummen, die weitere trees und blobs identifizieren, ähnlich Inode-Nummern in Dateisystemen. Wenn eine Datei in einem Commit nicht geändert wird, ändert sich auch die Checksumme nicht und sie muss nicht nochmals gespeichert werden. Die Objekte liegen im Projekt unter .git/objects. Über Git-„Bordmittel“ lässt sich jeder beliebige Commit über den zugeordneten Hash (die Prüfsumme/Checksumme) eindeutig identifizieren, separat auslesen, verschmelzen oder gar als Abzweigungspunkt nutzen – vergleichbar mit den Revisionsnummern in anderen Systemen.
Säubern des Repositorys
Die Daten gelöschter und zurückgenommener Aktionen und Entwicklungszweige bleiben vorhanden (und können wiederhergestellt werden), bis sie explizit gelöscht werden.
Interoperabilität
Es gibt Hilfsprogramme, die Interoperabilität zwischen Git und anderen Versionskontrollsystemen herstellen. Solche Hilfsprogramme existieren unter anderem für GNU arch (git-archimport), CVS (git-cvsexportcommit, git-cvsimport und git-cvsserver), Darcs (darcs-fastconvert, darcs2git und andere), Quilt (git-quiltimport) und Subversion (git-svn).
Web-Interface
Mit Gitweb gibt es eine in Perl geschriebene Weboberfläche. Der Team Foundation Server von Microsoft verfügt über eine Git-Anbindung (Git-tf).
