Git

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche
Der Titel dieses Artikels ist mehrdeutig. Weitere Bedeutungen sind unter Git (Begriffsklärung) aufgeführt.
Git
Logo
Entwickler Junio C. Hamano, Shawn O. Pearce, Linus Torvalds und viele andere
Aktuelle Version 2.1.2
(30. September 2014)
Betriebssystem Linux und andere Unixoide Systeme, Microsoft Windows
Programmier­sprache C, Bourne-Shell, Perl
Kategorie Versionsverwaltung
Lizenz GNU GPLv2
Deutschsprachig ja[1]
git-scm.com

Git ([ɡɪt], engl. Blödmann) ist eine freie Software zur verteilten Versionsverwaltung von Dateien, die ursprünglich für die Quellcode-Verwaltung des Linux-Kernels entwickelt wurde.

Eigenschaften[Bearbeiten]

Git ist ein verteiltes Versionsverwaltungssystem, das sich in einigen Eigenschaften von typischen Versionskontrollsystemen unterscheidet:

Nicht-lineare Entwicklung[Bearbeiten]

Entwicklungsgeschichte mit extensiv genutztem Branching und Merging

Sowohl das Erstellen neuer Entwicklungszweige (branching), als auch das Verschmelzen zweier oder mehrerer Zweige (merging) sind integraler Bestandteil der Arbeit mit Git und fest in die Git-Werkzeuge eingebaut.[2] 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 Elterncommits, lässt sich die Branchstruktur 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[Bearbeiten]

Dezentrale Verwaltung des gesamten Repositorys mit Hilfe von GIT.

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-Repositorys 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 Repositories[Bearbeiten]

