Git

aus Wikipedia, der freien Enzyklopädie

Wechseln zu: Navigation, Suche
Wikipedia:Hauptseite
 Dieser Artikel beschreibt eine Versionsverwaltungssoftware. Für andere Bedeutungen des Wortes Git siehe GIT (Begriffsklärung).
Git
Logo von Git
Entwickler: Junio Hamano, und viele andere
Aktuelle Version: 1.6.3.2
(4. Juni 2009)
Betriebssystem: unixoide Systeme, Microsoft Windows
Kategorie: Versionsverwaltung
Lizenz: GPL
Deutschsprachig: nein
http://git-scm.com/

Git ist ein freies verteiltes Versionskontrollsystem. Es wurde ursprünglich für die Verwaltung des Linux-Kernels entwickelt.

Die Entwicklung von Git wurde im April 2005 von Linus Torvalds begonnen, um das bis dahin verwendete Versionskontrollsystem BitKeeper zu ersetzen, welches durch eine Lizenzänderung vielen Entwicklern den Zugang verwehrte. Die erste Version erschien bereits wenige Tage nach der Ankündigung. Die derzeit aktuelle Version wird produktiv für die Entwicklung des Linux-Kernels und vieler weiterer Projekte eingesetzt. Derzeitiger Maintainer von Git ist Junio Hamano.

Git läuft auf fast allen modernen UNIX-artigen Systemen, wie Linux, Solaris, Mac OS X, FreeBSD, DragonFlyBSD, NetBSD, OpenBSD, AIX und IRIX. Auf Microsoft Windows läuft es entweder mit Hilfe der Cygwin-Umgebung oder mit Msysgit, bzw. der seit einiger Zeit verfügbaren TortoiseGit-Shell-Erweiterung (ähnlich TortoiseSVN).

Mittlerweile wird Git − neben dem Linux-Kernel − von vielen bekannten Projekten genutzt, darunter Samba, X.Org, Qt, GNOME, One Laptop per Child, Ruby on Rails, VLC, Wine, LilyPond, TaskJuggler, DragonFly BSD, Android, Perl 5[1] und x264[2].

Inhaltsverzeichnis

[Bearbeiten] Eigenschaften

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

  • Nicht-lineare Entwicklung: Sowohl das Erstellen neuer Entwicklungszweige (branching) sowie das Verschmelzen zweier oder mehrerer Zweige (merging) sind integraler Bestandteil der Arbeit mit Git und sind fest in die Git-Werkzeuge eingebaut.[3] 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.
  • Kein zentraler Server: Jeder Benutzer besitzt eine lokale Kopie des gesamten Repositories, 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, gibt es in der Regel einen gesellschaftlichen Unterschied: Die Kopie, auf die von einer Projekt-Homepage aus verwiesen wird, gilt häufig als das „offizielle Repository”.
  • Datentransfer zwischen Repositories: Daten können mit einer Reihe verschiedener Protokolle zwischen Repositories übertragen werden. Git besitzt ein eigenes Protokoll, das den TCP-Port 9418 nutzt. Ebenso kann der Transfer über SSH oder (weniger effizient) über HTTP, HTTPS, FTP oder rsync erfolgen.[4] 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.[5]
  • Kryptographische Sicherheit der Projektgeschichte: Die Geschichte eines Projektes wird so gespeichert, dass der Name 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 Name der Revision ändert. Einzelne Revisionen können zusätzlich markiert und mit GPG digital signiert werden (tagging), beispielsweise um den Zustand zum Zeitpunkt der Veröffentlichung einer neuen Version der Software zu kennzeichnen.
  • Verzeichnisbasiertes Verständnis: Im Gegensatz zu traditionellen Versionskontrollsystemen wie SCCS, RCS und CVS arbeitet Git nicht auf einzelnen Dateien, sondern auf Verzeichnissen und Hierarchien von Verzeichnissen.
  • Säubern des Repositories: 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 existieren eine Reihe von Hilfsprogrammen, die Interoperabilität zwischen Git und anderen Versionskontrollsystemen herstellen. Entsprechende Hilfsprogramme existieren für GNU arch (git-archimport), CVS (git-cvsexportcommit, git-cvsimport und git-cvsserver), Quilt (git-quiltimport) und Subversion (git-svn).

[Bearbeiten] Geschichte

Die Git-Entwicklung wurde notwendig, nachdem viele Linux-Kernel-Entwickler gezwungen waren, die kostenlose Verwendung des proprietären BitKeeper-Systems aufzugeben.

Torvalds wünschte sich ein verteiltes System, welches er wie BitKeeper nutzen konnte und folgende Anforderungen erfüllte:

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

Die ersten zwei Anforderungen konnte ein bereits existierendes Projekt namens Monotone erfüllen.[6] Das dritte Kriterium konnte damals von keinem bestehendem System erfüllt werden.

Torvalds entschied sich dagegen, Monotone an seine Anforderungen anzupassen und begann stattdessen, ein eigenes System – Git – zu schreiben. 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, „cherry picking” genannt (englisch für „Kirschen pflücken”), dazu führen würde, dass Repositories „unaufgeräumt” bleiben würden. Wenn hingegen immer ganze Zweige importiert werden, würden 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 [6]

Gits Gestaltung verwendet einige Ideen aus Monotone, aber keinen Source-Code daraus.

[Bearbeiten] Einzelnachweise

  1. ↑ Projekte die Git benutzen (engl.)
  2. ↑ http://git.videolan.org/gitweb.cgi?p=x264.git
  3. ↑ http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#repositories-and-branches
  4. ↑ http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#exporting-via-http
  5. ↑ http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#submitting-patches
  6. ↑ a b Kernel SCM saga..

[Bearbeiten] Weblinks

Von „http://de.wikipedia.org/wiki/Git“
Persönliche Werkzeuge
Buch erstellen