Objektorientierte Programmiertechniken
LVA 185.A01, VU, 3 ECTS

Einrichten und Benutzen des Git-Repositories für die LVA Objektorientierte Programmiertechniken

Allgemeines

Git ist ein Version-Control-System, das vor allem die Zusammenarbeit mehrerer Personen in Softwareentwicklungsprojekten unterstützt. Jede Person hat eine eigene Kopie des Quellcodes, und mithilfe von Git werden diese Kopien synchronisiert und am aktuellen Stand gehalten. In der LVA Objektorientierte Programmiertechniken wird Git auch zur Abgabe von Lösungen der Programmieraufgaben verwendet.

Konkret existiert für jede Übungsgruppe ein Git-Repository, in dem alle gemeinsamen Dateien der Gruppe zusammen mit der gesamten Historie (allen gemachten Änderungen dieser Dateien) abgelegt sind. Es ist für die Gruppenmitglieder über die URI ssh://git@g0.complang.tuwien.ac.at/<Gruppe> erreichbar, nachdem alle zur Authentifizierung benötigten Informationen bekanntgegeben wurden. Üblicherweise legt sich jedes Gruppenmitglied auf dem eigenen Rechner eine Kopie, genannt Clone, dieser aktuellen Dateien des Repositories an (z.B. von einer Konsole aus mit dem Befehl git clone ssh://git@g0.complang.tuwien.ac.at/<Gruppe>) und kann darauf wie auf gewöhnlichen lokalen Dateien arbeiten. Nach einer Bearbeitung müssen die Änderungen in das Repository gebracht werden. Das geschieht in mehreren Schritten. Zuerst verwendet man z.B. den Befehl git add ..., wobei die Punkte für die Namen neuer oder möglicherweise geänderter Dateien stehen, um die betroffenen Dateien zu identifizieren. Danach wird z.B. durch den Befehl git commit bestätigt, dass diese Dateien bewusst geändert wurden, und die Änderungen müssen dabei verpflichtend durch einen Kommentar beschrieben werden. Das zentrale Repository bekommt davon jedoch noch nichts mit. Um die bestätigten (committed) lokalen Änderungen im zentralen Repository abzulegen, verwendet man z.B. den Befehl git push. Es empfiehlt sich, regelmäßig git pull aufzurufen, um bestätigte Änderungen, die von anderen Gruppenmitgliedern gemacht wurden, aus dem zentralen Repository in die lokale Kopie zu übernehmen. Dabei kann es passieren, dass die eigenen Änderungen nicht zu Änderungen anderer Gruppenmitglieder passen, das ist ein Konflikt. Eine Fehlermeldung wird darauf hinweisen. In den betroffenen Dateien befinden sich dann die in Konflikt stehenden Programmstellen (gekennzeichnet durch Zeilen bestehend aus Wiederholungen des Zeichens =) direkt untereinander, und der Konflikt wird beseitigt, indem man die in Konflikt stehenden Textstellen durch den gewünschten Text ersetzt, einfach durch Editieren der Dateien. Nach nochmaligem add, commit und push ist der Konflikt (hoffentlich) behoben, und die konfliktfreien Dateien stehen im zentralen Repository. Häufig verwendet wird auch der Befehl git status, der Informationen über den aktuellen Status der Dateien in der lokalen Kopie liefert, etwa welche Dateien seit dem letzten commit verändert oder neu angelegt wurden.

Vor Abgabeterminen ist mittels add, commit und push dafür zu sorgen, dass die Lösungen von Programmieraufgaben nicht nur in lokalen Kopien, sondern auch im zentralen Repository liegen. Die LVA-Leitung hat Lese-Zugriff auf die Repositories aller Gruppen und wird zu den Abgabezeitpunkten mittels git pull aktuelle Kopien holen, die in Folge als Grundlage für Beurteilungen dienen.

Jede(r) LVA-Teilnehmer(in) bekommt einen Account auf dem in der Übung verwendeten Rechner g0.complang.tuwien.ac.at. Hier können die Aufgaben gelöst werden. Es gibt bereits ein Verzeichnis, in dem eine Kopie des Repositorys liegt, sodass der Befehl git clone ... nicht mehr ausgeführt werden muss. Dieses Verzeichnis kann verwendet werden, muss aber nicht. Achtung: Es handelt sich dabei nur um eine Kopie, nicht um das zentrale Repository. Zur Abgabe reicht es nicht, Dateien (ohne add, commit und push) in dieses Verzeichnis zu kopieren.

Git ist ein mächtiges Werkzeug für die professionelle Softwareentwicklung in großem Stil. In der Übung wird nur ein kleiner Teil der Funktionalität benötigt. Es ist gefährliche Funktionalität vorhanden, mit der man beispielsweise Inhalte von Repositories zerstören kann. Daher sollte man keine Funktionalität verwenden, deren Auswirkungen man nicht abschätzen kann. Beispielsweise sollte man auf die Verwendung von Branches verzichten, da es leicht passiert, dass zum Abgabezeitpunkt nichts Sinnvolles im Hauptzweig steht und damit nichts abgegeben wurde. Recht gefährlich ist auch der Befehl git rebase, obwohl er in vielen Git-Einführungen empfohlen wird.

