GIT & SVN. Rheinisch-Westfälische Technische Hochschule Aachen Lehrstuhl für Datenmanagement und -exploration Prof. Dr. T. Seidl

Transkript

1 Rheinisch-Westfälische Technische Hochschule Aachen Lehrstuhl für Datenmanagement und -exploration Prof. Dr. T. Seidl Proseminar: Methoden und Werkzeuge GIT & SVN Versionsverwaltung Alexander aus der Fünten 25. Juni 2012 Betreuung: Prof. Dr. T. Seidl Philipp Kranen

2

3 Hiermit versichere ich, dass ich die Arbeit selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitate kenntlich gemacht habe. Aachen, den 25. Juni 2012

4

5 Inhaltsverzeichnis 1 Einleitung 1 2 Subversion 5 3 Git 9 4 Beispielhafter Arbeitsablauf 11 5 Zusammenfassung 15 Literaturverzeichnis 17 v

6

7 Kapitel 1 Einleitung Spätestens wenn man mit mehreren Dateien arbeiten muss, an denen sich häug etwas ändert, und auf die mehrere Mitarbeiter unter Umständen zeitgleich zugreifen müssen, sollte man sich mit Versionsverwaltung beschäftigen. Versionsverwaltung stellt für diese Szenarien eine erhebliche Aufwandsreduzierung für den Anwender dar und bietet einige nützliche Funktionen. So koordiniert diese nicht nur den gemeinsamen Zugri auf Dateien durch mehrere Mitarbeiter, sondern ermöglicht auch eine gleichzeitige Entwicklung an mehreren Entwicklungszweigen, ohne jeden einzelnen Entwicklungszweig direkt betrachten zu müssen, oder die Archivierung einzelner Stände (beispielsweise Versionen), um jederzeit wieder auf diese zugreifen zu können. Weiterhin werden jegliche Änderungen protokolliert, so dass jeder nachvollziehen kann, wer wann was und warum geändert hat. Erwähnenswert ist auch, dass keine Änderung endgültig ist, da man jede einzelne Änderung ganz leicht rückgängig machen kann. Versionsverwaltung kann man sich zusammengefasst als "Zeitmaschine" vorstellen, da diese sowohl in der Zeit agieren kann (Versionen) als auch im Ort (Zweige, Pfade)[1]. Versionsverwaltung, oft auch Versionskontrolle oder Versionskontrollsystem genannt, trit man sehr häug in der Softwareentwicklung an, da hier besonders oft mehrere Dateien gleichzeitig bearbeitet werden müssen und häug kleine Änderungen wieder verworfen werden. Generell beschränkt sich Versionsverwaltung aber nicht nur auf reine Textdateien, sondern kann auch binäre Dateien verwalten. Als ein sehr bekanntes Beispiel auÿerhalb der Softwareentwicklung sei auf die Wikipedia verwiesen, die jeden ihrer Artikel versioniert, so dass Änderungen leicht nachvollzogen, sowie ältere Artikelversionen wiederhergestellt werden können. 1

