Git
| Git | |
|---|---|
| Entwickler | Junio C. Hamano, Shawn O. Pearce, Linus Torvalds und viele andere |
| Aktuelle Version | 1.7.9 (27. Januar 2012) |
| Betriebssystem | Unixoide Systeme, Microsoft Windows |
| Programmiersprache | C, Bourne-Shell, Perl |
| Kategorie | Versionsverwaltung |
| Lizenz | GNU General Public License |
| Deutschsprachig | Nein |
| git-scm.com | |
Git (dt. [ɡɪt]) ist eine freie Software zur verteilten Versionsverwaltung von Dateien, die ursprünglich für die Quellcode-Verwaltung des Kernels Linux entwickelt wurde.
Die Entwicklung von Git wurde im April 2005 von Linus Torvalds begonnen, um das bis dahin verwendete Versionskontrollsystem BitKeeper zu ersetzen, das durch eine Lizenzänderung vielen Entwicklern den Zugang verwehrte. Die erste Version erschien bereits wenige Tage nach der Ankündigung. Derzeitiger Maintainer von Git ist Junio Hamano.
Git läuft auf fast allen modernen UNIX-artigen Systemen, wie Linux, Solaris, Mac OS X, FreeBSD, DragonFly BSD, NetBSD, OpenBSD, AIX und IRIX. Auf Microsoft Windows läuft es mit Hilfe der Cygwin-Umgebung, mit Msysgit oder der TortoiseGit-Shell-Erweiterung (ähnlich TortoiseSVN).
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) als auch das Verschmelzen zweier oder mehrerer Zweige (merging) sind integraler Bestandteil der Arbeit mit Git, fest in die Git-Werkzeuge eingebaut und sehr performant.[1] 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/masterfü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
-
Dezentrale Verwaltung des gesamten Repositories mit Hilfe von GIT. - 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 (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.
- 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.[2] 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.[3]
- 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.
- 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 gibt Hilfsprogramme, die Interoperabilität zwischen Git und anderen Versionskontrollsystemen herstellen. Solche Hilfsprogramme existieren 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 existiert eine in Perl geschriebene Weboberfläche
[Bearbeiten] Geschichte
Die Git-Entwicklung wurde notwendig, nachdem die Linux-Kernel-Entwickler gezwungen waren, die kostenlose Verwendung des proprietären BitKeeper-Systems aufzugeben.
Torvalds wünschte sich ein verteiltes System, das wie BitKeeper genutzt werden konnte und die folgenden Anforderungen erfüllte:
- Unterstützung verteilter, BitKeeper-ähnlicher Arbeitsabläufe
- Sehr hohe Sicherheit gegen sowohl unbeabsichtigte als auch böswillige Verfälschung
- Hohe Effizienz
Ein bereits existierendes Projekt namens Monotone entsprach den ersten zwei Anforderungen[4], 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 – 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, zu Rosinenpickerei und „unordentlichen” Repositories führen würde. 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[4]
Gits Gestaltung verwendet einige Ideen aus Monotone sowie BitKeeper, aber keinen Quellcode daraus. Es soll ausdrücklich ein eigenständiges Versionsverwaltungssystem sein.
[Bearbeiten] Verwendung
Die derzeit aktuelle Version wird produktiv für die Entwicklung vieler Open-Source-Projekte eingesetzt, darunter Amarok, Android, BusyBox, Debian, DragonFly BSD, Eclipse, Erlang, Fedora, Git selbst, Gnome, jQuery, JUnit, KDE, LilyPond, Linux Kernel, Linux Mint, node.js, One Laptop per Child, Perl 5, Parrot und Rakudo (Perl 6), PHP, phpBB,[5] PostgreSQL, Qt, Ruby on Rails, Ruby, Samba, TaskJuggler, VLC media player, Wine, x264,[6], X.org und Drupal. Außerdem wird Git von sehr vielen kleineren Hobby-Projekten genutzt.
[Bearbeiten] Siehe auch
- GitHub – Webbasierter Hosting-Dienst für Git-Projekte
- SCCS – Der POSIX-Standard für Versionsverwaltung
- Monotone – Verteiltes Versionsverwaltungssystem
- BitKeeper – Verteiltes Versionsverwaltungssystem
- Mercurial – Verteiltes Versionsverwaltungssystem
- Bazaar – Verteiltes Versionsverwaltungssystem
- Apache Subversion – Zentrales Versionsverwaltungssystem
[Bearbeiten] Literatur
- Valentin Haenel, Julius Plenz: Git – Verteilte Versionsverwaltung für Code und Dokumente. Open Source Press, 2011, ISBN 978-3-941841-42-0.
- Sven Riedel: Git – kurz & gut. O’Reilly, 2009, ISBN 978-3-89721-914-4.
- Scott Chacon: Pro Git. APress, 2009, ISBN 978-1-4302-1833-3.
[Bearbeiten] Weblinks
- Git Homepage – Offizielle Webpräsenz von Git
- Git documentation – Git-Dokumentation auf der Git-Homepage
- Detaillierte und sortierte Git-Dokumentation
- Warum Git besser als X ist – Vorteile von Git im Vergleich zu anderen Versionskontrollsystemen
- Git – Randal Schwartz über Git, 12. Oktober 2007 (englisch, Flash Video)
- Linus Torvalds on Git – Linus Torvalds über Git bei einem Google Tech Talk, 3. Mai 2007 (englisch, YouTube Video)
- Befehlsreferenz – Für die wichtigsten Anwendungsfälle (deutsch, Wiki)
- Verteilte Versionskontrollsysteme – Chaosradio Express über Verteilte Versionskontrollsysteme und GIT im Besonderen
- Themenschwerpunkt Git – Anleitungen zum Arbeiten mit Git (deutsch, Thomas Krenn Wiki)
[Bearbeiten] Einzelnachweise
- ↑ http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#repositories-and-branches
- ↑ http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#exporting-via-http
- ↑ http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#submitting-patches
- ↑ a b Linus Torvalds: Kernel SCM saga.. In: Linux-Kernel Archive. 6. April 2005, abgerufen am 13. September 2011 (englisch).
- ↑ phpBB moves source code versioning from Subversion to Git. 7. März 2010, abgerufen am 13. September 2011 (englisch).
- ↑ git.videolan.org Git - x264.git summary. Abgerufen am 13. September 2011 (englisch).