Es ist kein großes Problem, wenn eine lokale Kopie zerstört wird. Durch git clone ... lässt sich jederzeit eine neue Kopie anlegen, sodass nur die letzten Änderungen in der lokalen Kopie verloren sind.

Einrichten von Git auf eigenen Rechnern

Es sind Vorbereitungen nötig, bevor auf das Git-Repository zugegriffen werden kann. Zunächst muss eine Git-Variante installiert werden, wenn das nicht schon geschehen ist. Für jedes übliche Betriebssystem steht zumindest eine kostenfreie Variante bereit. Eine Web-Suche nach git und dem entsprechenden Betriebssystem wird geeignete Treffer liefern, und die eigentliche Programminstallation hält normalerweise keine Überraschungen bereit.

Nun müssen wir für die Authentifizierung sorgen. Aus Gründen der Bequemlichkeit und Sicherheit vermeiden wir Passwörter bei Zugriffen auf Repositories. Es liegt ein Fehler vor, wenn beim Zugriff nach einem Passwort gefragt wird. Zur Authentifizierung wird die Kombination aus einem privaten und einem dazu passenden öffentlichen Schlüssel verwendet. Diese Schlüssel werden automatisch generiert und dürfen nicht überschrieben werden. Der private Schlüssel muss in einer Datei auf jedem Rechner liegen, von dem aus man auf das Repository zugreifen will, während in das Repository die öffentlichen Schlüssel aller Personen eingetragen sind, die auf das Repository zugreifen dürfen. Sobald Sie Ihren Account am Übungsrechner erhalten, ist das Repository Ihrer Gruppe schon erstellt, und alle benötigten Schlüssel liegen schon am Übungsrechner. Wenn Sie von eigenen Rechnern aus arbeiten wollen, ist es noch notwendig, Ihren privaten Schlüssel aus Ihrem eigenen Account am Übungsrechner auf jeden dieser eigenen Rechner zu kopieren. Der private Schlüssel befindet sich im Home-Verzeichnis unter .ssh/id_rsa – bitte nicht überschreiben. Auf eigenen Rechnern soll er meist (je nach Installation der verwendeten Verbindungssoftware) ebenso als .ssh/id_rsa im Home-Verzeichnis stehen, wobei das Verzeichnis .ssh vor dem Kopieren eventuell noch anzulegen ist.

Schwieriger wird es, wenn auf einem eigenen Rechner ein privater Schlüssel .ssh/id_rsa schon für andere Zwecke eingesetzt oder Verbindungssoftware auf unübliche Weise installiert ist. Man kann zwar mehrere private Schlüssel gleichzeitig haben, aber man muss dem System mitteilen, wo diese Schlüssel zu finden sind. Je nach Betriebssytem und verwendeter Verbindungssoftware geschieht dies auf unterschiedliche Weise.

Achtung: Viele Beschreibungen aus dem Internet gehen davon aus, dass die Schlüssel erst generiert werden müssen. Das ist bei uns nicht der Fall. Neu generierte Schlüssel sind für unsere Zwecke sinnlos, weil sie nicht mit den öffentlichen Schlüsseln zusammenpassen, die bereits in den Repositories eingetragen sind.

Achtung: Der private Schlüssel hat seinen Namen nicht von ungefähr. Aus Sicherheitsgründen darf er nicht weitergegeben, per Mail verschickt oder auf andere Weise möglicherweise für andere Personen (auch nicht Tutor(inn)en) zugänglich gemacht werden. Er ist wie ein Passwort zu behandeln.

Git in IntelliJ IDEA

Die Verwendung von Version-Control-Systemen (VCS) ist in der Softwareentwicklung heute so weit verbreitet, dass der Umgang damit in praktische jedem Integrated-Development-Environment (IDE) abgebildet ist. Möglicherweise muss man dafür zusätzliche Module installieren oder aktivieren. Wir wollen exemplarisch den Umgang mit Git in IntelliJ IDEA betrachten, in anderen IDEs ist das aber nicht wesentlich anders. Vor der Verwendung sollte Git installiert und der für den Verbindungsaufbau nötige Schlüssel gesetzt sein.