8 2 Kapitel 1. Einleitung Das zeitlich ältere Prinzip beim Problem des gemeinsamen Zugris ist das des Sperren-Verändern-Entsperrens: Hierbei wird die Datei bei der Bearbeitung für andere Mitarbeiter gesperrt, bis die Bearbeitung abgeschlossen ist. Erst dann wird sie wieder freigegeben, also entsperrt. Da dieses Prinzip sehr nachteilig ist oft kann man an einer Datei gemeinsam arbeiten, da man unterschiedliche Stellen bearbeitet gibt es das alternative Prinzip des Kopieren-Verändern-Zusammenführens. Hierbei erstellt man sich zur Bearbeitung eine Arbeitskopie, ohne damit die Originaldatei zu verändern. Wenn man seine Änderungen abgeschlossen hat, kann man anschlieÿend die Originaldatei mit der Arbeitskopie zusammenführen. Dass Änderungen von anderen Mitarbeitern nicht verloren gehen, darum kümmert sich die Versionsverwaltung. Natürlich kann die Versionsverwaltung dies nicht immer sauber bewerkstelligen (beispielsweise wenn identische Bereiche unterschiedlich bearbeitet wurden). Dann gibt es einen Koniktfall, den der Anwender manuell lösen muss, indem er beispielsweise Rücksprache mit seinen Kollegen hält und anschlieÿend den Koniktfall durch eine abschlieÿende Änderung auöst. Die bekanntesten Versionsverwaltungen Subversion und Git, auf die in dieser Ausarbeitung näher eingegangen wird, benutzen das Prinzip des Kopieren-Verändern-Zusammenführens. Im Grunde kann man Versionsverwaltung in drei Arten kategorisieren, die auch zeitlich gesehen in dieser Reihenfolge aufeinander folgten. Als erstes sei die Lokale Versionsverwaltung genannt, die häug nur eine Datei versioniert. Diese spielt heutzutage noch in lokalen Büroanwendungen eine Rolle; die Versionen werden hierbei meist in der Datei selbst gespeichert. Nach der Lokalen Versionsverwaltung gibt es dann die Zentrale Versionsverwaltung. Hierbei bendet sich die gesamte Versionsverwaltung in einem zentralen Repository. Dieses kann sich auf dem Computer benden, häuger ist dieses aber über ein Netzwerk erreichbar, versehen mit den nötigen Zugrisrechten. Zum Bearbeiten holt man sich aus diesem Repository eine Arbeitskopie, die man lokal ändert. Anschlieÿend schickt man die Änderungen an das Repository bzw. bestätigt diese im Repository. Als bekanntestes Beispiel ist hier Subversion anzuführen. Die dritte Art der Versionsverwaltung ist die Verteilte Versionsverwaltung. Hierbei gibt es kein zentrales Repository, sondern jeder am Projekt Beteiligte hat sein eigenes Repository. Somit kann auch jeder lokal alle Änderungen verfolgen und Dateien ohne Konikte ändern, auch wenn die Datei gleichzeitig

9 1. Einleitung 3 von jemand anderem bearbeitet wird. Die Dateien existieren so zunächst parallel. Sie können später jedoch in eine neue Version zusammengeführt werden. Dies kann bei gröÿeren Projekten beispielsweise von einer Person mit einer Integrator-Rolle bewerkstelligt werden. Zwischen diesen verteilten Repositories wird häug dennoch ein quasi zentrales Repository bzw. ein master-repository verwendet, in dem sich der aktuelle Hauptentwicklungszweig bendet. Zusätzlich lassen sich leicht beliebig viele weitere Zwischenebenen einfügen, um das Projekt feiner organisieren zu können. Die Verteilte Versionsverwaltung ist so also besonders bei sehr groÿen Projekten interessant oder bei Projekten, bei denen die Mitarbeiter räumlich stark getrennt arbeiten (z.b. in verschiedenen Ländern). Hier ist als Beispiel Git anzuführen. Alle Versionsverwaltungen haben aber gemein, dass in der Regel lediglich die Änderungen zwischen den Versionen gespeichert werden, nicht jeweils die komplette Datei in jeder Version, um den Speicherplatz möglichst gering zu halten. Ebenso werden bei Änderungen im Repository jeweils nur eben diese im Netzwerk übertragen, um auch hier das Datenvolumen möglichst gering zu halten. In dieser Ausarbeitung wird in je einem Kapitel auf die Versionsverwaltungen Subversion und Git eingegangen, als Repräsentanten für die Zentrale und Verteilte Versionsverwaltung. Abschliÿend wird ein beispielhafter Arbeitsablauf anhand von Subversion durchgespielt.

10 4 Kapitel 1. Einleitung

11 Kapitel 2 Subversion Subversion ist eine Zentrale Versionsverwaltung und ist heutzutage aufgrund der Eigenschaft, dass es sich bei Subversion um eine freie und leistungsstarke Software handelt, die am weitestverbreitete Versionsverwaltung im Bereich der Zentralen Versionsverwaltungen. Abbildung 2.1: Repository-Client-Aufbau bei Subversion [7] Subversion entstand ursprünglich aus CVS (Concurrent Versions System), welches auch noch relativ weit verbreitet ist, aber nicht mehr aktiv weiterentwickelt wird. Einer der wesentlichen Unterschiede zwischen den beiden Versionsverwaltungen besteht darin, dass CVS lediglich Dateien versionierte, Subversion hingegen auch Verzeichnisse. Dies macht es möglich, die Versionsgeschichte auch nach Dateiverschiebungen zu behalten. Die Version 1.0 von Subversion erschien

