 "AA_hemden_123rf-406942_Kirill_Zdorov.png")
Kernel-Guru Greg Kroah-Hartmann hat fleißig gezählt: Im Jahr 2007 wuchs der Linux Kernel am Tag im Schnitt um 4500 Zeilen Quelltext – mittlerweile dürften es eher noch mehr sein. Um den Überblick über den Code zu behalten, verwenden die Kernel-Entwickler Git [1]. Dabei handelt es sich um ein sogenanntes Version Control System (VCS), das im Prinzip ähnlichen Systemen wie CVS (Concurrent Versions System, [2]) oder SVN (Subversion [3]) entspricht. Allerdings ist Git, verglichen mit diesen Werkzeugen, wesentlich mächtiger – und komplizierter.
Wenn Sie auf der Suche nach einer Versionsverwaltung für Ihr eigenes Softwareprojekt sind, ist Git sicher einen Blick wert. Dieser Artikel verschafft Ihnen einen Überblick über die grundlegenden Funktionen der Torvaldsschen Erfindung und verrät Ihnen, wie Sie eigene Repositories anlegen und verwenden oder auf jene anderer Entwickler zugreifen und deren Änderungen in Ihr eigenes Git-Verzeichnis übernehmen. Einen historischen Überblick über die Versionskontrolle des Linux-Kernels im Allgemeinen und von Git im Speziellen zeigt der Kasten "Git: Not macht erfinderisch".
Kleines Git-Glossar
Der folgende Abschnitt erklärt wichtige Begriffe im Zusammenhang mit Git. Kennen Sie bereits andere Versionskontrollsysteme, dann meinen die Begriffe dort möglicherweise etwas anderes als bei Git.
Repository: Die Oberbezeichnung für einen kompletten Baum sämtlicher Dateien und der gesamten History eines spezifischen Programms. Linus Torvalds entwickelt Linux beispielsweise in einem Repository namens linux-2.6. Um ein Projekt mit Git zu verwalten, benötigen Sie immer ein solches Repository.
Branch: Ein Entwicklungszweig in einem Repository. Branches entstehen, um den Inhalt eines Repositories in unterschiedliche Richtungen weiter zu entwickeln. Ganz typische Beispiele für Branches sind die stabilen und die Entwicklungszweige von Programmen. Beide Branches befinden sich im gleichen Repository, der Code der Branches kann sich aber deutlich unterscheiden. Bei der Arbeit mit Git arbeiten Sie immer in einem Branch; legen Sie keinen neuen explizit an, befinden Sie sich im master-Branch. Branches lassen sich miteinander ganz oder teilweise synchronisieren; in solchen Fällen spricht man von "Branch Merges". Der Begriff "Merge" meint allgemein das Zusammenführen von Veränderungen aus verschiedenen Quellen.
Tag: Ein Alias für den Zustand eines Branches (zum Beispiel des master-Branches) zu einem Zeitpunkt X.
Commit: Dieser Begriff steht für das Einpflegen einer lokalen Änderung in das Versionskontrollsystem. Entwickler arbeiten mit lokalen Verzeichnissen. Dort vorgenommene Änderungen landen nicht automatisch im VCS. Erst nach einem Commit durch einen Entwickler stehen die Modifikationen im VCS bereit, sodass dort auch für andere bereitstehen.
Los geht's
Als Anschauungsobjekt für diesen Artikel dient der Linux-Kernel. Sie erfahren, wie Sie auf einem Server ein Repository auf Grundlage des offiziellen Linux-2.6-Repositories erstellen und wie Sie einen lokalen Checkout dieses Repositories erstellen, Modifikationen vornehmen und diese zurück in das Repository auf dem Server spielen. Git funktioniert dezentral, was den Entwicklern ermöglicht, jederzeit mit einer lokalen Kopie eines Repositories zu arbeiten. Damit auch andere etwas davon haben, sollten Sie die Änderungen aber in einem Repository veröffentlichen.
Git ist seit Längerem Bestandteil der großen Distributionen wie OpenSuse, Ubuntu, Fedora oder Mandriva. Entsprechend verwenden Sie zur Installation den Paketmanager Ihrer Distribution. Installieren Sie darüber hinaus auch das Git-Webfrontend git-web. Um die korrekte Installation zu prüfen, geben Sie den Aufruf git help in der Konsole ein, worauf das Programm die Hilfeseite anzeigt (Abbildung 1).
Abbildung 1: Nach der Installation von Git zeigt die Eingabe von git help auf der Kommandozeile diese Ausgabe.
Bevor Sie Repositories anlegen oder modifizieren, müssen Sie Git erst einmal grundlegend konfigurieren. Dazu gehört die Angabe Ihres Namens und Ihrer E-Mail-Adresse, die später zum festen Bestandteil eines jeden Git-Commits werden. Optional teilen Sie Git mit, welchen Editor Sie bevorzugen. Die notwendigen Befehle zeigt Listing 1. Git legt damit in Ihrem persönlichen Verzeichnis eine Datei namens .gitconfig an, die diese Angaben enthält.
Listing 1
$ git config --global user.name "Ihr Name " $ git config --global user.email ihrname @beispiel .de $ git config --global core.editor vim $ git config --global color.branch "auto" $ git config --global color.status "auto" $ git config --global color.diff "auto"
Den Git-Server installieren
Dieser Artikel geht davon aus, dass Sie ein öffentliches Git-Verzeichnis anlegen, auf das prinzipiell jedermann lesend zugreifen darf. Entwickler mit eigenem Account auf dem Server dürfen außerdem ihre Änderungen in Form von Commits in das Git-Repository einspielen. Damit das klappt, brauchen Sie zunächst den Git-Server.
Legen Sie einen Ordner an, der Ihre Git-Repositories enthält, etwa /home/git, und bestimmen Sie als besitzende Gruppe und User jeweils git. Sofern noch nicht vorhanden, installieren Sie danach einen Inetd-Daemon und öffnen dessen Konfiguration /etc/inetd.conf. Dort tragen Sie die folgende Zeile ein:
git stream tcp nowait gitserver /usr/bin/git-daemon git-daemon --inetd --verbose --base-path=/home/git
Damit ist der Git-Daemon eingerichtet. Zugriff auf die Repositories erhalten Sie und andere später über die URL http://server
/name
. Heißt ein Repository also linux-2.6-local und der Hostname des Servers git.example.org, wäre die vollständige URL für das Repository entsprechend http://git.example.org/linux-2.6-local. Der zugehörige Ordner im Dateisystem wäre dann /home/git/linux-2.6-local.
Beachten Sie: Je nach verwendeter Distribution ist die Funktion export-all entweder aktiv oder abgeschaltet. Ist sie aus, führt das dazu, dass der Git-Daemon nicht alle Ordner in /home/git automatisch erfasst. Um sicherzustellen, dass der Git-Daemon ein Repository immer exportiert, legen Sie im Ordner des Repositories auf Ihrem Server die Datei git-daemon-export-ok an.
Einem Freund empfehlen