Zunächst sind allgemeine Einstellungen nötig: Unter VCS -> Enable Version Control Integration wählt man Git und gibt den Pfad zum ausführbaren Git-Programm an. Ein kleiner Test überprüft, ob Git funktioniert. Danach gibt man unter VCS -> Checkout from Version Control -> Git an, welches Repository zu verwenden ist (ssh://git@g0.complang.tuwien.ac.at/<Gruppe>), wo die neue lokale Kopie angelegt werden soll und wie das Verzeichnis mit der lokalen Kopie heißen soll. Es wird angeboten, die lokale Kopie als Projekt der IDE zu betrachten und als solches zu öffnen. Hat alles funktioniert, sieht man schon die einzelnen Verzeichnisse, in denen später die Quellcodes der Lösungen der Programmieraufgaben liegen sollten. Das Verzeichnis out für den übersetzten Programmcode kann problemlos außerhalb dieser Verzeichnisse liegen. Eine wichtige Kleinigkeit passt jedoch noch nicht: Durch das Erzeugen des Projekts wurde die lokale Kopie des Repositories wahrscheinlich implizit zur Wurzel der Quellcode-Verzeichnisstruktur, sodass alle darin vorkommenden Verzeichnisse als Java-Packages betrachtet werden; der Java-Compiler verlangt daher package-Deklarationen in den Java-Dateien in Unterverzeichnissen. Das wollen wir vermeiden. Zur Beseitigung dieses Problems reicht ein Rechtsklick auf den Namen der Kopie des Repositories (linkes Fenster im Reiter Project) und die Auswahl des Menüeintrags Mark Directory as -> Unmark as Sources Root. Danach wird durch einen Rechtsklick auf jeden Verzeichnisnamen Aufgabe<Aufgabennummer> und Auswahl von Mark Directory as -> Sources Root das jeweilige Verzeichnis wie gewünscht zur Basis der Quellcode-Verzeichnisstruktur für die jeweilige Aufgabe.

Nach dem Einrichten ist der Umgang mit Git (z.B. über die zusätzlichen Symbole in der Leiste rechts oben) recht bequem: Über das Symbol VCS (mit Pfeil nach unten) holt man sich eventuell vorhandene Aktualisierungen aus dem Repository in die lokale Kopie; die dabei (zumindest anfangs) angebotenen Einstellmöglichkeiten belässt man am besten so wie sie sind. Das entspricht dem Befehl git pull. Über das Symbol VCS (mit Pfeil nach oben) wird der aktuelle Zustand der lokalen Kopie ins Repository übertragen. Das sich dabei öffnende Fenster erlaubt die Auswahl der zu aktualisierenden Dateien (wobei die automatisch ermittelte Auswahl meistens perfekt passt), verlangt die Angabe einer Commit Message und erlaubt die Auswahl einiger Tätigkeiten, die vor der Übertragung zu erledigen sind. Das ist mehr als die Befehle git add ..., git commit und git push machen. Ein weiteres Symbol mit einer kleinen Uhr ermöglicht den einfachen Zugriff auf die Historie. Änderungen im Programm zu den einzelnen Commit-Zeitpunkten lassen sich mit einem speziellen Editor leicht verfolgen und alte Zustände wiederherstellen.

Die Arbeit mit einem VCS wirkt sich auf die übliche Vorgehensweise aus. Aufgrund der stets zugänglichen Historie gibt es keinen Grund, gleichzeitig verschiedene Versionen eines Programmtexts nebeneinander liegen zu haben. Man verzichtet auf das händische Verwalten von Backup-Dateien (und vermeidet damit auch Unklarheiten bezüglich der Zugehörigkeit einer Datei zum abgegebenen Programm). Allerdings sollte man Änderungen eher häufig, also in jedem einigermaßen konsistenten Zustand, ins Repository übertragen, damit

Git in der Beurteilung

Die Historie im Repository gibt einen Überblick über die Vorgehensweise bei der Lösung von Programmieraufgaben. Manche Studierende haben Angst davor, auf der Basis von aus derartigen Informationen abgeleiteten Annahmen beurteilt zu werden. Aus diesem Grund wird explizit zugesagt, dass die Historie im Repository im Normalfall für die Beurteilung gänzlich unberücksichtigt bleibt. Nur die jeweils letzten Versionen werden zu den Abgabezeitpunkten aus dem Repository geholt und beurteilt. Für die Beurteilung spielt es keine Rolle, welches Gruppenmitglied zu welchem Zeitpunkt welchen Teil der Lösung in das Repository übertragen hat. Nur in folgenden Fällen werden Ausnahmen gemacht:
Complang
Puntigam
   Kontakt
   Research
   Lehre
      OOP
      Typsysteme
      EP2
      FOOP
      Prog.spr.
      frühere Lehre
         LVAs 2017 W
         LVAs 2017 S
         LVAs 2016 W
            PK
            OOP
               Git in OOP
               1. Aufgabe
               2. Aufgabe
               3. Aufgabe
               4. Aufgabe
               5. Aufgabe
               6. Aufgabe
               7. Aufgabe
               8. Aufgabe
            Typsysteme
         LVAs 2016 S
         LVAs 2015 W
         LVAs 2015 S
         LVAs 2014 W
         LVAs 2014 S
         LVAs 2013 W
         LVAs 2013 S
         LVAs 2012 W
         LVAs 2012 S
         LVAs 2011 W
         LVAs 2011 S
         LVAs 2010 W
         LVAs 2010 S
         LVAs 2009 W
         LVAs 2009 S
         LVAs 2008 W
         LVAs 2008 S
         LVAs 2007 W
         LVAs 2007 S
         LVAs 2006 W
         LVAs 2006 S
         LVAs 2005 W
         LVAs 2005 S
         LVAs 2004 W
         LVAs 2004 S
         LVAs 2003 W
   Links
Sitemap
Fakultät für Informatik
Technische Universität Wien
Anfang | HTML 4.01 | Datenschutzerklärung | letzte Änderung: 2016-09-29 (Puntigam)