12 6 Kapitel 2. Subversion Die Versionierung von Subversion erfolgt mittels einer einfachen Revisionszählung. Bei jeder Änderung, die an das Repository übermittelt wird, erhöht sich die Revision des gesamten Repository um eins. Auch dies war bei CVS anders, denn dort bekamen lediglich die veränderten Dateien jeweils eine neue Revision, so dass es zu einem bestimmten Zeitpunkt mehrere Revisionen geben konnte. Nun ist es aber möglich, jedem Zeitpunkt eine exakte Revision zuzuordnen und umgekehrt, was viele Zugrie auf ältere Stände vereinfacht (zum Beispiel bei der Wiederherstellung einer älteren Version). Der Hauptentwicklungszweig wird bei Subversion Trunk genannt, Nebenzweige Branches. Weiterhin gibt es sogenannte Momentaufnahmen, die Tags genannt werden. Letztere sind nützlich, wenn man später auf diese speziellen Versionen unproblematisch und ohne Kenntnis einer genauen Revisionsnummer zugreifen kann. Tags werden nicht mehr verändert. Das Besondere an Subversion ist, dass es zwischen dem Trunk, den Branches und den Tags technisch gesehen keinen Unterschied gibt. Sowohl Branches als auch Tags beginnen ihre Versionsgeschichte als einfache Kopie des Hauptentwicklungszweigs bzw. anderer bereits vorhandener Nebenzweige. Es ist im Repository letztendlich lediglich durch die Benennung der Verzeichnisse Konvention, was der Trunk, was ein Branch und was ein Tag ist. Und demnach verwendet man diese auch. Da Kopien im Sinne von Subversion lediglich eine Verzeichnisänderung darstellen, handelt es sich auch um keine echte Kopie, die entsprechend Speicherplatz verbrauchen würde, sondern nur um eine neue Versionsgeschichte, die mit einem Vermerk auf ihren Ursprung beginnt. Demnach nennt man solche Kopien bei Subversion auch gerne "billige Kopien", die man sich an geeigneten Stellen auch nicht scheuen sollte zu erzeugen. Der wesentliche Arbeitsablauf mit Subversion ist, dass man sich zu Anfang erst einmal eine Arbeitskopie auscheckt. Mit der kann man dann ganz gewohnt und ohne Subversion arbeiten, mit der Ausnahme, dass beispielsweise das Hinzufügen neuer Dateien oder das Löschen von Dateien Subversion mitgeteilt werden muss, da Subversion wie gesagt auch die Vezeichnisstruktur versioniert. Weiterhin sei angemerkt, dass Subversion intern ein verstecktes Verzeichnis.svn in der Arbeitskopie verwendet, in dem unter anderem auch die ursprüngliche Arbeitskopie gespeichert ist, für den Fall, dass man Änderungen verwerfen möchte. Hat man seine Änderungen abgeschlossen, muss man zunächst ein Update der Arbeitskopie mit dem Repository durchführen, um im Repository geschehene Änderungen zu erhalten, die in der Zwischenzeit getätigt wurden. Subversion fügt diese Änderungen

13 2. Subversion 7 automatisch in die Änderungen der Arbeitskopie ein, es sei denn, es entsteht ein Konikt, da sich Änderungen überschneiden. In diesem Fall muss der Konikt manuell aufgelöst werden, und die Auösung des Konikts Subversion explizit mitgeteilt werden. Zum Schluss müssen die Änderungen mit einem commit und einer kurzen Mitteilung bestätigt werden; die Mitteilung steht anschlieÿend im log-protokoll und dient zur Erklärung, was sich in dieser Revision geändert hat. Subversion aktualisiert dann das Repository und erhöht automatisch die Revision um eins. Subversion bietet jede Menge nützliche Befehle und Tools (wie z.b. log, status, di, etc.), mit denen man Änderungen und Unterschiede sehr genau analysieren kann, sowie sich einen Blick über die Versionsgeschichte im Repository verschaen kann. Hilfe zur Benutzung erhält man ganz schnell mit svn help <Befehl> (über die Konsole). Weiterhin sei hier auf eine ausführlichere Befehlsreferenz verwiesen, wie z.b. im Buch "Versionskontrolle mit Subversion" [1]. Dieses Buch steht unter der Open-Source-Lizenz und ist auch online verfügbar [2].

