Guten Morgen, herzlich willkommen zur zweiten Vorlesung
Softwaretechnik 1.
Wir werden in den Übungen immer anfangen mit ein bisschen Quatsch.
Und der erste Quatsch, der hat was mit Anforderungsermittlung zu tun.
Das ist das, was Sie auf dem ersten Übungsblatt werden tun müssen.
Und Anforderungsermittlung gibt es nicht nur in der Softwaretechnik,
also nicht nur dann, wenn man Software baut, sondern auch, wenn man
andere Dinge baut, zum Beispiel Züge.
Ich nehme an, Sie sind alle schon mal mit der Bahn gefahren und jetzt
stellen Sie sich vor, Ihnen gehört eine Bahn, also so eine deutsche
Bahn oder eine französische.
Und was Sie brauchen, sind neue Züge.
Also müssen Sie Anforderungen aufschreiben, die diese neuen Züge
erfüllen sollen.
Und was relativ offensichtlich ist, ist, naja, Sie wollen, dass das im
Corporate Design ist.
Also die Form und die Farbe von diesen Zügen ist Ihnen sehr wichtig.
Also schreiben Sie das auf.
Was Sie auch noch aufschreiben ist, naja, das Ding braucht einen
tollen Namen, weil es gibt so Dinge wie ein ICE oder ein TGV oder ein
Sprinter.
Natürlich braucht das neue Kind auch einen schönen Namen.
Und es gibt noch viele Anforderungen mehr, die man sich über Züge so
einfallen lassen kann.
Und das haben Sie in Frankreich auch getan, als Sie die neuen Züge
bestellt haben.
Und nachdem Sie die Anforderungen aufgeschrieben haben, haben Sie erst
mal Züge bestellt.
Was glauben Sie denn, wie viele Züge man so bestellt, wenn man
Bahnunternehmen besitzt?
Größenordnung?
Irgendjemand?
20?
Ja, 20 ist ein bisschen wenig.
1.000.
Ich sag Ihnen mal, was Sie bestellt haben.
Die haben 2.000 Loks bestellt und entsprechend viele Waggons zum
Hinten dranhängen.
Das sind 159 Regio N von Bombardier und noch welche von Alstom.
Und das Ganze hat 15 Milliarden Euro gekostet.
Die Bestellung initial.
Wir haben nur ein kleines Detail vergessen.
Ritze kleines.
Dann kam das große Ups.
Also der Auftragnehmer oder die Auftragnehmer, die haben die Züge
geliefert.
Genauso wie bestellt.
Und dann hat man festgestellt, wir haben ein ganz kleines Detail
übersehen.
Und dann gab es eine Schlagzeile in der Zeitung.
Ich habe hier eine ganz renommierte mitgebracht.
Das ist tatsächlich ein Screenshot.
Kein Scheiß.
Die Züge waren tatsächlich zu breit.
Da gab es zwei Unternehmen, nämlich das RFF und die SNCF.
Die SNCF, das sind die, die die ganzen Züge betreiben.
Und die RFF, das sind diejenigen, die das Schienennetz betreiben.
Und die haben zusammen diese Ausschreibung gemacht und gedacht, die
anderen, die werden sich schon darum kümmern.
Und die RFF hat die Breite der Züge quasi bestimmt und hat sich darauf
bezogen, wie breit die Bahnsteige so in den letzten 30 Jahren gebaut
wurden.
Haben dabei übersehen, es gibt noch welche, die sind deutlich älter,
sogar älter als 50 Jahre.
Und das hat dazu geführt, dass man ein paar Bahnsteige hat ändern
müssen.
Weil ich meine, die Züge kann man nicht mehr zurückschicken und sagen,
macht die mal einen halben Meter schmäler.
Das hat zusätzlich nochmal 100 Millionen gekostet.
Ungefähr.
So ganz genaue Zahlen habe ich nicht.
Aber das war schon ein bisschen blöd.
Glücklicherweise gibt es eine Marketing Abteilung, die hat das Ganze
so formuliert, die anstehenden Modernisierungsarbeiten an den
Bahnsteigen begleiten die technologische Entwicklung des
Rollmaterials.
Schon klingt es ganz toll, aber wenn Sie mal eine
Anforderungsermittlung machen, versuchen Sie daran zu denken, dass
Ihre Software nicht zu breit wird oder zu schmal.
Es ist echt teuer und im Zweifelsfall haben Sie damit Ärger, selbst
wenn später der Kunde die Änderungen bezahlt.
Denken Sie daran, wenn Sie das Übungsblatt bearbeiten, da werden Sie
Anforderungen aufschreiben müssen.
Überlegen Sie sich, was plausibel ist und was wahrscheinlich im Alltag
dann auch funktionieren, damit es Ihnen besser geht als den Kollegen
in Frankreich.
Wir haben letztes Mal aufgehört mit der Versionskontrolle.
Sie erinnern sich, es gab dieses wahnsinnig moderne Werkzeug namens
RCS, mit dem man einzelne Dateien versionieren konnte.
Und das Letzte, was wir gesehen haben, war...
Alles täuscht.
Genau, die Folie zu RCS.
Und an der Stelle machen wir jetzt auch weiter mit einer kleinen
Erinnerung.
RCS ist schon ein bisschen über 30 Jahre alt, aber und dort haben wir
die grundlegenden Operationen, die wir uns von einem
Versionsverwaltungswerkzeug wünschen.
Aufbewahrung, Wiederherstellung, Logbuch, Verschmelzen und so weiter.
Die Weiterentwicklung von RCS ist an CVS und wie dort steht, verwendet
CVS tatsächlich intern RCS und fügt im Wesentlichen nur
Netzwerkfähigkeit hinzu und die Unterstützung von Verzeichnisbäumen.
Ist hier irgendjemand unter uns, der schon mal mit CVS gearbeitet hat
oder das schon mal gesehen hat?
Ah ja, tatsächlich einer.
Noch einer?
Ja, zwei habe ich jetzt gesehen.
Sie brauchen nicht zögerlich sein.
Sie können sich ruhig melden, wenn ich solche Fragen stelle.
Die sind nur für mein Interesse.
Wenn ich Sie tatsächlich dran nehmen möchte, dann merken Sie das an
der Frage.
Also CVS 1990 war dann, wie gesagt, die Weiterentwicklung und das
Ganze mündet dann von der Idee her in Subversion.
So, jetzt stelle ich die gleiche Frage nochmal.
Wer hat schon mal mit Subversion gearbeitet?
Bisschen mehr bitte jetzt.
Ja, auch nicht so sonderlich viele.
Erstaunlich.
Subversion ist, wie gesagt, die Weiterentwicklung von CVS.
Subversion ist jetzt internetfähig, das heißt, das Depot liegt auf
einem entfernten Rechner und Sie holen sich Ihre persönliche
Arbeitskopie durch einen Checkout, wie am Montag gesehen, auf Ihren
privaten Rechner oder auf Ihren Arbeitsrechner und haben dann dort
Ihre Arbeitskopie.
SVN ist es möglich, das komplette Projektdepot zu versionieren.
Das heißt, inklusive Verschiebung von Dateien, Umbenennung, Kopieren
von Verzeichnissen und so weiter.
Denn bei CVS hatte man tatsächlich das Problem, wenn man eine Datei A
hatte und dort viele Änderungen durchgeführt hat und dann plötzlich
auf die Idee gekommen ist, die sollte vielleicht doch lieber B heißen.
Dann war die ganze Historie weg.
Also B ploppte dann einfach auf in der Versionshistorie als fertige
Datei und man hatte keine Historie dazu.
Das ist unter SVN tatsächlich schon anders.
Was außerdem noch eine tolle große Neuerung gegenüber CVS ist, ist,
dass das Einbuchen und alle Änderungen tatsächlich die Einbuchung von
Änderungen atomar passieren.
Das heißt, bei CVS konnte es sein, wenn Sie fünf Dateien geändert
haben und die dann im Depot wieder einchecken wollten.
Das konnte gut passieren, dass die ersten drei übertragen wurden und
dann gab es ein Problem.
Man konnte nicht automatisch verschmelzen und dann wurde die vierte
Datei abgelehnt.
Aber die ersten drei waren schon da und schon haben Sie einen
inkonsistenten Zustand.
Das ist natürlich etwas, was man nicht haben möchte.
Deshalb Weiterentwicklung bei SVN.
Entweder alle fünf Dateien werden übertragen und alles funktioniert
oder eben nicht.
Was außerdem bei SVN passiert, sonst könnte ja so ein atomares
Einbuchen gar nichts bringen, ist das optimistische Ausbuchen.
Das heißt, wie wir am Montag gesehen haben, mehrere Leute können
gleichzeitig das gleiche Depot ausbuchen, Änderungen durchführen und
wieder einchecken.
Was SVN allerdings nicht bietet, was wir gerne hätten, wie wir auch am
Montag gesehen haben, sind die Varianten.
Das bietet SVN eingebaut nicht an.
Stattdessen erzeugt man in SVN eher Unterverzeichnisse und legt dort
seine alternativen Entwicklungszweige an.
Und das ist natürlich nicht so ganz optimal, denn man muss sich dann
immer an Konventionen halten.
Üblich ist, dass der Hauptentwicklungszweig im Trunk-Ordner liegt und
Varianten in einem Branches-Ordner abgelegt werden.
Das bedeutet aber auch, wenn Sie vor sich hin entwickeln und dann
merken, ab Version 1 möchte ich eine Variante bilden, kopieren Sie den
kompletten Inhalt des Trunk-Ordners in einen neuen Unterordner von
Branches, den Sie dann zum Beispiel Version 1.0.1.0 nennen, wie wir am
Montag gesehen haben, oder irgendwie anders, wie ein Feature, das Sie
entwickeln wollen.
Und in dem entwickeln Sie dann Ihre Variante.
Dann gibt es noch einen dritten Ordner, in dem man üblicherweise Dinge
ablegt.
Das ist der Tags-Ordner.
Das sind ausgelieferte Entwicklungsversionen.
Also wenn Sie Version 1.0 an den Kunden ausliefern, dann legen Sie
eine Kopie unter Tags dort ab.
Das Gleiche gilt dann für die ausgelieferte Version 2.0 und so weiter.
Aber wie gesagt, das sind alles nur Konventionen.
Daran sollten Sie sich halten.
Das fordert Disziplin von Ihnen und Ihren Mitentwicklern, dass Sie
sich auch an diese Konventionen halten.
Denn wenn Sie das nicht tun, dann bekommen Sie wieder Probleme später
beim Verschmelzen von Branches in den Hauptentwicklungszweig.
Das heißt, da kann es ganz schnell zu Chaos kommen.
Deshalb hätte man eigentlich gerne auch direkt Semantik für die
Variantenbildung.
Aber wir bleiben jetzt trotzdem erst mal noch bei SVN und schauen uns
an, wie das funktioniert.
Ich zeige Ihnen jetzt die Kommandos, die Sie brauchen, um mit SVN zu
arbeiten.
Und wir zeigen Ihnen die Kommando-Zeilen-Variante ganz einfach
deshalb, weil das auf allen Systemen gleich ist.
Und es gibt natürlich auch immer schöne grafische Benutzeroberflächen.
Aber auch dort finden Sie diese Befehle in irgendeiner Art und Weise
wieder.
Vielleicht mal am Rande.
Wer arbeitet denn in der Kommando-Zeile von Ihnen tatsächlich?
Ah, das sind schon ein paar mehr.
Okay, an den Rest vielleicht.
Probieren Sie es mal aus.
Es ist tatsächlich häufig so, dass es schneller geht und besser geht,
wenn man in der Kommando-Zeile arbeitet.
Und auch wenn das für Sie vielleicht am Anfang ungewohnt ist.
Was soll ich sagen?
Als Informatiker sollte man sich vielleicht daran gewöhnen.
Und wenn man erst mal reingefunden hat, geht es tatsächlich schneller.
So zurück zu SVN.
Wir fangen an mit dem Checkout-Befehl.
Das ist der Befehl, um ein Depot aus dem um aus dem Depot das Projekt
auszuchecken.
Wie der Befehl schon sagt, man muss natürlich eine URL angeben.
Sonst weiß man ja nicht, wo man das herbekommen soll.
Man kann zusätzlich auch noch ein Verzeichnis angeben.
Dann bekommt man eben nur ein Teil.
Nein, falsch.
Dann bekommt man ein Ordner, in dem man das Depot reinkopiert bekommt.
Ansonsten bekommt man einfach den Standardnamen, so wie er auf dem
Server abgelegt ist.
Genau, wichtig ist noch, gleichzeitig wird in diesem Verzeichnis, dass
Sie dort anlegen, ein Unterordner .svn angelegt.
Den sollte man einfach nicht anfassen.
Da liegen die ganzen Verwaltungsdinge drin, zum Beispiel um die Deltas
zu bilden.
Der sollte dort einfach liegen bleiben.
Den braucht SVN.
Also nicht löschen, nicht anfassen, einfach in Ruhe lassen.
Und wichtig ist natürlich auch noch, dass Sie eventuell, wenn der
Server, von dem Sie das Depot gerne holen möchten oder einchecken
möchten, wieder später, der kann passwortgeschützt sein.
Das heißt, das müssen Sie eventuell angeben.
Aber normalerweise nur einmal.
Das können Sie dann speichern.
Und wenn Sie dann ein Update machen, um wieder die aktuellen
Änderungen aus dem Depot zu holen, dann brauchen Sie normalerweise
kein Passwort und Benutzername mehr.
Und das ist natürlich jetzt schon die perfekte Überleitung zum
nächsten Befehl, SVN Update.
Der holt Ihnen die aktuellen Änderungen aus dem Depot.
Sie können zusätzlich außerdem noch ein Verzeichnis oder einzelne
Dateien im Befehl mit angeben.
Dann werden nur diese Dateien oder diese Verzeichnisse aktualisiert
und Sie behalten ansonsten den aktuellen Stand Ihres
Arbeitsverzeichnisses.
Wenn Sie jetzt ein Update machen und in der Zwischenzeit in Ihrer
privaten Arbeitskopie Änderungen vorgenommen haben, dann kann es
natürlich zu Konflikten kommen.
Ihre Dateien oder Ihre Änderungen werden aber nicht überschrieben
durch die Änderungen auf dem entfernten Depot, sondern die Konflikte
werden in einer separaten Datei gespeichert und angezeigt.
Sie müssen die dann, wie auch schon am Montag gesehen, selber
ausräumen.
Das dazu bietet SVN an sich auch keine Semantik an.
Wenn Sie dann fertig sind mit dem Ausräumen der Konflikte, dann können
Sie wieder committen und sind fertig mit dem Verschmelzen.
Und Sie merken schon, das baut hier alles aufeinander auf.
Jetzt kommt das SVN Commit und eine Frage.
Also die Frage ist, wenn ich Sie richtig verstanden habe, ob es bei
Konflikten um Konflikte im Programm geht oder ob es nur gleichzeitige
Änderungen gibt an einer Datei.
SVN überprüft natürlich nicht, ob Sie richtig programmiert haben.
Dafür ist es einfach nicht zuständig, sondern es geht tatsächlich um
Konflikte in Dateien, die an der gleichen Stelle geändert wurden.
Das sind die Konflikte, von denen wir hier sprechen, und die muss man
auflösen.
Das sehen wir aber gleich auch noch mal genauer, wie das dann
aussieht.
Jetzt mache ich erst mal mit dem Commit weiter.
Wenn Sie Änderungen gemacht haben und die auf das entfernte Depot
übertragen wollen, dann brauchen Sie den Befehl SVN Commit und auch
hier gilt wieder, Sie können einzelne Dateien oder Verzeichnisse
angeben.
Zum Übertragen, also Sie müssen nicht immer komplett alle Ihre
Änderungen übertragen.
Wenn es beim Übertragen zu Konflikten kommt, das heißt, es gibt eine
neue Änderung auf dem Depot und Sie ändern an der gleichen Stelle in
einer Datei etwas, dann bricht der komplette Commit ab.
Wer aufgepasst hat, dem ist jetzt klar, es bietet sich an, bevor man
etwas committet, immer erst ein Update zu machen, weil dann weiß man
schon, ob es zu Konflikten kommen kann und nicht der ganze Commit
wieder abbricht.
Wenn der Commit dann tatsächlich geklappt hat, das Einbuchen auf dem
Depot funktioniert hat, dann wird die Revisionsnummer der geänderten
Dateien erhöht von 1 auf 2, auf 3 auf 4 und so weiter.
Wichtig ist, dass nur die Änderungen der geänderten Dateien übertragen
werden.
In Ihrem Punkt-SVN-Verzeichnis befindet sich eine Kopie der letzten
Version aller Dateien und beim Einbuchen, wie es hier steht, werden
die Änderungen zwischen diesen Kopien und den geänderten Dateien
gesucht.
Also das sind genau diese Diffs, die wir uns das letzte Mal schon
angeschaut haben.
Und nur diese Änderungen werden dann zum SVN-Server übertragen und in
das entfernte Depot eingetragen.
Ist hier noch was, was ich nicht gesagt habe?
Ja, das ist im Grunde das, was ich gerade eben schon gemeint habe.
Wenn es Änderungen auf dem entfernten Server im Depot gibt, dann
müssen wir erst selber diese Konflikte ausräumen und verschmelzen.
Es gibt dafür grafische Oberflächen, das haben wir auch das letzte Mal
schon gesehen, wer sich noch erinnert, an dem Hello-Welt-Programm mit
den Änderungen von KIT zu Uni.
Das ist also die Möglichkeit für Sie, diese Konflikte auszuräumen.
Wenn Sie das getan haben, dann können Sie tatsächlich diese neue
Version dann im Depot ablegen.
Wenn Sie ein Commit machen, ich glaube, das habe ich vorhin noch nicht
erwähnt, dann werden Sie von SVN aufgefordert, einen Logbuch-Eintrag
zu machen.
Und in diesem Logbuch-Eintrag schreiben Sie einfach ganz kurz, was Sie
geändert haben.
Ein, zwei Sätze.
Normalerweise mit den Änderungen, mit der Semantik, die Sie
tatsächlich geändert haben.
Und das hat den Vorteil, dass, wenn sich dann wieder jemand die
Historie anschaut, nachvollziehen kann, was tatsächlich passiert ist.
Hier sehen wir jetzt mal den Befehl SVN-Log mit den zusätzlichen
Optionen "-v", das heißt einfach nur, zeigt mal ein bisschen mehr an,
liebes SVN.
Und für die Datei "-bar", man kann das auch für alle Dateien anzeigen
lassen.
Und hier sehen wir jetzt die Änderungen, die passiert sind von
Version, von Revision 1 auf Revision 2.
Sehen wir an dieser Stelle, Revision 1 und Revision 2 werden in
umgekehrter Reihenfolge für Sie angezeigt, das heißt die letzte
Änderung immer zuerst.
Und hier sehen wir, eine Person namens TK hat am 11.04.
die Datei "-bar", geändert.
Das sehen Sie an diesem M, die wurde modifiziert.
Und wenn Sie dann weiter zurück schauen in Ihrem Logbuch, dann sehen
wir in der ersten Revision wurden mehrere Dateien und Ordner angelegt,
dafür steht das "-a", wie "-ed".
Und wenn Sie Dateien löschen, dann gibt es außerdem noch die
Information für Sie, dass die gelöscht wurde, dann würde hier ein
"-d", stehen.
Also stellen wir uns vor, in Revision 2 wird die Datei "-bar", nicht
geändert, sondern gelöscht.
Dann würde hier einfach ein "-d", stehen.
Die Änderungen, die hier passiert sind, sind natürlich nicht
sonderlich aussagekräftig.
Also das sollte jetzt nicht für Sie der Goldstandard werden, schreiben
Sie sprechende Logbucheinträge.
An der Stelle kann man natürlich jetzt sagen, ist ja ganz hübsch, dass
ich weiß, welche Dateien geändert wurden, aber was tatsächlich
passiert ist, wissen wir immer noch nicht.
Das heißt, wir würden ja ganz gerne wissen, was tatsächlich für
Änderungen in den Dateien passiert sind.
Und dafür gibt es einen weiteren Befehl, svndiv.
Dem geben Sie zwei Revisionen mit, das sehen wir hier.
"-r1.2", sagt, wir wollen gerne den Unterschied von Revision 1 zu
Revision 2 für die Datei hallo.java sehen.
Und genau die sehen wir jetzt auch hier.
Wir haben hier einmal mit "--", gekennzeichnet, den Stand der Revision
1 der Datei hallo.java und mit "-+, den Stand der Datei hallo.java in
Revision 2.
Und hier sehen Sie jetzt genau, dass an der gleichen Stelle etwas
geändert wurde.
Der Teil wurde entfernt von Revision 1 zu Revision 2 und dieser wurde
hinzugefügt.
Eigentlich relativ offensichtlich und einsichtig, aber was Sie hier
auch schon sehen können ist, SVN arbeitet teilenweise.
Und das ist genau der Punkt, wo Versionskontrolle und Codequalität
zusammenkommen.
Schreiben Sie ganz viel in eine Zeile, was ja immer möglich ist, und
buchen das ein und jemand anders ändert in dieser langen Zeile genau
an der gleichen Stelle oder an einer anderen Stelle etwas, dann
bekommen Sie ein Problem.
Konflikte werden häufiger.
Das heißt, es bietet sich an, sauberen Code zu schreiben, dann haben
Sie weniger Probleme.
Das heißt natürlich jetzt nicht für Sie, Sie sollten so möglichst
viele Zeilen erzeugen, wie Sie können, also nicht immer Enter drücken,
wenn es denn möglich ist, sondern schreiben Sie einfach sinnvollen
Code, dann haben Sie wenig Probleme bei möglichen Konflikten und dann
dem späteren Verschmelzen.
Das Ganze auch noch mal in den Boxen für Sie zum Nachlesen.
Und dann sind wir mit SVN auch schon durch.
Was wir jetzt gesehen haben, sind drei Systeme, die von der Idee her
aufeinander aufbauen.
Alle arbeiten mit diesen Deltas.
Wir hatten RCS, was die Grundfunktionalität einer Versionskontrolle
zur Verfügung stellt, was wir uns so vorstellen.
Wir hatten CVS, das die Netzwerkfähigkeit und die Verzeichnisbäume
hinzufügt und dann SVN, was die Internetfähigkeit und das Umbenennen
noch ermöglicht.
Und eigentlich könnte man jetzt sagen, da haben wir doch eigentlich
alles schon, was wir überhaupt jemals haben wollten von einer
Versionskontrolle.
Dem ist nicht ganz so.
Es gibt ein paar Stellen in SVN, die sind nicht so richtig handlich
und Sie haben schon gesehen, dass mit den Varianten, das ist irgendwie
nicht ganz so praktisch.
Und deshalb gab es ein paar Leute, die sich gedacht haben, das können
wir doch bestimmt besser machen.
Und es war aber nicht so ganz klar, wie man jetzt an der Stelle mit
dem Ansatz noch weiterkommen soll.
Und deshalb, was macht man in diesem Fall?
Wir machen es einfach nochmal komplett neu mit einer neuen Idee.
Und das ist jetzt Git.
Und das ist jetzt der Punkt, wo Sie tatsächlich anfangen sollten,
richtig aufzupassen.
Denn Git ist auch die Versionskontrolle, die wir in den Übungen
verwenden werden, Sie auf den Übungsblättern.
Git ist von 2005.
Das ist somit das Neueste, was wir Ihnen anbieten können und ist auch
so state of the art.
Und bei Git funktioniert jetzt alles ein bisschen anders.
Wir schauen uns nicht mehr wie bei RCS, CVS und bei SVN Dateien und
Änderungen auf diesen Dateien an, sondern wir arbeiten mit Objekten.
Wie das im Detail aussieht und was sich da für nette Dinge daraus
ergeben, das sehen wir gleich.
Merken Sie sich erstmal, wir haben keine Dateien mehr, sondern nur
noch Objekte.
Was außerdem noch ganz hübsch ist, die Variantenbildung ist jetzt
integraler Bestandteil.
Das heißt, wir müssen uns keine Gedanken mehr machen, wie diese
Varianten verwaltet werden, intern, so wie das noch bei SVN war, wo
wir uns alle an Konventionen halten mussten, dass wir unsere Ordner
gleich benennen müssen für die Varianten.
Das ist in Git tatsächlich schon eingebaut.
Außerdem ist die Historie kryptographisch gesichert.
Das sehen Sie nachher auch noch an einigen Stellen.
Das ist ganz hübsch für die Leute, die ein bisschen paranoid veranlagt
sind.
Aber es hat tatsächlich auch Nutzen.
Wichtig ist auch noch, dass die Philosophie eine ganz andere ist, was
das Depot betrifft.
Das Depot ist jetzt nicht mehr im Internet, sondern jeder Git-Nutzer
hat ein eigenes Depot.
Das heißt, alle Operationen, die Sie durchführen können mit Git, gehen
auch offline.
Wenn Sie in ein entferntes Depot übertragen möchten, was natürlich
auch möglich ist, gibt es dafür extra Operationen.
Aber das ist nicht mehr der Kern von Git.
Das sind die zusätzlichen Befehle, die Sie brauchen für die
Übertragung in entfernte Depots.
Das jetzt aber nur am Rande, denn das werden Sie nicht brauchen in der
Übung.
Genauso wie den letzten Punkt hier auf der Folie.
Was man mit Git außerdem noch schön erreichen kann, ist, dass man
Befehls -Hierarchien und Arbeitsabläufe direkt in der
Versionskontrolle abbilden kann.
Man kann zum Beispiel solche Dinge bauen, dass auf dem Hauptzweig nur
bestimmte Nutzer arbeiten dürfen.
Alle anderen müssen auf Nebenzweigen arbeiten und dürfen dann ihre
Änderungen in das Depot ablegen.
Und nur die Leute, die berechtigt sind, auf dem Hauptzweig zu
arbeiten, entscheiden dann, werden diese Änderungen in den Hauptzweig
übernommen, die da gekommen sind, oder eben nicht.
Hier sehen Sie im Grunde destilliert die Gesamtidee von Git.
Wir haben unseren Arbeitsbereich oder unser Git-Depot und dort können
Dateien drinnen liegen.
Das interessiert Git aber erstmal gar nicht.
Wenn Sie wollen, dass Git eine Datei zur Versionskontrolle hinzufügt,
dann benutzen Sie den Git-Add-Befehl.
Dann sagt Git, okay, das ist eine Datei, die schaue ich mir jetzt mit
an und kümmere mich darum, dass die auch richtig versioniert ist.
Dann ist die in Git in dieser sogenannten Staging-Area.
Damit haben Sie aber noch keinen Commit.
Wenn Sie tatsächlich diese Änderung an der Datei oder diese neue Datei
committen wollen, dann brauchen Sie einen extra Git-Commit-Befehl.
Und dann wird diese Änderung in Ihr lokales Depot tatsächlich
eingebucht.
Jetzt könnte man sich natürlich fragen, was bringt das?
Das ist doch jetzt nur ein Extraschritt mehr auf dem Weg zu einem
Commit.
Hat das irgendeinen Sinn?
Und jetzt kommt wieder die Frage, wer hat eine Ahnung, warum könnte
man das haben wollen?
Zwischen dem Working Directory, wo Ihre Dateien drinnen liegen und dem
Depot.
Also, Ihr Kommilitone sagt genau das Richtige.
Man kann selektiv auswählen, was möchte man tatsächlich committet
haben und was nicht.
Also es könnte ja sein, dass Sie an fünf Dateien Änderungen
durchführen und zwei davon waren Änderungen an der GUI und die anderen
drei Änderungen waren Änderungen an einem Algorithmus XY.
Dann möchten Sie das vielleicht nicht in einem Commit haben, sondern
möchten sagen, okay, die ersten zwei werden ein extra Commit, dann
fügen Sie die zunächst zur Staging Area hinzu, machen einen Commit,
wird in Ihr Depot eingetragen, dann fügen Sie die nächsten drei
Dateien hinzu zur Staging Area und bauen einen zweiten Commit.
Und schon haben Sie das semantisch getrennt.
Ihr Logbuch, was Sie später anschauen, sieht schöner aus und Sie
können Ihre Änderungen besser nachvollziehen.
Es kann in Ihrem lokalen Depot keine Konflikte geben, weil Sie ja nur
alleine darauf arbeiten.
Das heißt, dort haben Sie keine Konflikte.
Nicht in diesem Workflow.
Also Sie können auch lokal Konflikte haben, aber das schauen wir uns,
glaube ich, hier gar nicht an.
Wenn dann später.
Also nein.
Worauf ich eigentlich aber noch hinaus wollte, was es außerdem noch
gibt, was ganz hübsch ist.
Manchmal hat man sehr große Dateien und hat da viele Änderungen drin,
aber die gehören semantisch nicht unbedingt zusammen.
Manche Stellen sind vielleicht Bugfixes, andere Stellen sind
tatsächlich neue Semantik.
Man kann, wenn man hier den Get-Add-Befehl richtig parametrisiert,
kann man auch einfach Stücke von Dateien zur Staging Area hinzufügen
und dann in ein Commit verpacken.
Das kann SVN auch nicht.
Sie können stückchenweise Dateien einchecken.
So, jetzt sind wir hier angekommen endlich und können jetzt natürlich
auch noch mit einem Git-Push unsere sämtlichen Commits, die wir bis
dahin getätigt haben, auf ein entferntes Depot übertragen.
Und wir können auch Änderungen von dort wiederholen mit Git-Fetch oder
mit Git-Pull.
Außerdem haben wir hier noch die zwei Befehle Git-Checkout und Git
-Merge.
Checkout hat in Git eine andere Semantik als in SVN.
Wir erinnern uns, in SVN war Git-Checkout der Befehl, um Änderungen
vom entfernten Depot zu holen.
In Git bedeutet Checkout, ich möchte meine Arbeitskopie in einen
gewissen Zustand versetzen.
Das könnte zum Beispiel sein, ich möchte von meinem Depot, in dem ich
mein Datei eingecheckt habe, zurück auf eine ältere Version.
Wie das genau funktioniert, sehen wir auch noch später.
Außerdem haben wir noch den Git-Merge Befehl.
Wenn Sie ein Git-Fetch ausführen, das heißt Änderungen aus dem
entfernten Depot holen, dann sind diese Änderungen erstmal da, aber
die sind noch nicht in Ihrem aktuellen Zweig, in Ihrer Arbeitskopie
eingepflegt.
Dazu müssen Sie dann noch Git-Merge ausführen.
Wenn Sie den Befehl Git-Pull benutzen, dann haben Sie beides in einem,
dann haben Sie ein Fetch und ein Merge in einem.
In der Zwischenzeit erkläre ich diese Folie.
Hier sehen wir die Befehle, die Sie brauchen für Git.
Das sind im Wesentlichen die, die Sie auch schon bei SVN gerade eben
gesehen haben, plus natürlich die zusätzlichen, die wir brauchen.
Wir brauchen das Git-Add, was wir gerade gesehen haben.
Wir brauchen das Commit, Push und Merge.
Hier unten sehen wir auch nochmal den Hinweis, Pull ist Fetch und
Merge kombiniert.
Git-Clone ist im Grunde das Checkout von SVN.
Das heißt, wenn Sie ein entferntes Depot haben möchten auf Ihrem
lokalen Arbeitsrechner, dann benutzen Sie den Git-Clone Befehl.
Hier gibt es allerdings auch einen kleinen Unterschied zu SVN.
Wenn Sie Git-Clone benutzen, bekommen Sie die komplette Historie des
Depots mitgeliefert.
Bei SVN ist das anders, da bekommen Sie nur die aktuelle Version und
wenn Sie die vorherigen Versionen brauchen, dann müssen Sie die später
noch nachholen.
Jetzt gehen wir die größtenteils noch durch.
Git-Init legt Ihnen ein neues Git-Depot auf Ihrem Arbeitsplatzrechner
an.
Dazu brauchen Sie anders als SVN kein entferntes Depot.
Das heißt, Sie können einfach, wie Sie lustig sind, auf Ihrem Rechner
Git -Depots anlegen, ohne dass die jemals irgendwohin übertragen
werden müssen.
Mehr braucht es dazu nicht.
Damit sind Sie schon fertig.
Sie haben damit sofort eine Working Area, eine Staging Area und das
lokale Repository.
Wie ich schon gesagt habe, wenn Sie jetzt Dateien hinzufügen wollen
oder auch Änderungen hinzufügen wollen zur Staging Area, dann brauchen
Sie diesen Git-Add-Befehl.
Sie können das natürlich selektiv tun für Dateien oder für
Verzeichnisse, Sie müssen nicht natürlich alles hinzufügen.
Und wenn Sie das getan haben, folgt wie gesagt der Commit.
Mit dem Commit wird in das eigene Depot geschrieben und hier ist jetzt
auch nochmal der Hinweis auf die Frage von vorhin.
Es kann natürlich keine Konflikte geben an der Stelle, weil wir nur
lokale Änderungen haben, die wir alle selber durchgeführt haben.
Hier sehen wir den Lebenszyklus einer Datei in Git.
Es gibt den Zustand Untracked, also wenn ich eine Datei neu ablege in
meinem Git-Arbeitsverzeichnis, dann sagt Git, ja, kenne ich nicht,
will ich nicht, brauche ich nicht.
Wenn ich dann die Datei hinzugefügt habe, dann ist sie zunächst einmal
natürlich nicht verändert, sondern ist einfach da.
Wenn ich die Datei ändere, dann geht sie über in diesen Modified
-Zustand, das heißt, es hat sich erst geändert.
Wir müssen vielleicht diese Änderung später einbuchen.
Als nächstes würden wir dann von dort ein Add ausführen und damit die
Datei in die Staging-Area überführen.
Dann ist die Datei staged und von dort aus können wir dann Committen
und kommen dann zurück aus Dateisicht in diesen unmodifizierten
Zustand.
Wir können natürlich auch jederzeit aus diesem Zustand die Datei
wieder löschen aus der Versionskontrolle.
Dann sagt Git wieder, mach mit der Datei, was du willst, interessiert
mich nicht weiter.
Hier sehen Sie jetzt das entsprechende Logbuch für Git.
Auch hier gilt natürlich, wenn Sie ein Git-Commit machen, fordert Sie
Git auf, doch bitte einen Logbucheintrag zu verfassen, genau wie SVN.
Hier ist das zweimal passiert.
Es gibt den Logbucheintrag, wir begrüßen nur die SVT 1.
Und zuvor in dem Commit davor, wir grüßen alle, nein, wir sagen nur
Hallo Welt geschrieben.
An dieses Logbuch kommen Sie ran, wieder mit dem Befehl Log, also Git
Log, für die Datei Hello Java in dem Fall.
Wir sehen, dass hier ein fleißiger Mitarbeiter Matthias Landhäuser
zwei Commits auf dieser Datei durchgeführt hat und entsprechend
Änderungen getätigt hat.
Was Sie hier außerdem schon sehen, ist die Kryptografie.
Wer sieht die Stelle?
Also die Kryptografie, die sieht man hier.
Die Commits haben nämlich so ganz komische Namen, kryptografische.
Das ist vielleicht auch schon die Antwort, wozu man das braucht.
Möchten Sie vielleicht nochmal sagen, warum möchte man Hashes haben,
statt einfach nur durchnummerierte Revisionen?
Ja, das waren jetzt zwei Antworten in einer.
Die erste Antwort war, man hat keine Probleme, wenn mehrere Autoren an
derselben Datei etwas ändern, weil ja durch die Hashes eindeutige
Bezeichnungen erzeugt werden.
Ja, das ist richtig.
Das ist der eine Punkt.
Und der andere Punkt ist tatsächlich ein Sicherheitsfeature.
Wenn ich etwas ändere inhaltlich an einem Commit, dann würde sich
natürlich auch der Hash ändern.
Das heißt, wenn ich nachträglich irgendwie versuche, in meiner
Historie herumzufuschen und dort Dinge zu ändern, dann müsste ich die
komplette Historie anpassen, weil ansonsten die Hashes nicht mehr
stimmen.
Und die Commits natürlich aufeinander aufbauen, das heißt, ein Commit
weiß von seinem Commit davor, welcher das war und wenn ich dort den
Hash ändere, dann stimmen natürlich diese Bezüge nicht mehr.
So, schauen wir mal hier rein, ob ich alles gesagt habe.
Hinweis hierzu vielleicht noch, in die Hashes geht tatsächlich der
Inhalt der Änderung mit ein, Autor, wahrscheinlich auch das Datum, ich
weiß es gerade gar nicht genau, was alles eingeht, aber es ist
einiges, damit es auch tatsächlich eindeutig wird.
Genau, dann habe ich tatsächlich schon alles gesagt und jetzt kommt
der eigentliche Knackpunkt in der Denkweise von Gitt, der ihn deutlich
unterscheidet von SVN, Matthias.
Ach, auf das Buch hinweisen.
Auf das Buch hinweisen, das ist jetzt eigentlich genau die richtige
Stelle, oder?
Genau.
Wer noch nicht mit Gitt gearbeitet hat und wem das hier alles so
schnell geht und das dürfte alle betreffen, die noch nicht mit Gitt
gearbeitet haben, also ist das im Grunde das Gleiche, denen empfehle
ich diesen Link tatsächlich.
Dort ist sehr gut aufgezeigt, wie Gitt funktioniert, wie man Gitt
benutzt, wahrscheinlich besser als wir das hier in der knappen Zeit,
die wir haben, je könnten.
Lesen Sie sich das durch, das hilft enorm.
Der wichtigste Punkt ist, dass SVN keine Deltas speichert, sondern
Schnappschüsse.
Wir erinnern uns, bei SVN und ähnlichen Versionskontrollsystemen sah
das so aus.
Wir haben Dateien ABC und wenn wir Änderungen von einer Revision zur
nächsten durchführen, dann haben wir eben immer diese Deltas.
Hier haben wir das erste Delta für Datei 1 und hier dann das zweite in
Version 4 und so weiter und so fort.
Immer auf Dateiebene mit den Deltas.
In Gitt sieht das ein bisschen anders aus.
Wir haben pro Commit ein Schnappschuss unserer Arbeitskopie.
Das bedeutet für Sie, Sie haben pro Version sofort alles zur Hand, was
Sie brauchen.
Wenn Sie zwischen den Versionen springen wollen, dann nehmen Sie
einfach den nächsten Snapshot und haben alle Informationen zur Hand.
Wie das intern funktioniert, sehen wir jetzt auch gleich.
Nehmen wir mal zum Beispiel drei Dateien, die in unserem Gitt
-Verzeichnis hinzugefügt werden und anschließend Committed werden.
Dann sieht das für Gitt wie folgt aus.
Wir haben pro Datei einen solchen Blob und darüber liegend haben wir
ein Tree-Objekt, was im Grunde diese Dateien verwaltet.
In diesem Tree-Objekt sehen wir dann auch der erste Blob mit dem Hash
5b1d3.
Das war die Datei readme, die wurde jetzt wohl hinzugefügt.
Und über diesen Tree-Objekten gibt es dann wieder diese Commit
-Objekte, die im Grunde alles einsammeln, was Sie brauchen für einen
Commit.
In dem Fall sind das diese drei Dateien.
Für die nächste Folie lassen wir jetzt diesen rechten Teil weg und
schauen uns an, wie das auf Commit-Ebene funktioniert.
Und da sehen Sie schon, wenn wir jetzt drei Commits machen, dann haben
wir drei dieser Commit-Objekte, die auch voneinander wissen.
Das heißt, wir haben hier den ersten Commit, der auch den netten
Logbuch -Eintrag Initial Commit hat.
Wir haben den nächsten Commit, der offensichtlich eine Änderung
durchführt, einen Bug fixt.
Und wie Sie sehen, weiß dieser Commit, dass dieser Commit der ältere
Commit war.
Das gleiche gilt auch wieder für den Commit.
Der weiß auch, dass wir hier diesen Commit als älterer Commit haben.
Und je nachdem, welchen Commit Sie anschauen, haben Sie einen
bestimmten Snapshot Ihres Arbeitsverzeichnisses und können mit diesem
arbeiten.
Wenn Sie GIT einfach so benutzen und nichts weiter tun, da kommt eine
Frage.
Im Grunde die, um es mit SVN-Wort zu sagen, die Revision, die Sie
gerade anschauen wollen.
Das heißt, der Zustand, der gerade aktuell war, als dieser Commit
gemacht wurde.
Sie können natürlich in Ihre Historie zurückspringen zu einem Commit,
der früher passiert ist und bekommen dann den Snapshot.
Das heißt, dass das Abbild Ihres Arbeitsverzeichnisses, wie er zu
diesem Zeitpunkt war.
Das verstehen wir in der Snapshot.
Also gefragt wurde, was das hier oben sagt.
Ich vermute einfach mal, das ist die Größe des Commits.
Fragen Sie mich nicht, was da drin steht.
Aber in dem GIT-Buch auf der URL ist es sicherlich erklärt.
Das ist gut.
Also wer das unbedingt wissen will und auch alle, die es nicht wissen
wollen, lesen Sie das Buch.
Es ist wirklich kurzweilig.
Es hat fast Roman-Feeling.
Also machen Sie das.
Das ist ernst gemeint.
Zurück zur Folie 65, auf der ich eigentlich war.
Wenn Sie einfach so mit GIT arbeiten, Ihre Commits tätigen, dann haben
Sie einen impliziten Entwicklungszweig und der nennt sich Master.
Das ist Ihr Hauptentwicklungszweig, auf dem Sie arbeiten.
Jetzt habe ich aber schon gesagt, die Versionsbildung ist integraler
Bestandteil von GIT.
Und jetzt ist natürlich die Frage, wie bekomme ich denn tatsächlich
andere Varianten.
Wenn ich eine neue Variante haben möchte, das heißt, ich möchte jetzt
Tests durchführen, dann lege ich mir mit dem Befehl GIT-Branch und
einem Namen, den ich mir selber wähle, eine neue Variante an.
Das heißt erstmal nicht mehr, als dass ein zweiter Zeiger hinzugefügt
wird und der heißt jetzt eben Testing.
Und er zeigt zunächst einmal auf den gleichen Commit, wie unser
Hauptentwicklungszweiger Master auch.
Jetzt kommt die Frage an Sie.
Woher weiß jetzt GIT, was der aktuelle Commit ist?
Also stellen Sie sich vor, ich könnte ja diesen Testingzeiger auch
verschieben, woanders hin.
Der könnte zum Beispiel auch hier drauf stehen.
Woher weiß ich jetzt als GIT, an welcher Stelle ich gerade bin?
Irgendjemand eine Idee?
Da vorne rechts schon wieder, ja.
Ich habe das Gefühl, Sie haben das Buch schon gelesen oder schon
anderweitig mit GIT gearbeitet.
Also da kam schon wieder die richtige Antwort aus der Ecke.
Wir haben ja gesagt, GIT arbeitet mit Objekten und wer mit Objekten
arbeitet, arbeitet auch gerne mit Zeigern.
Wir haben hier schon zwei Zeiger.
Da ist die Antwort, da geht einfach noch einer mehr.
Wir haben einen Zeiger, der auf den aktuellen Commit zeigt.
Beziehungsweise auf den Zeiger, der auf den aktuellen Commit zeigt.
Das ist jetzt in dem Fall Master.
Nächste Frage, was passiert jetzt, wenn ich zu dem Testing möchte?
Bitte, da oben.
Wir haben ja vorhin gesagt, wir haben mit GIT Branch diese neue
Variante da unten Testing erzeugt.
Das heißt aber noch lange nicht, dass wir damit arbeiten.
Wir bleiben weiterhin da oben bei dem Master stehen.
Wenn wir tatsächlich da unten arbeiten wollen, dann müssen wir unseren
Head Zeiger dorthin bewegen.
Und das ist genau der Punkt, wo jetzt das GIT Checkout ins Spiel
kommt.
Wenn ich jetzt sage, GIT Checkout Testing, dann komme ich hier runter.
Mein Zeiger zeigt nach dort.
Alle Änderungen, die ich dann ab dort tätige, passieren auf dieser
Variante Testing, auf dem Branch Testing.
Sie können Ihren Head Zeiger auch noch anders verschieben.
Also es hält Sie niemand davon ab, mit einem GIT Checkout 34AC2 auf
diesen Commit in der Historie zuvor zeigen zu lassen.
Das ist auch gar kein Problem, dann sind Sie eben auf dem Stand, wie
in Ihrer Arbeitskopie zur Zeit dieses Commits war.
Angenommen, wir machen im Testing-Zweig eine Änderung und buchen Sie
ein.
Was passiert?
Die Antwort sehen Sie gleich auf der Folie, aber vielleicht möchte
noch jemand vorher was sagen.
Ich habe es schon so ungefähr angedeutet.
Und ich sage es vorneweg, Sie und Sie sind raus für die Frage.
Vielleicht mal jemand anders.
Also Sie wissen ja noch, ja da oben meldet sich schon jemand.
Ich mache mal nochmal die Folie auf, vielleicht hilft Ihnen das.
Da oben bitte.
Okay, das heißt, wie sieht es aus?
Was passiert?
Ich habe hier einen neuen Commit-Knoten.
Habe ich das richtig verstanden?
Ja, das ist so.
Ich deute das mal als richtig.
Ich zeige Ihnen mal, wie das aussieht.
So sieht das dann aus.
Das heißt, ich habe einen neuen Commit und mein Testing und mein
Headzeiger, die wandern mit.
Und jetzt kommt die ganz einfache Frage.
Was passiert, wenn ich zurück zum Master möchte?
Sie kommen aus derselben Ecke, aber Sie haben noch nichts gesagt.
Sie dürfen.
Welchen Befehl müsste ich ausführen?
Genau.
Also die Antwort ist, ich bräuchte dann wieder einen Git-Checkout
-Master.
Und dann wandert mein Headzeiger zurück zum Master.
Was mit dem Zeiger passiert, das habe ich jetzt schon gesagt.
Was passiert mit den Dateien?
Sie waren leider schon, tut mir leid.
Eigentlich auch nicht so schwierig.
Die Frage wurde auch schon mehr oder weniger beantwortet, vorhin mal
so zwischendrin bei einer anderen Nachfrage.
Sie dürfen sich ruhig trauen.
Man hört nur mich auf der Aufzeichnung.
Wenn ich jetzt auf den Master zurückspringe, haben wir wieder den
Snapshot, den wir hier hatten.
Das heißt, Sie sehen dann Ihre Dateien so, wie sie zu diesem Commit
-Zeitpunkt aussahen.
Und jetzt kommt eigentlich der spannende Teil, für den wir leider
nicht so richtig Zeit haben.
Und hier kommt der zweite Verweis auf das Buch.
Ich kann das nicht so gut erklären, wie das dort überhaupt erklärt
wird.
In Sprachform lesen Sie das durch, wie das funktioniert.
Hier sehen Sie kurz schematisch, wie das Verschmelzen jetzt in Git
funktioniert.
Wir arbeiten auf unserem Hauptzweig, fangen an mit einem Commit 0,
gehen zu einem Commit 1, weiter Commit 2.
Und an der Stelle trennen wir jetzt auf.
Wir haben hier unten diesen Branch, ISS 53, Issue 53 vielleicht.
Das heißt, irgendeine Fehlerbehebung, von der wir abzweigen, ab C2.
Und bekommen dann diese zweite Entwicklungslinie, auf der wir
Änderungen durchführen und den Fehler vielleicht beheben.
Wir brauchen dafür zwei Commits.
Blöderweise steht, wenn Sie was reparieren, die Welt nicht still.
Sondern jemand auf dem Masterzweig arbeitet auch weiter.
Der legt hier diesen Commit C4 in der Zwischenzeit an.
Das heißt, Sie müssen das Ganze jetzt irgendwie zusammenführen.
Und Sie sehen ja, Sie haben jetzt hier zwei unterschiedliche Zustände,
die Sie zusammenführen müssen.
Sie haben den aktuellen Zustand C5, auf dem Sie Ihre Änderungen
einfügen.
Und in der Zwischenzeit hat sich auch im Hauptzweig der Commit C4
gebildet.
Und Sie möchten diese beiden jetzt zusammenführen.
Was Sie dazu machen müssen, ist zunächst einmal, wenn Sie hier
gearbeitet haben, dann sind Sie ja aktuell mit Ihrem Headzeiger auf
dem Issue 53 Branch noch drauf.
Dann müssen Sie erstmal zurück in den Master.
Dafür benutzen Sie einen Git-Checkout-Master.
Und dann sind Sie im Grunde hier oben.
Und das ist auch genau der Snapshot, in den dieser Snapshot integriert
werden soll.
Das heißt, Sie sind dann hier wieder an diesem Punkt.
Dieser Pointer, der leider jetzt schon hier rechts ist, der steht
eigentlich noch dort, zusammen mit dem Head.
Und an dieser Stelle führen Sie dann ein Git-Merge aus.
Und entweder funktioniert das reibungslos und Sie können einfach, weil
die Änderungen an unterschiedlichen Stellen durchgeführt wurden,
einfach einen neuen Commit haben auf dem Hauptentwicklungszweig, indem
dann beide Änderungen von hier unten und von hier oben zusammengeführt
sind.
Oder Sie müssen das vorhanden aufräumen.
Genau, das war es soweit zu Git.
Jetzt bitten wir uns der Frage, wir haben hier unten einen Fehler
behoben.
Wie haben wir den denn überhaupt gefunden?
Und darauf ist die Antwort testen, testen, testen.
Jetzt kommt noch eine Frage, stelle ich gerade fest.
Ja.
Das ist ein bisschen eine schwierige Frage.
Also die Frage ist, wenn ich einen Commit auschecke, der weiter
zurückliegt, direkt, dann soll ich die Frage überhaupt beantworten,
macht das Sinn?
Ja, die Antwort ist, man macht es nicht.
Sie wechseln auf diesen älteren Commit zurück, sagen Git Checkout 34
AC2 und legen dann dort erstmal einen neuen Branch an.
In diesen Branch commiten Sie dann rein.
Sie können natürlich auch direkt auf diesen Commit weiterarbeiten,
aber das ist eine blöde Idee, weil der hat dann keinen Namen außer
seinem Hash und das ist äußerst unübersichtlich.
Git warnt Sie auch davor, das zu tun, aber es hindert Sie nicht dran.
Aber die Antwort ist, wenn Sie irgendwo sind in Ihrem Git Graph und
Sie wollen einen Commit machen, dann sollten Sie in einem Branch sein.
Dementsprechend einfach einen neuen anlegen und dann geht das relativ
einfach.
Zu der Folie habe ich noch einen kleinen Nachtrag.
Sebastian hat uns erzählt, jeder Git-Knoten, jeder Git-Commit hat
einen Elternknoten.
Das gilt für C1, 2, 4, 3 und 5.
Das gilt nicht für C0.
C0 hat keinen Vorgänger, das ist der erste.
Und das gilt auch nicht für welche, die einen Merge-Commit darstellen.
Die haben mehr als einen, nämlich den Zweig, auf dem man gerade
gearbeitet hat, plus den, den man reinmergen will.
Und das endet auch nicht bei zwei.
Man kann mit Git ganz lustige Dinge machen.
Die Anzahl der Eltern ist nicht begrenzt.
Gut, dann kommen wir zum Testen.
Sie haben Testen schon kennengelernt in der Programmieren-Vorlesung.
Wer hat denn schon einen JUnit-Testfall geschrieben?
Okay.
Von denen, die sich nicht gemeldet haben.
Wer weiß, was eine Java-Annotation ist?
Okay.
Die Frage ist, wie findet man Fehler und was verstehen wir unter einem
Testfall?
Ein Testfall ist das Ausführen des Programms, das Sie vor sich haben,
unter bestimmten Bedingungen und Sie haben die Eingabedaten gegeben
und dementsprechend wissen Sie auch, was die Ausgabedaten, die
Reaktionen Ihres Programms sein sollen.
Und das Ziel vom Testen, Aufdecken von Defekten.
Nicht das Sicherstellen von Korrektheit, sondern das Aufdecken von
Defekten.
Und ein Testfall ist nur dann ein guter Testfall, wenn er sich selbst
überprüft.
Es nützt nichts, wenn Sie mit einem Block da sitzen und abhaken oder
Kreuzchen machen, sondern Sie möchten eigentlich einen Testfall haben,
der selbst wieder ein Programm ist und der im Erfolgsfall einfach gar
nichts tut, ohne Meldung durchläuft und im Fehlerfall Sie darauf
hinweist, dass dieser Testfall fehlgeschlagen ist.
Stich das Programm was anderes geliefert hat, als Ihre ursprüngliche
Erwartung war.
Und der Vorteil ist, wenn Sie Testfälle haben, die Programme sind,
dann können Sie diese Testprogramme alle zusammenfassen, automatisch
ausführen und haben einen sehr effizienten Überblick darüber, ob Ihr
Programm an diesen Stellen, die Sie getestet haben, Fehler enthält
oder nicht.
Und das Schicke ist, wenn Sie so eine Menge von Testfällen haben, dann
können Sie die verwenden zum Regressionstesten.
Sprich, Sie bauen eine große Testmenge auf, dann gehen Sie zwei Wochen
in Urlaub und der Kollege entwickelt das Programm weiter.
Wenn Sie zurückkommen, dann führen Sie einfach alle Testfälle, die Sie
gesammelt haben, nochmal aus.
Wenn jetzt einer rot ist und fehlschlägt, dann hat der Kollege was
kaputt gemacht.
Dann hauen Sie ihm auf die Finger.
Deswegen, Tests, die automatisch ausführbar sind und die sich selbst
prüfen können, das ist genau das, was wir haben wollen.
Und das Schöne ist, eine Maschine führt das aus.
Das heißt, wir können das beliebig oft machen.
Täglich, stündlich, nach jeder Änderung, die wir ins Git eingecheckt
haben.
Je nachdem, was für eine Häufigkeit da angebracht ist.
Wenn da Reports rauskommen, können Sie die an Ihren Chef schicken.
Frei nach dem Motto, ist alles grün.
Ampeln sind immer toll fürs Management.
Damit können Sie eine Ampel erzeugen.
Und zwar sehr billig, wenn Sie die Testfälle mal geschrieben haben.
Ein Werkzeug, mit dem man Testfälle schreiben kann in Java, ist JUnit.
Wir benutzen JUnit 4.
Und damit können Sie Testfälle zu Testmengen zusammenfassen.
Und JUnit liefert Ihnen dann alle Testfälle, die fehlgeschlagen sind.
Sie müssen sich also nicht alle angucken, die Sie gesammelt haben,
sondern JUnit weist Sie genau darauf hin.
Es gibt ähnliche Werkzeuge wie JUnit für, ich behaupte mal, annähernd
alle Programmiersprachen.
Die heißen dann NUnit für .NET oder PHPUnit für PHP.
Sie kriegen die Idee.
Wenn Sie mal was programmieren, außerhalb der Java-Welt, gucken Sie,
wie das Unit Testing Framework für diese Programmiersprache heißt, das
da gerade benutzt wird.
Dann schreiben Sie Ihre Testfälle damit und sind damit auf der
sicheren Seite.
Oder auf einer sichereren Seite als ohne.
Eine Testklasse in JUnit enthält mehrere Testfälle.
Jeder Testfall sollte eine Methode sein.
Und diese Testmethode, die enthält verschiedene Dinge, nämlich die
sorgt dafür, dass das Programm einen bestimmten Zustand hat.
Dann führt es Befehle auf dem Programm aus und dann prüft es, ob das
Ergebnis korrekt ist.
Das heißt, Sie haben alles, was ich gerade gesagt hatte, in so einer
Testmethode drin.
Den Aufbau von einem bekannten Zustand, die Änderungen am
Programmzustand und Sie haben eine Erwartungshaltung, die geprüft
werden kann.
Wenn Sie einen Testfall schreiben, der keine Erwartungshaltung hat,
dann ist das kein Testfall.
Das ist ganz einfach.
Wenn Sie das Programm ausführen und sagen, der Test ist grün, wenn es
nicht abstürzt, das reicht nicht.
Sie müssen genau sagen, was Sie vom Programm erwarten und das müssen
Sie im Testfall auch hin kodieren.
Nur dann gilt es als Testfall.
Dass eine Methode ein Testfall ist, das wird mit einer Annotation
gekennzeichnet.
Deswegen habe ich nach Annotations gefragt.
Das gibt es seit Java 5 und Sie können mit Annotationen
Metainformationen an Dinge im Quelltext dran schreiben.
Und zwar an alle Deklarationen.
Das heißt an Pakete, Klassen, Schnittstellen, Variablen, Methoden,
Parameter usw.
Zum Beispiel gibt es eine Annotation, die heißt Deprecated.
Die weist Sie darauf hin, dass Sie diese Methode nicht mehr benutzen
sollten, weil sie veraltet ist.
Sie können das trotzdem tun, niemand hindert Sie daran, aber der Java
-Übersetzer wird Sie warnen, zumindest wenn Sie den richtig
eingestellt haben, dass diese Methode benutzt wird.
Eclipse wird Sie auch darauf hinweisen.
Sie rufen hier was auf, was eigentlich nicht mehr benutzt werden soll.
Im Editor wird dann die Methode tatsächlich durchgestrichen.
Sie können sie trotzdem benutzen, aber Sie müssen damit rechnen, dass
es in Zukunft kaputt geht.
Umgekehrt, wenn Sie eine API betreuen, sagen wir eine Bibliothek, die
Sie vertreiben, und Sie möchten eine Methode wegwerfen, dann tun Sie
das nicht gleich, sondern Sie markieren die als veraltet.
Lassen Sie mal noch drin, damit Ihre Kunden feststellen, oh, Sie
benutzen hier veraltete Funktionalität und in einer späteren Version
löschen Sie die dann.
Dafür kann man Annotations benutzen und auch in JUnit werden die
benutzt.
Sie sehen hier ein Beispiel für JUnit.
Ich muss mal ein Stück nach hinten, damit ich alles sehen kann.
Das ist eine ganze Klasse, die Testfälle zusammenfasst.
Sie sehen hier, das ist ein Test für eine Bibliothek.
Es gibt auch eine private Bibliothek, die nur diesem Testfall gehört.
Ich habe sie gesehen und ich komme gleich auf sie zu.
Und es gibt einen Testcase.
Buch ist in Bibliothek, ist der Name von dem Testfall, dass es einer
ist, das sehen Sie an der AddTest-Annotation.
Und die Erwartungshaltung, der tatsächliche Test, der ist in diesem
AssertTrue drin.
Und AssertTrue prüft, ob das Argument in diesem Fall B tatsächlich
wahr ist.
Solange B den Wert wahr hat, ist alles in Ordnung und JUnit lässt sie
in Frieden.
Wenn der Wert aber aus irgendeinem Grund auf falsch wechselt, weil
dieser Aufruf hier feststellt, Faust ist nicht in der Bibliothek drin,
dann wird dieser Testfall rot und dann müssen Sie sich darum kümmern,
dass der Fehler behoben wird.
Bevor der Testfall ausgeführt wird, gibt es noch einen Aufruf an
Methoden, die mit AddBefore gekennzeichnet worden sind.
In dem Fall wird hier eine neue Bibliothek angelegt.
Und nachdem der Testfall gelaufen ist, werden die Methoden ausgeführt,
die mit AddAfter gekennzeichnet sind.
Das ist quasi herstellen von einem konsistenten Zustand und aufräumen,
wenn man den Testfall beendet hat.
Und er stellt eine Frage zu dieser Deprecated-Annotation im
Hintergrund und versucht das mal in zwei Sätze zu fassen.
Wenn Sie eine Bibliothek herstellen, ist es dann besserer Stil, eine
Methode mit Deprecated zu markieren und quasi einzuräumen?
Wer die benutzt, ist selbst schuld.
Das könnte zu Fehlern führen.
Oder ist es besserer Stil, die Methode gleich zu entfernen?
Die Antwort ist, das ist eine gute Antwort für mündliche Prüfungen,
nicht für schriftliche.
Es kommt darauf an.
Und zwar darauf, was Ihre Kunden so gerne von Ihnen hätten.
Wenn Sie eine Milliarde Kunden haben und die benutzen alle diese
Methode, dann steigen die Ihnen aufs Dach, wenn Sie sie einfach
löschen.
Wenn die niemand benutzt und die hauptsächlich intern gebraucht wird,
die aber noch nicht fertig sind mit Aufräumen und nur sicherstellen
wollen, dass jetzt kein neuer Code geschrieben wird, der die auch noch
benutzt, dann ist so eine Markierung wahrscheinlich besser.
Das hängt vom Anwendungsfall ab.
Ihr Kommilitone fragt, wenn ich jetzt eine Klasse habe und ich
schreibe da die ganzen Tests rein und markiere die mit AddTest,
versaut mir das nicht meine AP?
Weil ich habe ja dann ganz viele Methoden, die eigentlich nur zum
Testen da sind.
Die Antwort ist ja.
Und aus diesem Grund schreiben Sie die Tests nicht in die Klasse, die
Sie testen, sondern Sie machen separat eine daneben.
Sie haben eine Klasse, in dem Beispiel Bibliothek.
Das ist die Klasse, die getestet wird.
Und Sie haben eine Klasse Bibliothek Test.
Da sind die ganzen Testfälle drin.
Und das hat den großen Vorteil, dass Sie a.
nicht Ihre API verschmutzen mit Testmethoden und b.
hat es den großen Vorteil, dass Sie Ihre Tests nicht an den Kunden
ausliefern müssen.
Weil dem geben Sie die Testklasse einfach nicht.
Der hat damit nichts zu tun.
Die Frage von hier vorne ist, wie teste ich private Methoden?
Gar nicht, weil auf die können Sie nicht zugreifen, außer mit
Reflection.
Das ist eher eine blöde Idee.
Sie würden wahrscheinlich die Sichtbarkeit ein bisschen größer machen,
das vielleicht auf Package-Sichtbarkeit machen und die Testklasse ins
gleiche Paket legen.
Oder Sie testen eine Methode, die diese private benutzt.
Aber wie man feststellt, welche Teile einer Klasse man getestet hat
oder nicht, das sehen wir später auf den Folien.
Das hatten wir alles.
Jetzt kommen die Annotationen, die man so braucht.
AddTest haben wir schon gesehen.
Damit wird ein Testfall markiert.
Die Annotation Test kann auch Argumente haben.
Zum Beispiel ExpectedSQLExceptionClass heißt, ich erwarte, dass in
diesem Testfall eine Ausnahme auftritt.
Dieser Testfall wird nur dann grün, wenn die Ausnahme ausgelöst wird.
Wenn da keine Ausnahme kommt, dann wird der rot.
Man kann auch sagen, der Test darf nur 42 Millisekunden laufen, danach
wird er abgebrochen.
Wenn es länger dauert, ist der Test rot.
Mit AddIgnore kann ich Tests schreiben, aber JUnit darauf hinweisen,
dass die noch nicht ausgeführt werden sollen.
Zum Beispiel, weil ich die Funktionalität noch gar nicht implementiert
habe.
Bevor und After hatten wir gerade schon.
Bevor und After werden vor jedem Testfall ausgeführt.
Es gibt noch ein Gegenstück dazu, das ist BeforeClass und AfterClass.
Das wird einmal ausgeführt, vor allen Testfällen in einer Testklasse.
Wir sehen gleich, wie das aussieht.
Hier ist jetzt ein etwas umfangreicherer Test.
Da sehen wir, es gibt eine BeforeClass Verbinde mit Datenbank.
Ein Datenbankaufbau ist teuer, das will man nur einmal machen.
Es gibt ein AfterClass, der die Verbindung wieder trennt.
Das braucht man dann entsprechend auch nur einmal.
Und dazwischen gibt es zwei Testfälle und einmal Before und einmal
After.
Wenn man das jetzt mit JUnit ausführt, dann wird zuerst die Methode
Verbinde mit DB aufgerufen.
Dann die BauerAuf-Methode, die mit AddBefore gekennzeichnet ist.
Und dann der erste Testfall.
Danach kommt die RäumerAuf-Methode, die ist mit AddAfter
gekennzeichnet.
Und dann kommt der nächste Aufbau.
Das heißt, da kommt dann nochmal BauerAuf, das ist Schnitt 5.
Und danach kommt erst BuchAusleihen.
Und nach BuchAusleihen kommt dann natürlich wieder RäumerAuf.
Allerdings können Sie sich nicht darauf verlassen, dass die Tests
genau in der Reihenfolge ausgeführt werden, wie sie hier stehen.
Es könnte auch sein, dass Schritt 3 und 6 umgekehrt passieren.
Schreiben Sie nie Testfälle, die voneinander abhängen.
Jede Testmethode muss für sich alleine genommen sinnvoll sein und ein
Testfall darstellen.
Und wie gesagt, ganz am Ende wird dann nochmal aufgeräumt.
Sie können in Eclipse die ganzen Testfälle laufen lassen.
JUnit ist eigentlich ein Kommandozeilen-Werkzeug, aber Sie können im
Kontextmenü einfach sagen, Eclipse, bitte führe mir diese Datei als
JUnit -Testfall aus.
Und Sie sehen dann, in diesem Fall gibt es einen Testfall und der ist
fehlgeschlagen.
Das heißt, hier haben Sie einen roten, das ist blöd.
Wenn der Testfall nicht fehlschlägt, dann sieht das Ganze so aus.
Keine Fehler, keiner ist gelaufen.
Benutzen Sie es am besten in Eclipse, ein bisschen handlicher.
Wer das noch nie gemacht hat, bitte ausprobieren.
Wichtig, wann immer Sie einen Fehler finden und beheben, schreiben Sie
einen Testfall, der genau diesen Fehler auslöst und dann prüft.
Das heißt nämlich, wenn Sie den Fehler korrigiert haben, dann stellen
Sie mit diesem Testfall sicher, dass nicht der Kollege kommt und den
Fehler gleich wieder einbaut.
JUnit-Test und ähnliche Werkzeuge sind deswegen extrem wichtig.
Das ist nicht nur hier in der Vorlesung so, sondern auch in der
Praxis.
Es ist tatsächlich so, dass in normalen Projekten, die Wert auf Testen
legen, der Produktivcode ungefähr 30 bis 50 Prozent des
Gesamtcodebestands ausmacht.
Das heißt, die Hälfte ungefähr des Codes, den Sie programmieren, ist
Testcode.
Das ist nichts, was ich mir hier ausgedacht habe und das ist toll für
die Uni, sondern Testen ist wirklich wichtig und Testen ist auch
Aufwand.
Machen Sie sich das klar und machen Sie das auch Ihrem Chef klar.
Wenn der sagt, schreiben Sie Tests, Sie haben dafür fünf Minuten, wird
nicht funktionieren.
Und damit es sinnvoll ist, müssen die Testfälle sich selbstständig
überprüfen.
Sie müssen immer so eine Zusicherung reinschreiben.
Wenn Sie keine Zusicherung drin haben, ist der Test ziemlich wertlos.
Jetzt kommt die Sache, woher weiß ich, was ich schon getestet habe.
Es gibt ein Werkzeug, das heißt Emma oder E-Clammer als Eclipse
-Plugin.
Das sollten Sie auf dem Vorbereitungsblatt schon mal gehört haben.
E-Clammer ist ein Werkzeug, mit dem Sie Testfälle ausführen.
Und E-Clammer oder Emma registriert dann, welche Codezeilen von Ihrem
Produktivcode ausgeführt worden sind.
Sie sehen also, ob die private Methode getestet wurde oder nicht.
Und dann können Sie sich Überblick geben lassen.
Und hier ist jetzt ein Beispiel, diese Methode hier, die Test Y3x, die
ist vollständig abgedeckt.
Alle Zeilen sind grün, aber die Methode hier oben, zwar public, aber
die ist trotzdem nicht getestet.
Das heißt, hier ist irgendwas schief gelaufen.
Wir wollen noch einen Testfall haben, der auch die obere Methode
abdeckt.
Damit können Sie sicherstellen, dass Sie den Überblick kriegen, was
getestet wurde und was nicht.
Und Sie können sich auch sagen lassen, welche Methode oder Klasse oder
welches Paket Sie zu wie viel Prozent getestet haben.
Das heißt, Emma gibt Ihnen da so ein Schätzeisen, mit dem Sie gucken
können, wie gut Sie gerade im Testen sind.
Hier kommt eine Tonefrage.
Kann man das auch beim normalen Ausprobieren vom Programm benutzen?
Sinngemäß, was habe ich alles ausprobiert, ohne dass es abgestürzt
ist?
Nein.
Es gibt sicherlich Werkzeuge, die das leisten.
Ich weiß aber nicht, ob man das mit Emma hinkriegt.
Vermutlich können Sie einfach einen Testfall schreiben, der Ihr
Programm startet.
Dann klicken Sie in der GUI rum und beenden das Programm wieder.
Das müsste ziemlich genau diesen Effekt hervorrufen, aber das müssten
Sie ausprobieren.
Das habe ich noch nicht getan.
So, das habe ich Ihnen gesagt.
Genau.
Was Sie jetzt tun müssen, bevor Sie Code verpacken in einen Jar, wie
wir das letzte Woche gemacht haben, ist, Sie müssen es entwickeln, Sie
müssen Tests schreiben, Sie müssen Coding Conventions einhalten, Sie
müssen eine neue Revision in die Versionskontrolle einbuchen, Sie
müssen Reports an Ihren Chef schicken, Sie müssen das Ganze verpacken
und ausliefern und wenn Sie nicht alleine arbeiten, müssen Sie auch
Ihren Kollegen Bescheid sagen, dass sich was geändert hat.
Das ist alles ziemlich viel Arbeit und das müssen Sie irgendwie
erledigen.
Aber Sie sind Profis.
Immer wenn etwas stupide ist, sollten Sie sich ein Werkzeug hernehmen,
das das für Sie macht.
Und ein Werkzeug, das das leistet, ist Maven.
Maven automatisiert einzelne Schritte, das automatisiert leider nicht
das Programmieren, aber alles, was Sie so ums Programmieren drumherum
mit dem Quelltext machen, können Sie damit steuern.
Das ist ein Werkzeug von Apache und das kann den Code übersetzen mit
dem Java-Übersetzer, das kann dafür sorgen, dass Sie Bibliotheken, die
Sie brauchen, auch lokal auf Ihrem Rechner haben, in der richtigen
Version, zum richtigen Zeitpunkt.
Das kann Ihr Programm, wenn es kompiliert und alle Testfälle grün
sind, verpacken in ein JAR und ausliefern und das kann sogar Berichte
erstellen und irgendwo hinschicken, auf eine Webseite hochladen oder
ähnliches.
Das heißt, es ist sehr praktisch, wenn Sie das im Griff haben und wenn
Sie das Vorbereitungsblatt angefasst haben, Sie müssen mit Maven
arbeiten in der Softwaretechnik und zwar nicht nur auf dem
Vorbereitungsblatt, sondern bis zum Ende des Semesters.
Das heißt, üben Sie jetzt, mit Maven umzugehen, das hat ein paar Ecken
und Kanten und bis Sie sich da, sagen wir mal, reingedacht haben,
werden ein paar Minuten vergehen.
Es ist sehr lohnenswert, wenn Sie diese Minuten jetzt investieren und
nicht auf Übungsblatt 5, wenn Ihnen noch 100 Punkte fehlen.
Sie werden das brauchen, jede Programmieraufgabe müssen Sie mit Maven
verpacken oder es irgendwie erreichen, dass das, was Sie abgeben,
genauso aussieht.
Und glauben Sie mir, das mit Maven verpacken, das geht einfacher.
Genau, das habe ich im Prinzip gesagt.
Was relativ wichtig ist, Maven standardisiert einige Dinge.
Das heißt, Sie bekommen eine zusätzliche Projektdatei, der drinsteht,
wie das Projekt so aussieht und wie das funktioniert.
Und Sie bekommen ein Verzeichnis-Layout vorgegeben, wo Sie Ihre
Dateien abzulegen haben.
Sprich, wo liegt der Quellcode, wo liegen Bilddateien, die Sie
brauchen als Ressourcen, wo lege ich meine Testklassen ab und so
weiter.
Und diese Übersicht sieht so aus, dass Sie in einem Projektverzeichnis
ein Verzeichnis haben, das heißt Source, da liegen die ganzen Quellen
drin.
Und wenn Sie was kompilieren, dann wird das Verzeichnis Target
angelegt und alles, was da drin ist, heißt, wenn Sie arbeiten und
entwickeln, bewegen Sie sich in dem Source-Zweig.
Wenn Sie was bauen, verpacken, laufen lassen wollen, befinden Sie sich
im Target-Verzeichnis.
Wenn Sie das Ganze ins Git reinlegen, dann würden Sie Target ziemlich
sicher ausschließen vom Git, weil was da reinkommt, können Sie
jederzeit neu erzeugen.
So, jetzt habe ich Ihnen gesagt, Sie trennen die Dateien vom
Produktivcode und den Testcode.
Das sind die beiden Verzeichnisse Main und Test.
Und unterhalb von Main und Test liegt zweimal im Grunde das Gleiche,
nämlich Konfigurationsdateien oder Java Quellcode oder irgendwelche
Ressourcen.
Wenn Sie ein Projekt anfangen, legt Ihnen Maven diese Struktur an und
Sie müssen im Prinzip nur noch Ihre Dateien dort ablegen, wo sie
hingehören.
Wenn Sie das machen, haben Sie deutlich weniger Aufwand, als wenn Sie
alles in ein Verzeichnis legen und darauf hoffen, dass das in zwei
Jahren noch verständlich ist.
Wir brauchen ein bisschen Vokabular.
Bis jetzt haben wir von Projekt gesprochen und vielleicht von
Artefakten.
In Maven gibt es Archetypes, das sind die Vorlagen, die Sie sich
erzeugen lassen können.
Sie können in Eclipse auch sagen, wenn Sie sagen Create New Project,
dann haben Sie eine Auswahl, normalerweise mit Java Projekt und sowas.
Da gibt es auch einen Punkt Maven, da können Sie neue Maven-Projekte
anlegen.
Das ist der Punkt, den Sie brauchen.
Sie werden dann gefragt, wie soll dieses Artefakt heißen?
Und der Name setzt sich zusammen aus der Artifact-ID und der Group-ID.
Die Group, das ist sowas wie ein Paket in Java.
Die Artifact-ID, das ist der Name von dem Artefakt.
Das heißt, Sie können innerhalb von einer Gruppe mehrere Artefakte
haben, die anderen Namen haben.
Und natürlich bekommt dann so ein Artefakt auch noch eine Version.
Dann können Sie loslegen.
Wenn Sie mit Maven arbeiten wollen, das ist in Eclipse integriert als
Plugin.
Da gibt es eine hübsche GUI.
Ihr Kommilitone stellt eine Frage zum Archetype, nämlich ist der fest,
wenn ich den einmal habe, oder kann ich das später ändern?
Dieser Archetype, der sorgt dafür, dass Sie ein Projektverzeichnis
bekommen, das gewissen Konventionen folgt.
Zum Beispiel ein Java-Projekt darstellt für eine normale Applikation
oder für eine Web-Applikation, die Sie in der Comcat laufen lassen.
Und natürlich können Sie hinterher alles umräumen und umschieben und
umkonfigurieren, um von einem zum anderen zu kommen.
Aber es ist vermutlich besser, Sie wählen gleich am Anfang das
Richtige.
Es gibt einen Hello-World-Standard-Anwendungsfall, den sollten Sie
dann wählen.
Wenn Sie mit Maven arbeiten, können Sie das in Eclipse tun.
Das ist integriert in der Java-Variante, aber es gibt natürlich die
Kommando -Zeilen-Variante, mit der Sie sehr viel mehr Dinge tun
können, wenn Sie denn wissen, wie.
Befehle sind immer so, dass Sie mvn eingeben, um das Programm zu
starten.
Und hinten dran gibt es dann den Aufruf, der sich trennt in Plugin und
Goal.
Ganz einfach deswegen, weil Programmfunktionalität in Maven sehr stark
strukturiert ist.
Und da gibt es halt verschiedene Plugins, die unterschiedliche Dinge
tun, zum Beispiel Versionskontrolle machen oder Code übersetzen oder
testen.
Und was Sie genau haben wollen, schreiben Sie hinten beim Goal hin.
Normalerweise werden Sie in den Übungen nur brauchen Maven Compile,
Test und Package.
Und die anderen Dinge, die können Sie sich anschauen, wenn Sie Lust
dazu haben.
So, jetzt muss ich mal gucken.
Das machen Sie über Eclipse.
Aber ich glaube, das erzähle ich Ihnen am Montag ausführlich, sonst
geht das hier durcheinander.