„Git“ your work done and don´t mess with your team!

Verteilte Versionsverwaltung mit GIT

Wichtigstes Tool für die Softwareentwicklung im Team ist eine funktionierende Versionsverwaltung. Nach den zentralisierten Systemen CVS, Subversion und anderen, ist aktuell das verteilte System Git das Tool der Wahl mit coolen neuen Features. Es ist besonders gut geeignet für große, verteilte OpenSource-Projekte, um viel Diskussion um Commit-Zugänge zu vermeiden und es jedem Entwickler einfach zu machen, seinen Code hochzuladen ohne alles kaputt zu machen. Bei Git gibt es kein zentrales Repository, sondern viele verteilte Branches die untereinander ausgetauscht werden können.

Git ist Open Source und wurde ursprünglich für die Quellcode-Verwaltung des Linux-Kernels entwickelt. Durch eine Lizenzveränderung des damals benutzten BitKeeper-Systems, konnten die Linux-Entwickler dies nicht mehr kostenlos verwenden, weshalb der Linux-Erfinder Linus Torvalds 2005 mit der Entwicklung einer neuen Quellcode-Management-Software begann, „because I hate CVS with a passion“. (Zitat aus seinem Vortrag bei Google Talks 2007, sehr empfehlenswert und sehr lustig, besonders seine grandiosen Slides :))

[youtube http://www.youtube.com/watch?v=4XpnKHJAok8]

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

„I’m an egotistical bastard, and I name all my projects after myself. First Linux, now git.“

„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

Software-Entwicklung basiert seiner Meinung nach immer auf einem „Network of Trust“. Mit einem verteilten System kann sich jeder aussuchen von welchen Entwicklern er den Code ziehen will, wem er vertraut. Er selbst vertraut da nicht besonders vielen 🙂

Sowohl das Erstellen neuer Entwicklungszweige (branching) als auch das Verschmelzen zweier oder mehrerer Zweige (merging) sind sehr performant implementiert. Ein Branch stellt nur eine Reference dar, die auf einen bestimmten Commit verweist. Außerdem ist Git sehr schnell beim mergen und sehr sicher, da jeder Code überprüft wird, bevor er hochgeladen werden kann. Danach wird er mit einer Checksumme versehen und man bleibt somit unverändert bestehen. Bei einer Änderung wird sofort eine neue Version mit einer neuen Checksumme erstellt. Dadurch ist es nicht möglich, die Versionsgeschichte nachträglich zu manipulieren, ohne dass sich der Hash der Revision ändert. Im Gegensatz zu CVS, wo jede Datei eine eigene Revisionsnummer besitzt, speichert Git bei einem Commit das gesamte Dateisystem ab.

Jedes Feature und jeder Entwickler kann einen Branch oder ein eigenes Repository haben, aus dem dann Commits über Merge oder Cherry-pick (Nutzen einzelner Commits) in den Hauptzweig des Projekts (master) übernommen werden können.

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 den verschiedenen Repositories gibt, 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 wird aber kein Workflow von Git vorgegeben und verschiedenste Szenarien sind deshalb möglich.

Git läuft auf allen Unixsystemen, sowie seit 2012 auch unter Windows mit dem Client GitHub oder mit Hilfe der Cygwin-Umgebung, mit Msysgit oder der TortoiseGit-Shell-Erweiterung. Mit Gitweb gibt es auch eine in Perl geschriebene Weboberfläche, die mit Git ausgeliefert wird.

Kleine GIT Einführung

Um ein bisschen mit Git herumzuspielen und sich an seiner einfachen Bedienung zu erfreuen, seien hier ein paar Basisbefehle angegeben.

Git-Downloads gibt es für Mac, Windows und Linux.

Konfiguration

Nach der Installation muss zunächst ein Name und eine Emailadresse angegeben werden, damit man sich im Netzwerk identifizieren kann. Dazu die folgenden 2 Befehle auf der Konsole eingeben:

git config --global user.name "Mein Name"
git config --global user.email "meine_email@beispiel.com"

Um deine Einstellungen zu überprüfen, kannst du git config --list eingeben. Du kannst auch jederzeit die Hilfe aufrufen durch Eingabe von git help <verb>, z.B. git help config, um Informationen zu dem config-Befehl zu bekommen.

Ein Projekt tracken

Um ein existierendes Projekt mit Git zu versionieren (zu tracken), navigiere zunächst in das Projektverzeichnis und führe dann den Befehl git init aus. Dadurch wird ein neues Unterverzeichnis namens .git erzeugt, das alle benötigten Repository Dateien enthält.

Staging

Um eine bestimmte Datei oder ein Verzeichnis mit Git zu tracken , geben wir den folgenden Befehl ein:

git add DATEI oder VERZEICHNISNAME

Sie befindet sich dann im sogenannten Staging-Status. Eine mit Git getrackte Datei kann sich in unterschiedlichen Status befinden.

Mit dem Befehl git status läßt sich der Status der Dateien in dem aktuellen Verzeichnis abrufen.

Commit ausführen

Nun können wir unseren ersten Commit ausführen mit git commit. Nach dem -m-Zeichen muss eine Commit-Message angegeben werden.

git commit -m 'initial project version'

Wenn wir danach noch einmal git status aufrufen, sehen wir, daß nun erstmal alles was im staging-modus war committed ist. Als nächstes nehmen wir eine Änderung an einer unserer getrackten Dateien vor und speichern die Datei. Wenn wir nun erneut git status aufrufen, wird uns die Datei als modified angezeigt.

Danach kann ein Commit aller vorgenommenen Änderungen vorgenommen werden. Dazu muss man aber zunächst die zu comittenden Dateien oder Verzeichnisse wieder mit git add hinzufügen, oder aber man überspringt diesen Schritt indem man -a nach dem git commit angibt also
git commit -a -m 'meine commit message'
Dadurch werden alle Dateien übergeben, die auch vorher schon einmal committed worden waren und nun geändert wurden.

Um deine bisherige Commit-Historie anzusehen, einfach git log eingeben. Es wird der Hashcode des Commits angegeben, sowie der Autor, das Datum und die Commit-Message.

Um ein bereits existierendes Repository oder Projekt zu klonen wird der Befehl git clone [url] benutzt. Im Gegensatz zu anderen Versionskontrollsystemen heißt es hier klonen und nicht auschecken. Man erhält alle Dateien des Projekts mit der gesamten Historie und allen Versionen nach Ausführen des Klon-Befehls.

Um die Commit-History graphisch aufbereitet anzuschauen, kann mit dem Befehl gitk die mitgelieferte GUI aufgerufen werden, die wie folgt aussieht:

Damit sind die Grundfunktionen einer Versionsverwaltung erst einmal abgedeckt. Wie es weitergeht, läßt sich auf der offiziellen Git-Webseite nachlesen, dort wird Schritt für Schritt erklärt, wie man mit Git am besten umgeht.

TIGER TECH TALK

„Git“ your work done and don´t mess with your team!

Verteilte Versionsverwaltung mit GIT

Kleine GIT Einführung

Links

Schreibe einen Kommentar Antworten abbrechen