14 8 Kapitel 2. Subversion

15 Kapitel 3 Git Git ist eine Verteilte Versionsverwaltung und wird für viele groÿe Open- Source-Projekte eingesetzt, so zum Beispiel unter anderem für den Linux Kernel, für den Git ursprünglich von Linus Torvalds 2005 entwickelt wurde. Dies wurde aufgrund einer Lizenzänderung von BitKeeper nötig, einer anderen Verteilten Versionsverwaltung, die vorher für die Entwicklung des Linux Kernels eingesetzt wurde. Abbildung 3.1: Repository-Client-Aufbau bei Git [6] Der grundlegende Unterschied zu anderen Versionsverwaltungen ist eben der, dass jeder Entwickler ein eigenes Repository hat, dass er sich einmal anlegen muss. Dies macht er mit dem Befehl git clone. Somit hat er indirekt eine komplette Kopie vom Haupt- bzw. master-repository. Technisch gesehen gibt es 9

16 10 Kapitel 3. Git zwischen den verschiedenen Repositories keinen Unterschied, aber praktisch ist letzteres Repository in der Regel dasjenige, auf welches von der Projekt- Website aus verwiesen wird und das den Hauptentwicklungszweig beinhaltet. Der Hauptentwicklungszweig heiÿt bei Git master. Branches und Tags gibt es wie bei anderen Versionsverwaltungen auch. Eine Besonderheit bei Git ist jedoch, dass im Grunde jeder Entwickler sozusagen an einem eigenen Zweig arbeitet, nämlich auf dem eigenen Repository, und dieser Zweig dann an das nächste Repository übermittelt wird. Dies geschieht entweder über einen Transfer zwischen den Repositories oder vor allem beim master-repository auch in Form von Patches per an den oder die (Haupt-)Entwickler, die die Änderungen dann übernehmen. Oberhalb der lokalen Repositories der einzelnen Entwickler gibt es in der Praxis meist Personen mit Integrator- Rolle, die dafür sorgen, dass der Inhalt eines Repositories korrekt in ein anderes Repository übermittelt wird. Das Prinzip ist im Wesentlichen aber das Gleiche wie bei Subversion. Desweiteren gibt es auch bei Git diverse nützliche Tools, wie log, show, di, status, etc. Schnelle Hilfe zur Verwendung dieser Befehle erhält man ähnlich wie bei Subversion mit git help <Befehl>.

17 Kapitel 4 Beispielhafter Arbeitsablauf Bei diesem Beispiel wird davon ausgegangen, dass das Repository bereits besteht und schon einigen Inhalt aufweist. Zunächst muss man sich eine Arbeitskopie anlegen, indem man die Dateien, mit denen man arbeiten will, aus dem Repository lädt. Hier soll nur der Hauptentwicklungszweig des Projekts proseminar/svn/ aus dem Repository geladen werden und die Arbeitskopie im Ordner Arbeitsverzeichnis angelegt werden. $ svn checkout file:///pfad/zum/repos/proseminar/svn/trunk Arbeitsverzeichnis $ cd Arbeitsverzeichnis/ Nun kann man mit den Dateien im Arbeitsverzeichnis wie gewohnt arbeiten. Für dieses Beispiel soll angenommen werden, dass eine vorhandene Datei Einleitung.tex verändert wurde, sowie eine neue Datei Test.txt hinzugefügt wurde. Oft ist es praktisch, sich abschlieÿend alle Änderungen noch einmal anzeigen zu lassen: $ svn status? Test.txt M Einleitung.tex Das? bedeutet, dass Subversion die Datei noch nicht kennt oder genauer gesagt, dass die Datei noch nicht der Versionskontrolle unterliegt. Subversion muss also noch explizit mitgeteilt werden, dass es diese Datei mit in die Versionskontrolle aufnimmt: $ svn add Test.txt A Test.txt 11