Daten können neben dem Übertragen auf Dateisystemebene (file://) mit einer Reihe verschiedener Netzwerkprotokolle zwischen Repositories übertragen werden. Git besitzt 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.[3] 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.[4]

Kryptographische Sicherheit der Projektgeschichte[Bearbeiten]

Korrumpiertes Objekt

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[Bearbeiten]

Im Gegensatz zu CVS, wo jede Datei eine eigene Revisionsnummer besitzt, speichert Git bei einem Commit das gesamte Verzeichnis ab. 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 nicht die Checksumme, 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 Repositories[Bearbeiten]

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[Bearbeiten]

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[Bearbeiten]

Gitweb mit den Unterschieden zwischen zwei Commits

Mit Gitweb gibt es eine in Perl geschriebene Weboberfläche. Der Team Foundation Server von Microsoft verfügt über eine Git-Anbindung (Git-tf).

Verwendung[Bearbeiten]

Die aktuelle Version wird produktiv für die Entwicklung vieler Open-Source-Projekte eingesetzt, darunter Amarok, Android, BusyBox, CMake, Debian, DragonFly BSD, Drupal, Eclipse, Erlang, Fedora, Git selbst, Gnome, Joomla, jQuery, JUnit, KDE, LibreOffice, LilyPond, Linux-Kernel, Linux Mint, MediaWiki, node.js, One Laptop per Child, OpenFOAM, Perl 5, Parrot und Rakudo (Perl 6), PHP, phpBB[5], Plone, PostgreSQL, Qt, Ruby on Rails, Ruby, Samba, Scala, TaskJuggler, TYPO3, VLC media player, Wine, x264[6] und X.org. Außerdem wird Git von einer Vielzahl weiterer Open-Source-Projekte genutzt, wie sie beispielsweise auf Plattformen wie GitHub, GitLab[7] und Gitorious zu finden sind.

Verwaltung von Inhalt[Bearbeiten]

Obwohl git primär zur Versionsverwaltung von Quellcode entwickelt wurde, wird es auch zum Speichern von flach strukturierten (im Gegensatz zu relationalen Strukturen) Datensätzen direkt als Datei genutzt. So können Funktionen wie Versionsverwaltung, Hook, diff, Replikation und Offline-Nutzung auch für Inhalte ohne Datenbank genutzt werden.[8]. Die Nutzung ist ähnlich NoSQL, auch wenn git keine Indexstruktur, Abfrage oder Gleichzeitigkeit erlaubt.

Der Einsatz erstreckt sich auch auf inhaltlich einfach strukturierte Systeme wie CMS[8] oder Wikis[9][10].

Unterstützte Betriebssysteme[Bearbeiten]

Git läuft auf fast allen modernen unixartigen Systemen, wie Linux, Solaris, Mac OS X, FreeBSD, DragonFly BSD, NetBSD, OpenBSD, AIX, IRIX und Haiku. Unter Microsoft Windows kann es nativ mit dem Client von GitHub[11] verwendet werden, oder mit Hilfe der Cygwin-Umgebung, mit Msysgit oder der TortoiseGit-Shell-Erweiterung (ähnlich TortoiseSVN).

Geschichte[Bearbeiten]

Durch eine Lizenzänderung des bis dahin genutzten, proprietären BitKeeper-Systems konnten die Linux-Kernel-Entwickler dieses nicht mehr kostenlos verwenden und somit blieb vielen Entwicklern der Zugang verwehrt. Daher begann Linus Torvalds im April 2005 mit der Entwicklung einer neuen Quellcode-Management-Software und präsentierte bereits wenige Tage nach deren Ankündigung eine erste Version.

Altes Logo

Torvalds wünschte sich ein verteiltes System, das wie BitKeeper genutzt werden konnte und die folgenden Anforderungen erfüllte:

  1. Unterstützung verteilter, BitKeeper-ähnlicher Arbeitsabläufe
  2. Sehr hohe Sicherheit gegen sowohl unbeabsichtigte als auch böswillige Verfälschung
  3. Hohe Effizienz

Ein bereits existierendes Projekt namens Monotone entsprach den ersten zwei Anforderungen,[12] das dritte Kriterium wurde jedoch von keinem bestehenden System erfüllt.

Torvalds entschied sich dagegen, Monotone an seine Anforderungen anzupassen, und begann stattdessen, ein eigenes System zu entwickeln. Einer der Hauptgründe für diesen Schritt war die Arbeitsweise, für die Monotone nach Torvalds Ansicht optimiert ist. Torvalds argumentierte, dass einzelne Revisionen von einem anderen Entwickler in den eigenen Entwicklungszweig zu importieren zu Rosinenpickerei und „unordentlichen“ Repositories führen würde. Wenn hingegen immer ganze Zweige importiert werden, wären Entwickler gezwungen aufzuräumen. Dazu seien „Wegwerf-Zweige“ notwendig.

“This is my only real conceptual gripe with ‘monotone’. I like the model, but they make it much harder than it should be to have throw-away trees due to the fact that they seem to be working on the assumption of ‘one database per developer’ rather than ‘one database per tree’. You don't have to follow that model, but it seems to be what the setup is geared for, and together with their ‘branches’ it means that I think a monotone database easily gets very cruddy. The other problem with monotone is just performance right now, but that's hopefully not _too_ fundamental.”

Linus Torvalds[12]

Gits Gestaltung verwendet einige Ideen aus Monotone sowie BitKeeper, aber keinen Quellcode daraus. Es soll ausdrücklich ein eigenständiges Versionsverwaltungssystem sein.

Derzeitiger Maintainer von Git ist Junio Hamano.

Name[Bearbeiten]

Der Name „Git“ bedeutet in der britischen Umgangssprache soviel wie „Blödmann“. Linus Torvalds erklärte seine Wahl des ungewöhnlichen Namens mit einem Witz, sowie damit, dass das Wort praktikabel und in der Softwarewelt noch weitgehend unbenutzt war:

“I’m an egotistical bastard, and I name all my projects after myself. First ‘Linux’, now ‘Git’.”

Linus Torvalds [13]

“The joke ‘I name all my projects for myself, first Linux, then git’ was just too good to pass up. But it is also short, easy-to-say, and type on a standard keyboard. And reasonably unique and not any standard command, which is unusual.”

Linus Torvalds [14]

Der Name Linux wurde anfangs nicht von Torvalds selbst propagiert und nur widerwillig akzeptiert.[15]

Siehe auch[Bearbeiten]

Literatur[Bearbeiten]

  •  Valentin Haenel, Julius Plenz: Git – Verteilte Versionsverwaltung für Code und Dokumente. Open Source Press, München 2011. ISBN 3-941841-42-4
  •  Sven Riedel: Git – kurz & gut. O'Reilly Verlag, Köln 2009. ISBN 3-89721-914-X
  •  Jon Loeliger, Matthew McCullough: Version Control with Git. 2. Auflage. O'Reilly Media, Sebastopol 2012. ISBN 978-1-4493-1638-9 eBook
  •  Scott Chacon: Pro Git. APress, New York 2009. ISBN 1-4302-1833-9

Weblinks[Bearbeiten]

 Commons: Git – Sammlung von Bildern, Videos und Audiodateien

Einzelnachweise[Bearbeiten]

  1. https://github.com/git/git/blob/master/po/de.po
  2. http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#repositories-and-branches
  3. http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#exporting-via-http
  4. http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#submitting-patches
  5. phpBB moves source code versioning from Subversion to Git. 7. März 2010, abgerufen am 13. September 2011 (englisch).
  6. git.videolan.org Git – x264.git summary. Abgerufen am 13. September 2011 (englisch).
  7. Explore GitLab. Abgerufen am 10. September 2014 (englisch).
  8. a b https://speakerdeck.com/bkeepers/git-the-nosql-database
  9. http://blog.assembla.com/assemblablog/tabid/12618/bid/104945/How-we-Moved-2-3-Million-Wiki-Pages-to-Git.aspx
  10. https://github.com/gollum/gollum
  11. GitHub stellt Windows-Client vor, heise.de News, zuletzt abgerufen am 22. Mai 2012
  12. a b Linus Torvalds: Kernel SCM saga.. In: Linux-Kernel Archive. 6. April 2005, abgerufen am 13. September 2011 (englisch).
  13. https://git.wiki.kernel.org/index.php/GitFaq#Why_the_.27Git.27_name.3F
  14. Lord of the Files: How GitHub Tamed Free Software (And More). 6. April 2005, abgerufen am 24. Februar 2012 (englisch).
  15. Siehe dazu Geschichte von Linux#Der Name Linux