18 12 Kapitel 4. Beispielhafter Arbeitsablauf Bevor man die Änderungen nun ans Repository sendet, sollte man erstmal schauen, ob es im Repository nicht Änderungen gibt, die man berücksichtigen sollte. Wenn es dort Änderungen an den gleichen Dateien gibt, schlägt der Versuch, die eigenen Änderungen ans Repository zu übermitteln, eh fehl. $ svn update C Einleitung.tex Aktualisiert zu Revision 5. In diesem Beispiel gab es tatsächlich eine Änderung, und zwar an der gleichen Datei. Da auch mindestens eine gleiche Stelle innerhalb der Datei betroen war, konnte Subversion die Änderungen nicht selbst zusammenfügen. Diese Information ist dem C (Conict) aus der Ausgabe zu entnehmen. Diesen Kon- ikt muss man nun selbst beheben. In der Datei selbst wurden von Subversion Koniktmarker eingefügt, die einem anzeigen, was die eigene Änderung war und was nun die neue Version ist. <<<<<.mine Text mit der eigenen Änderung... ======== Text mit den Änderungen aus der neuen Revision... >>>>>>.r15 Weiterhin bietet Subversion Möglichkeiten, direkt eine Variante zu übernehmen oder mit svn revert einfach die eigenen Änderungen zu verwerfen. Am anschaulichsten ist es hier aber, in der betreenden Datei die Koniktmarker zu entfernen und irgendwie zu einer abschlieÿenden Änderung zu kommen (zum Beispiel durch Absprache mit den Kollegen). Wenn dies getan ist, muss man Subversion über die Behebung des Konikts informieren: $ svn resolved Einleitung.tex Konflikt von Einleitung.tex aufgelöst Wenn es nun keine weiteren Änderungen oder Konikte mehr gibt, kann man die Änderungen unter Angabe einer kurzen Nachricht endlich an das Repository übermitteln: $ svn commit -m "Nachricht für log-datei" Sende Einleitung.tex Hinzufügen Test.txt Übertrage Daten.. Revision 6 übertragen. Vorangegangene Änderungen kann man mit svn log einsehen (auch auf bestimmte Dateien oder Verzeichnisse beschränkt).

19 4. Beispielhafter Arbeitsablauf 13 Die Benutzung von Subversion oder allgemein von Versionsverwaltungen muss nicht zwangsweise in der Konsole erfolgen. Es gibt auch graphische Benutzeroberächen, beispielsweise als Darstellung im Browser oder als Eingliederung direkt in die Oberäche des Betriebssystems.

20 14 Kapitel 4. Beispielhafter Arbeitsablauf

21 Kapitel 5 Zusammenfassung In dieser Ausarbeitung wurden die wesentlichen Unterschiede der Versionsverwaltungen vorgestellt: So arbeitet die Lokale Versionsverwaltung, wie der Name bereits sagt, lokal auf einem Rechner, die Zentrale Versionsverwaltung (Beispiel Subversion) mit einem zentralen Repository, auf dem alle Dateien liegen, und die Verteilte Versionsverwaltung (Beispiel Git) auf mehreren Repositories, die gegenseitig abgeglichen werden. In den einzelnen Kapiteln wurde die prinzipielle Arbeitsweise mit Subversion bzw. Git erläutert, die generelle Verwendung einer Arbeitskopie erklärt, sowie das jeweils verbreitete Vokabular vorgestellt. Abschlieÿend wurde ein beispielhafter Arbeitsablauf mit Subversion durchgespielt, wobei noch einmal auf die interessanten Stellen eingegangen wurde. 15

22 16 Kapitel 5. Zusammenfassung

23 Literaturverzeichnis [1] Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato. Versionskontrolle mit Subversion. O'Reilly Verlag, [2] Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato. Versionskontrolle mit Subversion [Online; Stand 28. April 2012]. [3] David Thomas, Andrew Hunt. Versionsverwaltung mit CVS. Carl Hanser Verlag, [4] Wikipedia. Apache Subversion. title=apache_subversion&oldid= , [Online; Stand 28. April 2012]. [5] Wikipedia. Git , [Online; Stand 28. April 2012]. [6] Wikipedia. Repository-Client-Aufbau bei Git. wiki/datei:svnvsgitserver_2.png, [Online; Stand 24. Mai 2012]. [7] Wikipedia. Repository-Client-Aufbau bei Subversion. org/wiki/datei:svnvsgitserver_1.png, [Online; Stand 24. Mai 2012]. [8] Wikipedia. Versionsverwaltung. title=versionsverwaltung&oldid= , [Online; Stand 28. April 2012]. 17