Inhaltsverzeichnis

1. Was ist das V-Modell?

Wie sich direkt erkennen lässt, ist das V-Modell wieder in einzelne Phasen unterteilt. Jeder blaue Kasten repräsentiert dabei eine Phase im Entwicklungsprozess. Das erinnert stark an das Wasserfallmodell, das wir im vorherigen Beitrag kennengelernt haben.

2. Wie funktioniert das V-Modell?

Genau wie beim Wasserfallmodell muss man auch beim V-Modell eine Phase vollständig abschließen, bevor man zur nächsten übergehen kann.

Auch hier gibt es also wieder eine sequenzielle Abfolge, was bedeutet, dass alles der Reihe nach durchlaufen wird. Beim Wasserfallmodell zuvor hatten wir so gesehen nur die linke Seite des Prozesses, was den Wasserfall-Effekt erzeugt hat, da die Phasen nacheinander wie eine Kaskade nach unten abliefen.

Im Gegensatz zum Wasserfallmodell, das nur die Phasen auf der linken Seite zeigt, verläuft das V-Modell auf beiden Seiten. Das V-Modell verdankt seinen Namen der markanten V-Form, die sich auch in der Grafik erkennen lässt. 

Auf der linken Seite verlaufen die Phasen nach unten, während sie auf der rechten Seite wieder nach oben führen. So entsteht die typische V-Form.

Sieht man sich das Modell genauer an, könnte man die linke Seite als die Entwurfsseite bezeichnen, denn dort sind all die Phasen aufgeführt, die für den Entwurf verantwortlich sind. 

In der Mitte, am unteren Punkt des "V" befindet sich die Programmierung, also die Implementierung des gesamten Entwurfs.

Auf der rechten Seite folgen dann die Testphasen. Damit lässt sich zusammenfassen, dass die linke Seite für den Entwurf und die Konstruktion steht, während die rechte Seite für das Testen der entwickelten Software verantwortlich ist.

Beim V-Modell ist wichtig zu verstehen, dass jeder Konstruktions- bzw. Entwurfsphase eine entsprechende Testphase direkt gegenübersteht. 

Was das genau bedeutet, werden wir uns gleich noch genauer ansehen.

3. Die Phasen des V-Modells

Genau wie beim Wasserfallmodell nimmt der Detailierungsgrad nach unten hin zu. Je weiter man sich also nach unten bewegt, desto ausführlicher werden die Phasen.

Das bedeutet, dass man oben mit einer groben fachlichen Spezifikation beginnt, die nach unten hin immer detaillierter wird und am Ende den gesamten Entwurf in Programmcode umsetzt.

In der Spitze des "V" findet die Implementierung statt und auf der rechten Seite folgen die entsprechenden Testphasen. Da jeder Konstruktions- bzw. Entwurfsphase direkt eine Testphase gegenübersteht, sorgt dieses Modell für eine sehr hohe Testabdeckung.

Dadurch wird sichergestellt, dass alle Aspekte der Software gründlich geprüft werden. 

3.1 Phase 1: Die Anforderungsanalyse

Wie bereits erwähnt, liegt der Startpunkt des V-Modells bei der Anforderungsanalyse, die sich links oben befindet. In dieser Phase werden zunächst die Anforderungen an das System festgelegt. Daraufhin folgt die Phase des funktionalen Systementwurfs.

3.2 Phase 2: Der funktionale Systementwurf

In dieser Phase dreht sich alles um die Systemanforderungen. Aus der sogenannten Blackbox-Sicht wird beschrieben, wie das System die zuvor festgelegten Anforderungen umsetzen soll. Dabei ist es wichtig, das Ganze aus einer übergeordneten Perspektive zu betrachten und sich grob zu überlegen, wie das System ablaufen soll.

Das bedeutet, dass in dieser Phase noch nicht die technische Umsetzung des Systems festgelegt wird, da der Fokus hier ausschließlich auf der Blackbox-Sicht liegt. Es geht also darum, das System von oben zu betrachten, ohne sich in technischen Details zu verlieren.

3.3 Phase 3: Der technische Systementwurf

Nach der funktionalen Phase folgt der technische Systementwurf. Hier dreht sich alles um die konkrete Systemarchitektur. Es geht dabei darum, zu entscheiden, wie das System technisch umgesetzt wird. In dieser Phase werden alle wichtigen Designentscheidungen getroffen, damit sich die Entwickler bei der späteren Implementierung an diesen Entwurf halten können, ohne selbst noch über das Design nachdenken zu müssen.

Das bedeutet, dass von Anfang an alles strukturiert durchgeplant wird und wenn es dann an die tatsächliche Umsetzung geht, der gesamte Plan bereits feststeht. Die Entwickler können sich also darauf verlassen und das Projekt Schritt für Schritt umsetzen, ohne weitere grundlegende Entscheidungen treffen zu müssen.

3.4 Phase 4: Die Komponentenspezifikation

Nach Abschluss der technischen Systementwurfsphase folgt die Komponentenspezifikation. Hier geht es um eine noch detailliertere Beschreibung der einzelnen Systemkomponenten. Sobald diese spezifiziert sind, geht es in die nächste Phase: die Programmierung bzw. Implementierung.

3.5 Phase 5: Die Implementierung

Die Entwickler orientieren sich nun am zuvor erstellten Konstruktionsplan und setzen das gesamte System um.

Im V-Modell endet der Prozess allerdings nicht mit der Implementierung, sondern stattdessen beginnt nun der Aufstieg auf der rechten Seite des "V" mit den Testphasen.

3.6 Phase 6: Die Komponententests

Die erste Testphase, die ansteht, sind die Komponententests. Hier zeigt sich wieder das Prinzip, dass der Detailierungsgrad von oben nach unten immer feiner wird. 

Bei den Tests läuft es jedoch genau umgekehrt ab: Man geht von fein nach grob vor. Zuerst werden die einzelnen Komponenten getestet, was als Komponententests oder auch Unit-Tests bezeichnet wird.

In einem späteren Teil dieser Tutorialreihe werden wir uns diese Testarten und ihre Bedeutung noch genauer ansehen. Hier reicht erst einmal eine grobe Übersicht, damit du verstehst, wie das Modell funktioniert. 

3.7 Phase 7: Die Integrationstests

Nach den Komponententests folgen die Integrationstests, in welchen man prüft und validiert, ob der technische Systementwurf korrekt umgesetzt wurde.

Die Phase, in der die Integrationstests stattfinden, steht im V-Modell genau gegenüber der technischen Systementwurfsphase. 

3.8 Phase 8: Die Systemtests

Danach folgen die Systemtests, die den funktionalen Systementwurf validieren. Auch diese Phase steht im Modell direkt der entsprechenden Entwurfsphase gegenüber.

3.9 Phase 9: Die Abnahmetests

Am Ende folgen die Abnahmetests, die überprüfen, ob die Software den ursprünglichen Anforderungen entspricht. Hier wird validiert, ob alles so umgesetzt wurde, wie es in der Anforderungsanalyse festgelegt war.

4. Zusammenfassung

Das ist im Wesentlichen das V-Modell. Links befindet sich die Konstruktionsseite, rechts die Testseite. Für jede Konstruktionsphase gibt es demnach auf der gegenüberliegenden Seite eine entsprechende Testphase.

Das bedeutet: die Anforderungsanalyse wird durch die Abnahmetests validiert, während der funktionale Systementwurf durch die Systemtests überprüft wird und auch jede andere Entwurfsphase steht einer passenden Testphase gegenüber, um sicherzustellen, dass das System den Anforderungen entspricht.

5. Der wichtigste Vorteil des V-Modells

Wie bereits zu Beginn erwähnt, liegt ein wichtiger Vorteil bei diesem Modell in der hohen Testabdeckung. Schon während der Anforderungsanalyse denkt man über die späteren Abnahmetests nach. Das bedeutet, dass man bereits in jeder Konstruktionsphase die entsprechenden Tests einplant und damit sicherstellt, dass die Realisierbarkeit von Anfang an im Fokus steht.

Setzt man das Ganze nicht von Beginn an auf diese Weise um, kann es leicht passieren, dass wichtige Aspekte übersehen werden. Erst während der Tests stellt man dann fest, dass etwas gar nicht so realisierbar ist wie gedacht. Aus diesem Grund ist das Vorgehen besonders nützlich. 

Inhaltsverzeichnis

1. Was wirst du in diesem Beitrag lernen?

2. Was ist das Wasserfallmodell?

Im vorherigen Beitrag haben wir bereits den Software-Lebenszyklus kennengelernt. Dabei haben wir gesehen, dass sich dieser aus den folgenden 6 Phasen zusammensetzt, die in der Softwareentwicklung stets berücksichtigt werden müssen: 

1  Anforderungsanalyse
2  Design und Entwurf
3  Implementierung
4  Testphase
5  Abnahme und Einführung
6  Wartungsphase

Das Wasserfallmodell ist ein Vorgehensmodell, das zeigt, wie man diese Phasen nacheinander durchlaufen kann. 

Um das Ganze zu veranschaulichen, werfen wir an dieser Stelle einen Blick auf die folgende Grafik. Du wirst feststellen, dass sie im Grunde fast genauso aussieht wie die Grafik aus dem letzten Beitrag, mit dem Unterschied, dass sich hier zwischen den Phasen Stufen befinden.

Das Wasserfallmodell ist ein lineares Modell, was bedeutet, dass die Phasen zeitlich aufeinanderfolgen.

Anders gesagt: Es ist nicht möglich, mehrere Phasen parallel laufen zu lassen. Beispielsweise kann die Anforderungsanalyse nicht gleichzeitig mit der Testphase stattfinden. In diesem Vorgehensmodell durchläuft man die Phasen nacheinander, weshalb es als linear bezeichnet wird.

3. Die Phasen des Wasserfallmodells

4. Die Vorteile des Wasserfallmodells

Alles läuft dabei strikt zeitlich hintereinander ab – also sequenziell, ohne dass Phasen parallel verlaufen. Das bringt einige Vorteile mit sich. Zum einen sind die Phasen klar voneinander abgegrenzt, was es ermöglicht, für jede Phase individuelle Ziele festzulegen. Durch diese klare Trennung können in jeder Phase viele Meilensteine definiert werden, wodurch der Fortschritt gut kontrollierbar ist.

Ein weiterer großer Vorteil des Wasserfallmodells ist die frühe Klarheit über die Kosten und die voraussichtliche Dauer des Projekts. Sobald alles einmal geplant ist, lassen sich diese Faktoren gut abschätzen. Da man für jede Phase klare Ziele und Meilensteine definiert, kann man von Anfang an genau berechnen, welche Kosten anfallen und wie lange jede Phase dauern wird. Durch die strukturierte und sequenzielle Vorgehensweise hat man von Beginn an also einen genauen Überblick über den Projektverlauf.

5. Die Nachteile am Wasserfallmodell

Jetzt kommen wir allerdings zum großen „Aber“, denn das Wasserfallmodell bringt auch einige Nachteile mit sich. Sehen wir uns die Kritikpunkte nun also mal genauer an.

5.1 Es gibt kein Zurück mehr

Der erste Punkt ist, dass es in der Praxis oft schwierig ist, wenn nicht sogar unmöglich, die Phasen klar voneinander abzugrenzen.

Stell dir vor, wir befinden uns nach der Implementierungsphase in der Testphase und in dieser Phase werden jetzt Fehler entdeckt, wodurch an mehreren Stellen nachgebessert werden muss. 

Eigentlich müssten wir diese Probleme beheben. Doch wenn man streng nach dem Wasserfallmodell arbeitet, ist die Implementierungsphase bereits abgeschlossen und ein Rücksprung zu einer vorherigen Phase ist laut diesem Modell nicht vorgesehen.

Das bedeutet, dass man nichts mehr programmieren dürfte, wenn man sich strikt an das Modell halten würde. Hier zeigt sich bereits, dass es kaum möglich ist, die Phasen so klar voneinander zu trennen.

In realen Softwareprojekten ist es oft notwendig, mehrere Phasen erneut zu durchlaufen, um am Ende ein gutes Ergebnis zu erzielen. Das steht jedoch im Widerspruch zum Wasserfallmodell.

5.2 Keine Flexibilität

Ein weiterer Kritikpunkt ist der Verlust der notwendigen Flexibilität. Stell dir vor, du stehst vor der Aufgabe, ein System zu programmieren und es gibt von Anfang an zwei oder drei kritische Stellen, bei denen unklar ist, ob sie so umgesetzt werden können wie geplant. 

In der Praxis beginnt man oft mit den kritischsten Aspekten eines Systems, denn wenn diese nicht funktionieren, lohnt sich die restliche Arbeit nicht. Das Wasserfallmodell steht allerdings auch im Widerspruch zu diesem Ansatz, da man streng den Phasen folgen muss. 

Ich hatte vorhin bei den Vorteilen erwähnt, dass die Kosten und die voraussichtliche Dauer des Projekts von Beginn an festgelegt werden. Das gilt jedoch nur, wenn die Anforderungen an das zu entwickelnde System während des gesamten Prozesses stabil bleiben. Das bedeutet, dass sich während der gesamten Entwicklungs- und Projektlaufzeit nichts an den Anforderungen ändert. 

Auch danach, in der Wartungsphase, sind Änderungen kaum möglich, da ein Rücksprung zu früheren Phasen im Wasserfallmodell nicht vorgesehen ist.

Wenn sich am Ende des Projekts eine Anforderung ändert – sei es durch neue Technologien, veränderte Geschäftsmodelle oder Konkurrenz durch innovative Start-ups – muss man entsprechend reagieren und das System anpassen. Dazu wären Rückschritte nötig, um neue Anforderungen zu definieren und das System entsprechend umzubauen. 

6. Warum das Wasserfallmodell kaum noch anwendbar ist

In der Praxis sind Anforderungen also nie wirklich stabil. Genau deshalb ist das Wasserfallmodell in modernen und oft komplexen Softwareprojekten kaum noch anwendbar. Dennoch ist es ein grundlegendes Modell, das man kennen sollte. In der heutigen Softwareentwicklung wird es allerdings nur noch selten eingesetzt.

Wir werden in den kommenden Beiträgen selbstverständlich noch andere Vorgehensmodelle kennenlernen, die heute weit verbreitet und sehr relevant sind. 

Inhaltsverzeichnis

1. Was ist der Software Lebenszyklus?

2. Die 6 Phasen des Software Lebenszyklus

In der folgenden Grafik sind die sechs Phasen des Software-Lebenszyklus übersichtlich dargestellt:

Im Internet findet man natürlich zahlreiche Videos, Blogartikel und Bücher zu diesem Thema, worin der Software-Lebenszyklus jeweils etwas anders dargestellt wird.

Im Grunde geht es aber immer um das Gleiche. Ob eine Quelle von sieben Phasen spricht, eine andere von acht oder wieder eine andere nur von fünf – oft sind diese Phasen einfach anders zusammengefasst.

Ich habe mich hier entschieden, den Lebenszyklus in sechs Phasen zu unterteilen.

3. Die Anforderungsanalyse

4. Die Design- oder Entwurfsphase

Als Nächstes geht es in die Design- oder Entwurfsphase. In dieser Phase plant man die gesamte Software im Detail. Hier legen wir fest, wie das Layout der Software aussehen soll und welche Programmiersprachen zum Einsatz kommen. Wird die Software beispielsweise in C# oder Java entwickelt? Sollen wir ein bestimmtes Framework verwenden, wie zum Beispiel Spring für Java?

Außerdem definieren wir den Aufbau der Businesslogik, ob und mit welchen Datenbanken wir arbeiten und wie die Softwarearchitektur insgesamt gestaltet sein soll.

Am Ende entsteht ein umfassender Entwurf, der alle wichtigen Entscheidungen enthält. Dieser Entwurf dient dann als Grundlage für die nächste Phase, in der die eigentliche Implementierung stattfindet.

In der Design- und Entwurfsphase kommen viele verschiedene Diagrammtypen zum Einsatz, die wir noch kennenlernen werden. Diese helfen uns dabei, das gesamte Softwarekonzept sauber zu planen. Sobald der Entwurf fertig ist, geben wir ihn an die nächste Phase weiter – die Implementierungsphase.

5. Die Implementierungsphase

In der Implementierungsphase beginnt dann die eigentliche Programmierarbeit. Hier wird erstmals produktiv Code geschrieben. Alles, was davor passiert ist, diente im Grunde der Planung und Vorbereitung.

Du siehst also, dass bei einem typischen Softwareprojekt ein großer Teil der Zeit in die richtige Planung investiert wird.

Es ist enorm wichtig, sich in der Planungsphase ausreichend Zeit zu nehmen. Man kann gut und gerne ein Drittel der Gesamtzeit für die Planung einrechnen, um eine solide Grundlage zu schaffen, die alle Aspekte berücksichtigt. 

Einfach drauflos zu programmieren, bringt in den meisten Fällen wenig. Wenn man nur fünf Prozent der Zeit in die Planung steckt und dann denkt: „Super, jetzt kann ich 90 Prozent der Zeit programmieren“, wird man oft am Ende feststellen, dass die Systeme nicht sinnvoll zusammenspielen oder die Software unnötig komplex geworden ist – wie in unserem Beispiel aus dem Einleitungsbeitrag.

Deshalb ist es so wichtig, die Planung gründlich und gewissenhaft durchzuführen, bevor man mit der Implementierung beginnt.

6. Die Testphase

Sobald die Implementierung abgeschlossen ist, kommt die vierte Phase: die Testphase. Diese ist von großer Bedeutung, denn man sollte nie davon ausgehen, dass alles, was programmiert wurde, fehlerfrei funktioniert.

Selbst wenn man die einzelnen Programmteile getestet hat, kann es zu Problemen kommen, sobald die verschiedenen Teile zusammengeführt werden. In einem Team arbeiten oft mehrere Entwickler, und wenn deren Arbeit vereint wird, können unerwartete Fehler auftreten, die vorher nicht sichtbar waren.

Deshalb ist es absolut notwendig, die Software vor der Übergabe an den Kunden gründlich zu testen – und zwar immer wieder.

Stell dir nun mal vor, wir würden die Workshop-Management-Software ohne gründliche Tests an den Kunden ausliefern. Tausende von Menschen melden sich zu den Workshops an, aber im Hintergrund gibt es einen unentdeckten Fehler, der beispielsweise die Anzahl der Anmeldungen nicht korrekt mitzählt.

Das Ergebnis? Am Tag des Workshops stehen plötzlich 200 Teilnehmer vor dem Seminarraum, allerdings gibt es nur Platz für 20.

Das wäre natürlich eine Katastrophe, die sich jedoch leicht verhindern lässt, indem man die Software gründlich testet und sicherstellt, dass sie wie geplant funktioniert.

So vermeidet man im Nachhinein zusätzliche Kosten, etwa durch Entschädigungen für Teilnehmer, die umsonst angereist sind. Darüber hinaus könnte das Unternehmen durch solche Fehler an Ansehen verlieren und für große Unzufriedenheit bei den Kunden sorgen. All das lässt sich durch eine sorgfältige Testphase vermeiden.

7. Die Abnahme und Einführung

Nach Abschluss der Testphase folgt die nächste wichtige Phase: die Abnahme und Einführung. Bei der Abnahme geht es darum, dass der Kunde das entwickelte Softwaresystem überprüft und offiziell freigibt. 

In dieser Phase wird die Software auf das Zielsystem übertragen, installiert und in den Betrieb eingeführt. Dieser Prozess der Verteilung und Installation wird oft als „Rollout“ oder „Deployment“ bezeichnet.

Der Kunde prüft anschließend, ob alles wie erwartet funktioniert und wenn er zufrieden ist, wird die Software offiziell in Betrieb genommen und im Alltag genutzt.

8. Die Wartungsphase

Zum Schluss gelangt die Software in die letzte Phase des Lebenszyklus: die Wartungsphase. In dieser Phase wird die Software kontinuierlich gepflegt und weiterentwickelt, wobei verschiedene Gründe dafür eine Rolle spielen können.

Es kann zum Beispiel sein, dass Bugs erst im laufenden Betrieb entdeckt werden, die der Kunde meldet. Diese müssen wir natürlich beheben. Ein anderer Grund könnte sein, dass das Unternehmen, das die Workshops anbietet, stark wächst und der Traffic auf die Anwendung deutlich zunimmt.

Falls die Software ursprünglich nur für eine bestimmte Anzahl an Nutzern ausgelegt war, könnten Performance-Probleme auftreten, weil die Server überlastet sind. In diesem Fall müssten wir die Software nachträglich optimieren und anpassen, damit sie auch mit dem höheren Traffic reibungslos funktionieren kann.

All diese Dinge erledigt man in der Wartung.

9. Fazit

Das war nun ein grober Überblick über den Software Lebenszyklus. In den kommenden Beiträgen werden wir darauf aufbauen und uns verschiedene Vorgehensmodelle ansehen. Du kannst dir sicher vorstellen, dass es verschiedene Ansätze gibt, um diese Phasen in der Entwicklung zu durchlaufen.

Was meine ich damit? Ein klassischer Ansatz der Softwareentwicklung wäre, alle Phasen von 1 bis 6 der Reihe nach abzuarbeiten. Allerdings gibt es auch andere Ansätze.

Ein Beispiel für einen alternativen Ansatz besteht darin, im ersten Schritt nur das Nötigste zu entwickeln, also ein MVP (Minimal Viable Product). Dieses MVP enthält nur die grundlegendsten Funktionen, um zu testen, ob die Software so funktioniert, wie wir es uns vorstellen, und um dem Kunden eine erste Version zu präsentieren. So kann der Kunde entscheiden, ob er die Software in dieser Form überhaupt benötigt.

Anschließend kann man aus dem Feedback des Kunden lernen und nach und nach weitere Funktionen ergänzen. Dieser iterative Prozess wiederholt sich immer wieder, um die Software stetig zu verbessern.

Es gibt verschiedene Vorgehensmodelle, die diesen Ansatz unterstützen und genau darauf werden wir in den folgenden Beiträgen noch einen genaueren Blick werfen.

Inhaltsverzeichnis

1. Warum ist das Thema Software Engineering so wichtig?

2. Was wirst du in diesem Beitrag lernen?

Zunächst werden wir die grundlegende Frage beantworten, was Software Engineering eigentlich ist. Dabei werde ich den Begriff ausführlich erklären, damit du eine klare Vorstellung davon erhältst.

Im Anschluss sehen wir uns die Ziele an, die wir mit Software Engineering verfolgen  und warum sie in der Praxis so wichtig sind.

Anhand eines Beispiels werde ich dir dann aufzeigen, wie Fehler im Software Engineering zu erheblichen Problemen und Schäden führen können.

Abschließend gebe ich dir einen Ausblick auf die Inhalte des gesamten Crashkurses, damit du entscheiden kannst, ob dieses Thema für dich interessant ist.

Lass uns also direkt mit der ersten Frage starten:

3. Was ist Software Engineering?

4. Die Ziele von Software Engineering

Ein zentrales Ziel des Software Engineering ist die Erstellung von Qualitätssoftware. Doch was bedeutet Qualität in diesem Kontext? Qualität umfasst verschiedene Aspekte, wie beispielsweise die Frage, ob die Software die von den Nutzern erwarteten Funktionen erfüllt. Hier spielt auch die Wirtschaftlichkeit eine Rolle: Wenn die Software die gewünschten Funktionen nicht bereitstellt, wird ein Nutzer sie wahrscheinlich nicht lange verwenden.

Wird der Zweck nicht erfüllt, so macht die Nutzung keinen Sinn und das Projekt ist damit unwirtschaftlich.

Zusätzlich sind weitere Kriterien wichtig: Ist die Software zuverlässig? Funktioniert sie effizient? Ist sie benutzerfreundlich? Lässt sie sich gut warten und pflegen, auch nach der Entwicklungsphase? All diese Punkte sind entscheidend für die Qualität einer Software. Das Ziel des Software Engineering ist es daher, Software von höchster Qualität zu entwickeln.

Ein weiteres Ziel des Software Engineering ist es, Fehler zu vermeiden. Das bedeutet allerdings nicht, dass man Fehler völlig ausschließen sollte. Im Gegenteil: Aus Fehlern lernt man und sie können wertvolle Erkenntnisse liefern. 

Wichtig ist, Fehler nicht ständig zu wiederholen. Wenn man bereits weiß, dass etwas nicht funktioniert, ist es ineffizient, diese Erfahrung erneut zu machen. Stattdessen sollte man auch aus den Fehlern anderer lernen, um sie selbst zu vermeiden.

Software Engineering unterstützt diesen Lernprozess effektiv.

4.3 Aufwände minimieren

Darüber hinaus zielt es darauf ab, Aufwände zu minimieren. Das steht in engem Zusammenhang mit der Vermeidung von Fehlern.

4.4 Den Kundennutzen maximieren

Ein anderes wichtiges Ziel des Software Engineering ist es, den Kundennutzen zu maximieren. Dabei wird deutlich, wie wichtig es ist, den Kunden stets im Fokus zu behalten und zu überlegen: „Was möchte der Kunde oder die Kundin überhaupt?“

Es spielt keine Rolle, ob der Kunde ein Unternehmen ist, das dich beauftragt hat, eine Software zu entwickeln, eine Nutzerin einer Webanwendung, die du erstellt hast, oder ein Spieler eines Spiels, das du programmiert hast – all diese Personen fallen unter den Begriff „Kunden“.

5. Mehr als nur Programmieren

Die Vielzahl der Ziele, die im Software Engineering verfolgt werden, deutet schon darauf hin, dass dieses Feld ziemlich umfangreich ist. Bei der Erstellung von Software geht es nicht nur um das Programmieren, was viele fälschlicherweise annehmen.

Programmieren ist lediglich ein Teil des gesamten Prozesses.

Es gibt viele Aspekte, die man beim Software Engineering berücksichtigen muss und ein wesentlicher Teil davon ist das Projektmanagement. Dabei ist es entscheidend, einen klaren Plan zu haben, der festlegt, wer der Kunde ist, was wann programmiert wird und wer in einem Team für welche Aufgaben verantwortlich ist. 

Besonders im Spielebereich sollte man auch die Zielgruppe genau definieren und psychologische Aspekte berücksichtigen, um sicherzustellen, dass das Spiel langfristig gespielt wird.

Ein strukturierter Plan ist unerlässlich, ebenso wie kontinuierliche Tests, um zu überprüfen, ob die bisherigen Entwicklungen funktionieren. Sobald die Software in Betrieb genommen wird, ist es wichtig, sie zu übergeben, wenn sie für einen Kunden entwickelt wurde und sie anschließend regelmäßig zu warten.

Zusammenfassend lässt sich also sagen, dass Software Engineering von enormer Bedeutung ist und ein umfangreiches Feld darstellt.

6. Warum Software Engineering auch für Anfänger wertvoll ist

Unser Ziel ist es, dir mit diesem Crashkurs einen umfassenden Überblick über das Thema zu geben und dir zu zeigen, wie man diese Konzepte in der täglichen Praxis der Softwareentwicklung anwendet.

Egal, ob es sich um große oder kleine Projekte handelt, Software Engineering ist grundsätzlich für alle Entwicklungsprozesse entscheidend. Besonders wichtig ist es, zu verstehen, dass diese Prinzipien nicht nur für erfahrene Entwickler relevant sind. 

Selbst wenn du gerade erst in die Programmierung eingestiegen bist und das Gefühl hast, dass große Projekte noch in weiter Ferne liegen, möchte ich dir ans Herz legen, diese Serie durchzulesen. Sie vermittelt grundlegende Konzepte und Strukturen, die du von Anfang an richtig umsetzen kannst.

Auf diese Weise vermeidest du die Situation, in der du monatelang an etwas arbeitest, nur um später festzustellen, dass das Projekt nicht funktioniert. Genau dafür ist Software Engineering da – um dir dabei zu helfen, Projekte von Anfang an auf den richtigen Weg zu bringen.

7. Negativbeispiel aus der Praxis: Ein Fehler kostete 60 Millionen Euro

Um noch einmal zu verdeutlichen, warum dieses Thema so wichtig ist, möchte ich einen Bericht von Heise.de heranziehen. Dieser stammt zwar vom 16. Februar 2017, ist aber immer noch sehr relevant. Die Schlagzeile lautete damals: „60 Millionen Euro versenkt: Bundesagentur für Arbeit stoppt IT-Projekt ROBASO“.

In dem Artikel wird beschrieben, wie die Bundesagentur für Arbeit 14 verschiedene interne Anwendungen nutzt, damit ihre Mitarbeiter ihre täglichen Aufgaben erledigen können. Das Ziel war es, eine zentrale Softwareplattform zu entwickeln, auf der alle diese Anwendungen zusammengeführt werden, um einen einheitlichen Zugangspunkt für die Mitarbeiter zu schaffen.

Die Idee klang zunächst logisch: Man hatte einen klaren Zweck definiert und wollte eine Software entwickeln, die all diese Anforderungen erfüllt. So startete das Projekt, wenn ich mich richtig erinnere, im Jahr 2010. Über mehrere Jahre hinweg wurde daran gearbeitet, und die Software wuchs zu einem extrem komplexen System heran. Nach einigen Jahren führte man dann einen Pilottest durch – und das Ergebnis war ernüchternd: Die Software erwies sich als viel zu unflexibel für den täglichen Einsatz.

7.1 Der Grund für den Fehler

Doch was bedeutet, dass die Software „unflexibel“ war? Im Bericht gab es ein Beispiel: Wollte man etwa die Kontonummer eines Kunden ändern, war dies zwar technisch möglich, aber die Mitarbeiter mussten anschließend zahlreiche weitere Daten manuell eingeben, obwohl nur eine kleine Änderung notwendig war.

Die Software war derart komplex, dass am Ende kaum jemand damit arbeiten konnte.

Letztlich stellte man fest, dass das gesamte Projekt gescheitert war – und das zu einem Preis von 60 Millionen Euro, die somit verloren waren.

Ein Blick in den Artikel zeigt eine entscheidende Stelle, in der es heißt: „Erst bei der Pilotierung im Februar 2016 wurde festgestellt, dass es kein standardisiertes Systemgeschäft gibt und die komplexen und vielfältigen Fallgruppen der Kundenanliegen einer sehr differenzierten Arbeitspraxis bedürfen.“

Man stellte also fest, dass das Vorhaben nicht so umsetzbar war, wie ursprünglich gedacht. Obwohl man in diesem Projekt Methoden des Software Engineering angewandt hatte, wurde in einer entscheidenden Phase ein Fehler gemacht.  

Man hat nicht ausreichend analysiert, ob das Konzept überhaupt realisierbar ist. Stattdessen investierte man weiter, zahlte Entwickler, Projektmanager und steckte immer mehr Geld in die Entwicklung – nur um am Ende festzustellen, dass das gesamte Budget von 60 Millionen Euro verschwendet worden war und kein brauchbares Ergebnis dabei herauskam.

8. Warum Softwareprojekte scheitern

Warum zeige ich dir dieses Beispiel? Ich möchte dir damit verdeutlichen, wie viel auf dem Spiel steht, insbesondere bei Entwicklungsprojekten dieser Größenordnung. 60 Millionen Euro klingen nach einer unglaublichen Summe – und genau das soll dir zeigen, wie gravierend Fehler im Prozess sein können. Schon kleine Versäumnisse können dazu führen, dass ein ganzes Projekt scheitert.

Interessanterweise scheitern die meisten Softwareprojekte nicht an technischen Problemen, sondern an Aspekten wie schlechtem Projektmanagement oder einer unzureichenden Auseinandersetzung mit der Zielgruppe. Dadurch wird etwas entwickelt, das am eigentlichen Bedarf vorbeigeht.

Solche Probleme treten häufiger auf, als dass technische Aspekte nicht realisierbar sind. Auch wenn Großprojekte für dich als Programmieranfänger vielleicht noch weit entfernt erscheinen, möchte ich dir damit zeigen, was passieren kann, wenn man sich nicht an grundlegende Prinzipien hält oder kleine Fehler im Prozess macht.

9. Wann Software Engineering für kleine Entwickler sinnvoll ist

Das gilt auch für kleine Entwickler. Wenn du beispielsweise nur ein Skript schreibst, das Dateinamen umbenennt, brauchst du dafür natürlich keine große Planung – das kannst du einfach und schnell umsetzen. Genauso bei kleinen Anwendungen: In manchen Fällen kannst du ohne großen Plan direkt starten.

Sobald ein Projekt allerdings etwas größer wird, wirst du rasch merken, dass es nicht sinnvoll ist, sich einfach hinzusetzen und beispielsweise in Java mit Eclipse oder IntelliJ, ohne Plan Klassen zu erstellen und drauflos zu programmieren. 

Du wirst feststellen, dass dir nach ein paar Stunden immer wieder neue Dinge einfallen, die du noch berücksichtigen musst. Deshalb ist es wichtig, sich im Vorfeld wirklich Gedanken zu machen.

Software Engineering bietet hier ein strukturiertes Vorgehen, das dir Schritt für Schritt zeigt, wie du dein Projekt mit bewährten Methoden („Best Practices“) umsetzen kannst. 

Deshalb ist es auch für dich als Programmiereinsteiger wichtig, diese Tutorialreihe zu lesen oder im Videoformat anzusehen. Du wirst dabei viele wertvolle Dinge lernen, die dir in deiner weiteren Entwicklung enorm helfen werden. Selbst wenn du bereits etwas Programmiererfahrung hast, aber bisher noch nicht mit Software Engineering in Berührung gekommen bist, lege ich dir diese Serie ans Herz.

Wir haben uns nun ein Beispiel angesehen, das verdeutlicht, welche Folgen kleine Fehler in einem Projekt haben können – auch in finanzieller Hinsicht.

Zum Abschluss möchte ich dir noch einen Ausblick darauf geben, was dich im weiteren Verlauf dieses Crashkurses erwartet.

10. Was wirst du in diesem Crashkurs noch lernen?

Wir werden uns unter anderem verschiedene Vorgehensmodelle ansehen. Diese Modelle zeigen unterschiedliche Ansätze, wie wir von A bis Z eine Software entwickeln können. Es gibt davon zahlreiche Varianten.

Zum Beispiel das Wasserfallmodell oder agile Methoden wie Scrum. Dabei werden wir einige dieser Vorgehensmodelle kennenlernen, damit du mit ihnen vertraut wirst und ein grundlegendes Verständnis dafür entwickelst.

Als Nächstes werden wir uns mit Diagrammen befassen, die dazu dienen, Software zu beschreiben. Wenn du einen Plan für die Entwicklung erstellst, musst du klar kommunizieren, was du bauen möchtest. Besonders in einem Team ist es wichtig, dass jeder den Plan versteht.

Es gibt eine Vielzahl von Diagrammen, die du nutzen kannst, um anderen zu verdeutlichen, was du programmieren möchtest. Wir werden verschiedene Diagramme betrachten, die jeweils für unterschiedliche Einsatzzwecke geeignet sind.

Anschließend werden wir uns mit der Implementierung beschäftigen. Ich werde dir einige Kniffe und Prinzipien vorstellen, wie du deine Programme so designen kannst, dass der Code sauber und wartbar bleibt.

Außerdem werden wir verschiedene Testarten kennenlernen, uns mit der Abnahme und Inbetriebnahme auseinandersetzen und auch über die Wartung von Software sprechen. Dabei werden wir die Gründe erörtern, warum Software regelmäßig gewartet werden muss.

Das ist natürlich nur ein kleiner Ausblick auf das, was auf dich zukommen wird. Es gibt noch viele weitere Themen, die auf uns warten.

Inhaltsverzeichnis

1. Der Head-Pointer

Wenn wir auf den ersten Commit zurückgehen, bewegt sich der Head-Pointer auch mit auf diesen Commit. Wir arbeiten dann also mit diesem.

Wichtig: Man kann nicht nur auf Commits zeigen, sondern auch auf Branches, wie wir hier sehen.

Der Head-Pointer zeigt auf den Main-Branch. Fügen wir an dieser Stelle einen Commit hinzu, bewegt sich der Main-Branch nach vorne. Wie das aussieht, werde ich dir gleich noch grafisch zeigen. Der Head-Pointer fährt also mit dem Main-Branch mit.

2. Der Befehl git checkout

Wir selektieren also diesen Wert, machen einen Rechtsklick und klicken dann auf „copy“. Anschließend schreiben wir „git checkout“ und fügen dahinter mit einem Rechtsklick und „paste“ den Hash-Wert ein. Drücken wir jetzt auf Enter, dann bewegen wir den Head-Pointer auf genau diesen Commit.

3. Die Warnung: "You are in detached HEAD state"

Jetzt ist erst mal etwas Beunruhigendes passiert: Wir haben die Warnung „You are in detached HEAD state“ erhalten. Was im ersten Moment dramatisch klingt, ist letztendlich aber nichts, worüber wir uns große Sorgen machen müssen. Wir befinden uns immer dann im „detached HEAD state“, wenn wir mit unserem Head-Pointer nicht auf einen Branch zeigen, sondern auf einen einzelnen Commit.

Was es damit auf sich hat, werde ich dir in der folgenden Grafik zeigen. Du hast eben bereits gelernt, dass der Head-Pointer wie ein Zeiger funktioniert, der immer auf den aktuell ausgewählten Branch oder Commit zeigt. Im Beispiel ist genau das zu erkennen.

Wir haben einen Main Branch, wobei es sich um ein kleines Projekt handelt und darüber hinaus bereits drei Commits. Das sind Commit A, B und C. Jetzt können wir zu diesem Branch noch einen weiteren Commit hinzufügen. Wenn der Head-Pointer auch auf den Branch Main zeigt, passiert dann Folgendes:

Der neue Commit wird erstellt und der Branch, auf den wir gerade zeigen, bewegt sich ein Stück nach vorne. Somit liegt der neue Commit hinter dem Branch.

4. Einen neuen Branch erstellen

Wir können natürlich auch noch einen weiteren Branch erstellen, in welchem wir ein neues Feature entwickeln. Durch die Entwicklung in einem eigenen Branch stellen wir sicher, dass der Prozess keine Auswirkungen auf unseren Main Branch hat.

Anschließend können wir auch dort wieder einen Commit anlegen. Weil der Head-Pointer bereits auf unseren Branch Feature gezeigt hat, wurde der Commit zu diesem hinzugefügt. Das heißt: Der Commit wurde vor dem Branch Feature erstellt, welcher sich wiederum ein Stück nach vorne bewegt hat.

Wie du siehst, bewegt sich der Branch, auf den der Head-Pointer zeigt, bei jedem Commit ein Stück nach vorne. Der Commit gehört dann zu diesem Entwicklungszweig (Branch).

Man kann mit dem Head-Pointer allerdings nicht nur auf Branches zeigen, sondern auch auf einzelne Commits. Damit haben wir zum Beispiel die Möglichkeit, auf den Commit C zu zeigen. Das lässt sich umsetzen, indem wir Git Checkout und den Hash-Wert dieses Commits aufrufen.

5. Detached HEAD state: Was passiert hier?

Wenn wir mit dem Head-Pointer nicht auf einen Branch, sondern stattdessen auf einen einzelnen Commit zeigen, befinden wir uns im detached Head State.

Wichtig: Dadurch wird die zu Beginn erwähnte Warnung hervorgerufen.

Denn: Beim Zeigen auf einen einzelnen Commit besteht noch immer die Möglichkeit, weitere Commits zu erstellen. Diese weiteren Commits sind dann „kopflos“ und damit nicht Teil eines bestimmten Branches. Würden wir also auf dem Commit C einen weiteren Commit setzen, sähe das Ganze folgendermaßen aus:

6. Warum der detached HEAD state problematisch sein kann

Dann gäbe es den neuen Commit F, welcher zu keinem Branch gehört. Das bedeutet: Wenn wir nun bei einem beliebigen anderen Branch arbeiten und wieder zurück zu Commit F möchten, wird es schwierig, diesen zu finden. Schließlich sind die Branches nicht lediglich dazu da, Entwicklungszweige zu erstellen, sondern dienen ebenso als Orientierungspunkte.

Wenn wir also Commits erstellen, die zu keinem Branch gehören, wird das Ganze etwas chaotisch. Aus diesem Grund erhalten wir den Hinweis, dass der HEAD gerade detached, also frei stehend ist, was immer dann passiert, wenn wir mit dem Head-Pointer auf einen einzelnen Commit zeigen, anstatt auf einen Branch.

So viel zum Thema Head-Pointer.

7. Den Projektstatus in der Git Bash nachvollziehen

Zurück in der Git Bash sehen wir noch immer die Nachricht, dass wir uns im Detached Head Space befinden, da wir zum ersten Commit gewechselt sind.

Wenn wir jetzt noch einmal „git log“ eingeben, sehen wir den Log bis zu dem Zeitpunkt in unserem Projekt, an dem wir uns gerade befinden.

Darin wird nur der Commit angezeigt, auf den der HEAD zeigt. Außerdem sehen wir, dass dort nicht wieder „HEAD“ mit einem Pfeil auf einen Branch-Namen steht, sondern lediglich „HEAD“. Er zeigt also nur auf den Commit.

8. Mit git checkout zurück zum Main Branch steuern

An dieser Stelle werden wir uns nun wieder zurück zum aktuellen Stand unseres Projekts bewegen, nämlich zum Main Branch. Dazu schreiben wir zunächst einmal „git checkout“. Da wir jetzt aber nicht zu einem Commit springen möchten, sondern zum Main Branch, benötigen wir keinen Hash-Wert. Stattdessen genügt der Name des Branches, zu dem wir möchten. Wir geben also „git checkout main“ ein:

Daraufhin befinden wir uns auch schon wieder an diesem Punkt. Wenn wir nun „git log“ in die Konsole eingeben, sehen wir beide Commits und darüber hinaus, dass der Head auf den Branch Main zeigt:

An dieser Stelle möchte ich dir zeigen, dass es einen Unterschied macht, wo wir uns im Projekt mit dem Head-Pointer befinden. Werfen wir einen genaueren Blick auf unseren Projektordner, sehen wir die Datei index.html. Öffnen wir diese, steht darin der Satz „Das hier ist meine eigene Website“. Wir sind gerade auf dem aktuellen Commit, also auf unserem Main Branch.

Springen wir nun allerdings nochmal zurück zu unserem ersten Commit, indem wir „git checkout“ und dessen Hash-Wert eingeben, dann befinden wir uns mit dem Head-Pointer wieder auf der ersten Version unseres Projekts. Beim erneuten Laden der Website taucht auch der Rechtschreibfehler der ersten Version wieder auf.

Der Ort, an dem wir uns befinden, macht also tatsächlich einen Unterschied.

Wie du siehst, können wir mithilfe von git checkout den Stand unseres Projekts wieder zu einer alten Version zurücksetzen lassen, zur aktuellen Version springen, in einen anderen Branch wechseln, usw.

Du hast in diesem Beitrag also gelernt, wie man den git checkout Befehl verwendet und welche Rolle der Head-Pointer dabei spielt.

Inhaltsverzeichnis

1. Das Website-Projekt vorbereiten

Beim Öffnen dieser Datei sehen wir den Satz „Das hier ist meine eigne Website“. Den Rechtschreibfehler im Wort „eigene“ habe ich bewusst eingebaut.

Den Grund hierfür wirst du später noch erfahren. In diesem Beitrag werden wir herausfinden, wie wir die Vorteile einer Versionsverwaltung wie Git für unser Projekt nutzen können. Wir möchten nun aus unserem Projektordner „Website“ ein sogenanntes Git Repository, also ein Git Projekt machen. Anschließend werden wir auch schon den ersten Commit an unserem Projekt vornehmen.

2. Was ist ein Git Commit?

Es gibt nun einen einfachen Befehl, mit welchem wir ein Repository erstellen können. Dieser lautet „git init“.

3. Der Befehl git init

Zuerst müssen wir uns mit der Git Bash in den Ordner bewegen, in dem wir git init ausführen möchten. Also in den Ordner, aus welchem wir ein Repository kreieren werden.

Wir navigieren also in den Desktopordner und von dort aus in den Websiteordner. Aktuell befinden wir uns im User Ordner. Doch wie gelangen wir jetzt in den Desktopordner? Ganz einfach, indem wir „cd Desktop“ schreiben:

Wie wir sehen, befinden wir uns nun auf dem Desktop. Um anschließend in den Websiteordner zu gelangen, geben wir „cd Website“ ein:

An dieser Stelle werden wir aus dem Websiteordner ein Git Repository machen. Wie bereits erwähnt, nutzt man dafür den Befehl git init. Damit initialisieren wir ein Git Repository in diesem Ordner. Nachdem wir den Befehl bestätigt haben, sehen wir die Meldung „initialized empty git repository“:

Jetzt prüfen wir erst mal, ob das auch tatsächlich ein Git Repository ist. Dazu schreiben wir „git status“. Mit diesem Befehl können wir den aktuellen Status des Repositorys abfragen:

Damit haben wir erfolgreich ein Repository erstellt! Dieses besitzt aktuell zwar noch keine Commits, dafür aber „untracked files“. Das sind Dateien, die wir in unserem Repository noch nicht verwalten. Auf dieses Thema kommen wir gleich noch zurück.

Falls bei dir nun stehen sollte „fatal: not a git repository“, wie auf dem folgenden Bild zu sehen, ist bei dir etwas schiefgelaufen:

Stelle also sicher, dass du tatsächlich in den Ordner gegangen bist, aus welchem du ein Repository erstellen wolltest und du dort den Befehl git init ausgeführt hast.

Wenn wir jetzt in unseren Ordner hineinschauen, sehen wir einen versteckten Ordner, der mit dem git init Befehl erstellt wurde. Dabei handelt es sich um den .git-Ordner. Diesen sehen wir nur dann, wenn wir in unserem Betriebssystem eingestellt haben, dass versteckte Ordner angezeigt werden.

Der versteckte Ordner enthält alle Informationen über unser darin angelegtes Git Repository. 

Wir werden uns mit diesem Ordner allerdings nicht großartig auseinandersetzen. Ich wollte dir lediglich zeigen, dass dieser existiert. Das ist also unser Git Repository.

Jetzt werden wir zu unserem Website-Ordner die Datei Todo-List hinzufügen. Dazu erstellen wir ein neues Textdokument und nennen dieses „Todo-List“. Das machen wir, um zu sehen, dass Git diese neue Todo-List-Datei auch erkennt, wenn wir noch einmal „status“ schreiben.

Navigieren wir nun also noch einmal in Git hinein und schreiben in unserem Projektordner ein weiteres Mal „git status“.

In der folgenden Abbildung sehen wir, dass wir bisher noch keinen Commit in unserem Git Repository erstellt haben. Dafür haben wir die beiden Dateien, die noch unter „untracked files“ gelistet sind.

Untracked files sind die Dateien, die unser Git Repository noch nicht verwaltet. Nun möchten wir diese beiden Dateien zum sogenannten „Staging Area“ hinzufügen, in welchem wir uns dann sozusagen unseren Commit zusammenbauen, also die erste Version unseres Git Repositorys.

4. Das Staging Area

Das Staging Area ist im Grunde einfach nur ein Zwischenschritt, in den wir unsere Dateien schreiben, die wir im nächsten Commit „committen“ möchten. Also aus welchen wir die nächste Version erstellen werden.

Um eine Datei zum Staging Area hinzuzufügen, schreibt man „git add“ und anschließend den Dateinamen. In unserem Beispiel können wir entweder den Dateinamen „Todo-List.txt“ oder lediglich „git add“ und einen Punkt (git add .) schreiben.

Wenn wir anschließend noch einmal „git status“ eingeben, sehen wir, dass nun alle „untracked“ Dateien in unserem Repository im Staging Area hinzugefügt sind:

Damit haben wir die beiden Dateien zu unserem Staging Area hinzugefügt. Nochmal zur Wiederholung: Das Staging Area ist ein Zwischenbereich, in den wir alle Dateien für den nächsten Commit schreiben.

Wir können uns im Staging Area unseren nächsten Commit also zusammenbauen und das ist ziemlich hilfreich. Wenn wir nämlich beispielsweise sehr viel an unserem Projekt gearbeitet haben, ohne dabei viele kleine Commits anzulegen, können wir im Staging Area trotzdem diese Änderungen Schritt für Schritt in kleine Commits aufteilen und erstellen. So sparen wir uns einen besonders großen Commit. Das ist an dieser Stelle auch ein wichtiger Tipp: 

Wenn man mit Git arbeitet, sollte man so kleine Commits wie möglich erstellen.

Die Commits sollten immer nur eine kleine logische Änderung beinhalten und nicht auf einen Schlag das ganze Projekt verändern. Wenn es dann nämlich zu Konflikten kommt, wird es ziemlich schwer, diese zu lösen.

Und dabei hilft uns das Staging Area immens. In das Staging Area können wir also mit „git add“ all die Dateien legen, die im nächsten Commit sein sollen.

5. Einen Git Commit erstellen

Die Dateien befinden sich also im Staging Area und nun möchten wir daraus einen Git Commit erstellen. Das bedeutet: Eine neue Version unseres Projekts. Wie machen wir das? Wir schreiben dazu den Befehl „git commit -m“ und darauffolgend zwischen Anführungszeichen (““) eine Commit Message. Generell ist es empfehlenswert, bei jedem Commit mit „-m“ eine Nachricht anzufügen. So weiß man immer, welche Änderung man dort vorgenommen hat.

Da es sich hierbei um unseren ersten Commit handelt, schreiben wir einfach mal die Nachricht „Erste Version von unserem Website Projekt“ dazu und bestätigen das Ganze mit Enter.

Damit haben wir unseren ersten Commit erstellt! Wenn wir jetzt „git status“ eingeben, sehen wir, dass wir uns gerade im Branch main befinden und es aktuell nichts weiter zu "committen" gibt. Das liegt daran, dass wir keine weitere Änderung an den getrackten Dateien unseres Projekts vorgenommen haben.

Übrigens können wir uns auch die Commit History unseres Projekts ansehen, indem wir „git log“ in die Kommandozeile eingeben. Wie wir auf der folgenden Abbildung sehen, existiert bisher nur der Git Commit, den wir gerade erstellt haben. Wir sehen dort einmal den Autor, also den Namen der Person, die den Commit erstellt hat. In diesem Fall ist das mein Name. Außerdem sehen wir die E-Mail-Adresse des Autors und den Zeitpunkt der Erstellung. Darunter steht die Commit-Message, die wir mit „-m“ angefügt haben. Das Anfügen solcher Messages ist also ziemlich sinnvoll.

Jetzt werden wir uns ansehen, was passiert, wenn wir eine Änderung an einer Datei vornehmen. Hierfür steuern wir noch einmal in unseren Website Ordner und öffnen die index.html-Datei mit notepad++.

Wie vorhin bereits erwähnt, hat sich ein Rechtschreibfehler auf unserer Website eingeschlichen. Diesen werden wir jetzt korrigieren.

Es handelt sich also nicht um die „eigne“ Website, sondern um die „eigene“ Website.

Anschließend speichern wir das Ganze ab und gehen zurück in unsere Git Bash. In der Git Bash schreiben wir nun noch mal „git status“.

Wie auf dem folgenden Bild zu erkennen ist, existiert eine neue Datei:

Die „bak“-Datei hat Notepad erstellt und ist für uns im Augenblick nicht relevant. Außerdem gibt es noch eine „modified“-Datei. Dabei handelt es sich um die index.html-Datei, die uns interessiert und die bearbeitet wurde.

Wir können jetzt die bearbeitete Datei wieder mit „git add“ zum Staging Area hinzufügen, indem wir „git add index.html“ schreiben. Um zu überprüfen, ob der Vorgang funktioniert hat, geben wir „git status“ ein. Wie wir auf der folgenden Abbildung erkennen können, befindet sich die Datei nun im Staging Area.

Jetzt werden wir einen Commit erstellen, da die neue Version den Rechtschreibfehler behoben haben soll. Wir schreiben also noch einmal „git commit -m“ und fügen hier die Bezeichnung „Korrektur von Rechtschreibfehler“ an.

Dann bestätigen wir das Ganze und der Commit ist damit erstellt. Wenn wir anschließend erneut „git log“ eingeben, können wir bereits zwei Commits erkennen.

Das ist zum einen der aktuelle Commit, in welchem wir die Korrektur des Rechtschreibfehlers vorgenommen haben und zum anderen ist das die alte Version, die wir als „Erste Version von unserem Website Projekt“ vermerkt haben.

Übrigens ist es auch möglich, zwischen Versionen hin und her zu wechseln. Das werde ich dir aber erst im nächsten Beitrag zeigen.

Im Prinzip können wir die Commit-History wie eine Art Zeitmaschine für unser Projekt verwenden und immer wieder zu einer alten Version zurückkehren. Ziemlich praktisch!

Inhaltsverzeichnis

1. Was wirst du in diesem Beitrag lernen?

2. Die Git Bash Kommandozeile

Wir starten mit den Grundlagen der Kommandozeile. Falls bei dir der Text noch ziemlich klein dargestellt sein sollte, kannst du diesen in der Git Bash durch Hinein- und Herauszoomen vergrößern oder verkleinern. Dafür hält man die STRG-Taste gedrückt und scrollt mit dem Mausrad.

Bevor wir nun mit dem ersten Befehl beginnen, möchte ich darauf eingehen, was auf der folgenden Abbildung zu lesen ist:

Auf dem Bild sehen wir „Sorm@JanekDesktop MINGW64 ~“. Beginnen wir mit dem grünen Text. „Sorm“ ist der Windows Benutzername. Das ist der Windows Benutzer, mit dem ich aktuell eingeloggt bin. Dann folgt das @-Zeichen und der Name meines Computersystems. Mein Computer heißt „JanekDesktop“ und ich bin eingeloggt mit dem Benutzer „Sorm“.

Danach steht „MINGW64“ auf dem Bildschirm. Dabei handelt es sich um die Kommandozeile, die wir verwenden. Also um eine MINGW64-Kommandozeile. Anschließend folgt eine Tilde (~). Die Tilde symbolisiert, dass wir uns gerade im Benutzerverzeichnis befinden. Das kann ich dir auch direkt anhand des ersten Befehls veranschaulichen. Und zwar ist das der pwd-Befehl.

3. Der pwd-Befehl

Wie du siehst, ist das mein Benutzerordner. Die Tilde ist also einfach eine Abkürzung für den Benutzerordner. Der Befehl „pwd“ steht für „print working directory“, was so viel bedeutet wie „gebe das aktuelle Arbeitsverzeichnis aus“. Und das ist das Verzeichnis, in welchem wir uns gerade befinden.

Als Nächstes möchte ich dir zeigen, wie du in verschiedene Ordner hinein navigieren kannst. Natürlich kannst du dein aktuelles Arbeitsverzeichnis auch jederzeit wechseln und genau das macht man mit dem cd-Befehl.

4. Der cd-Befehl

Wenn ich nun allerdings „cd /c/users/Sorm/Desktop“ schreibe, lande ich auf meinem Desktop, wie man in der folgenden Abbildung erkennen kann:

Auf dem Bildschirm steht bereits "Benutzerverzeichnis Desktop". Wenn ich jetzt den pwd-Befehl eingebe, sehen wir, dass ich mich gerade auf dem Desktop befinde:

Möchte ich nun in der Ordnerstruktur wieder eine Ebene nach oben gehen, also vom Desktopordner zurück in den übergeordneten Sorm-Ordner, dann schreibe ich dafür „cd“ und bestätige die Eingabe mit Enter. Dadurch bewege ich mich wieder in das übergeordnete Verzeichnis, also in den Benutzerordner:

Jetzt steuere ich mal in einen Beispielordner, den ich für diese Lektion erstellt habe. Dieser befindet sich auf meinem Desktop und darin zeige ich dir noch einen weiteren Befehl. Da er auf dem Desktop liegt und "Beispielordner" heißt, schreibe ich: „cd Desktop“.

An dieser Stelle kann ich einfach Desktop schreiben, weil ich aktuell im User Verzeichnis bin und Desktop ein Ordner ist, welcher sich im User Verzeichnis befindet. Das heißt, wenn ich das so angebe, gelange ich auch tatsächlich wieder auf meinen Desktop:

Hier auf dem Desktop gibt es nun einen Ordner namens „Beispielordner“. Wenn ich diesen noch in die Konsole eintippe und bestätige, werde ich in diesen hinein geleitet.

Jetzt möchte ich dir den sogenannten ls-Befehl vorstellen. Doch vorher müssen wir zunächst in der bereits vollen Konsole etwas Platz schaffen. Das gelingt uns, indem wir „clear“ eingeben und diese dadurch leeren:

Jetzt, wo uns wieder eine leere Konsole zur Verfügung steht, sehen wir uns den ls-Befehl an.

5. Der ls-Befehl

Mit dem ls-Befehl können wir den Inhalt des aktuellen Ordners, also des Ordners, in dem wir uns gerade befinden, ausgeben lassen. Im Moment sind wir im Desktop-Beispielordner, welcher eine Datei und einen Ordner enthält. Diese werde ich dir an dieser Stelle zeigen.

Dazu gebe ich „ls“ in die Kommandozeile ein, drücke die Enter-Taste und daraufhin wird uns der Inhalt dieses Verzeichnisses aufgelistet:

Wir sehen die verschiedenen Elemente in unterschiedlichen Farben hervorgehoben. Die Einkaufsliste.txt-Datei ist in Weiß geschrieben, wobei es sich um eine normale Datei handelt. Ein Ordner hingegen, wie der mit dem Namen „weiterer Ordner“, ist blau hervorgehoben. Das Nützliche am ls-Befehl ist also, dass wir damit immer sehen können, was sich im aktuellen Verzeichnis, in welchem wir sind, befindet.

An dieser Stelle möchte ich dir zeigen, wie du ein Element verschieben bzw. umbenennen kannst.

6. Der mv-Befehl

Um eine Datei beispielsweise zu verschieben, nutzt man den mv-Befehl, was für „move“ steht. Damit ist gemeint, ein Element in ein anderes hinein zu bewegen. Wie funktioniert das Ganze? Wir möchten beispielhaft einmal die Einkaufsliste.txt-Datei in den Ordner „weiterer Ordner“ verschieben. Wie machen wir das? Wir schreiben dazu einfach „mv“, dann das Element, das wir verschieben möchten (Einkaufsliste.txt) und anschließend geben wir das Element, also den Ordner an, in den wir es verschieben möchten. Da wir es in den Ordner „Weiterer Ordner“ verschieben möchten, geben wir diesen an:

Jetzt gibt es hier allerdings ein Problem. Wenn wir diese Zeile so bestätigen, denkt die Kommandozeile, wir möchten die Einkaufsliste.txt-Datei in einen Ordner namens „Weiterer“ verschieben. Das liegt daran, dass sich eine Leerzeile zwischen „Weiterer“ und „Ordner“ befindet. Im Namen selbst befindet sich tatsächlich auch ein Leerzeichen, allerdings muss die Kommandozeile sehen, dass der Name nach dem Leerzeichen noch weiter geht.

Um das zu ermöglichen, schreiben wir vor dem Leerzeichen ein Backslash (\):

Wenn wir diese Zeile jetzt bestätigen und anschließend den Befehl „ls“ schreiben, sehen wir, dass es funktioniert hat und sich im Beispielordner nur noch das Unterverzeichnis „Weiterer Ordner“ befindet:

Denn schließlich haben wir die Einkaufsliste.txt-Datei in den Ordner „Weiterer Ordner“ verschoben.

Um dir das Ganze zu demonstrieren, navigieren wir hierzu in „Weiterer Ordner“ und ergänzen bei der Namensangabe aufgrund des Leerzeichens wieder das Backslash. Anschließend drücken wir Enter und befinden uns daraufhin auch schon darin:

Wenn wir an dieser Stelle nun „ls“ schreiben, sehen wir, dass sich hierin nun auch die Einkaufsliste.txt-Datei befindet:

Um in der Konsole wieder etwas Platz zu schaffen, schreibe ich noch einmal „clear“ und drücke die Enter-Taste. Dann gebe ich wieder „ls“ ein und wie sich daraufhin erkennen lässt, haben wir wirklich nur die Einkaufsliste.txt-Datei im Ordner „Weiterer Ordner“.

Nun möchte ich dir zeigen, dass du die Einkaufsliste.txt-Datei auch wieder in das übergeordnete Verzeichnis schieben kannst, indem du „mv Einkaufsliste.txt . .“ schreibst:

Dass wir diese Datei in das übergeordnete Verzeichnis geschoben haben, kann ich dir noch einmal veranschaulichen, nachdem ich die Konsole nochmals mit „clear“ freigeräumt habe.

Navigieren wir nun noch mal selbst ins übergeordnete Verzeichnis, indem wir „cd . .“ eingeben. Nachdem wir den Befehl mit Enter bestätigt haben, geben wir „ls“ ein und sehen dann, dass die Einkaufsliste.txt-Datei wieder im Beispielordner ist:

Mit dem Befehl „mv“ kann man aber nicht nur Dateien verschieben, sondern diese auch umbenennen. Um Einkaufsliste.txt beispielsweise umzubenennen, schreibt man „mv Einkaufsliste.txt“ und gibt anschließend einen neuen Namen eines Elements an, das hier noch nicht existiert.

Wenn wir nun also einfach einen neuen Namen schreiben, anstatt den Namen des Ordners anzugeben, der sich im aktuellen Verzeichnis befindet, verschieben wir die Einkaufsliste nicht, sondern benennen sie um.

Beispielhaft nenne ich das Ganze „Shoppinglist.txt“ und lasse mir die Änderung mit dem Befehl „ls“ anzeigen:

Wie wir sehen, hat es funktioniert!

7. Der rm-Befehl

An dieser Stelle möchte ich dir zeigen, wie man mithilfe des „rm“-Befehls, welcher für „remove“ steht, Dateien löschen kann. Wir werden nun unsere Shoppinglist.txt-Datei löschen, indem wir „rm Shoppinglist.txt“ eingeben. Wenn wir das nun ausführen und anschließend „ls“ schreiben, sehen wir, dass die Shoppinglist.txt-Datei entfernt wurde:

Wichtig:
Mit diesem Befehl sollte man sehr vorsichtig umgehen. Die Shoppinglist.txt-Datei ist nämlich nicht im Papierkorb gelandet, sondern wurde tatsächlich entfernt.

Zum Schluss werden wir noch ein neues Verzeichnis mithilfe eines Konsolenkommandos erstellen.

8. Der mkdir-Befehl

Mit dem „mkdir“-Befehl, welcher für „make directory“ also „neues Verzeichnis erstellen“ steht, kann man einen neuen Ordner erstellen. Ich könnte an dieser Stelle zum Beispiel einen neuen Ordner namens „Listen“ anlegen, in dem ich verschiedene Einkaufslisten speichere.

Wenn ich diese Zeile im Anschluss bestätige, erstellt das Programm den neuen Ordner in unserem Beispielordnerverzeichnis, in welchem wir uns gerade befinden. 

Schreibe ich anschließend also noch „ls“, sehen wir den neuen Ordner „Listen“:

In diesen Ordner kann ich nun auch mit dem Befehl „cd“ hinein navigieren, obwohl er aktuell noch leer ist, weil wir ihn gerade erst erstellt haben:

So einfach kann man also mit „mkdir“ einen neuen Ordner erstellen.

An diesem Punkt habe ich dir auch schon die wichtigsten grundlegenden Befehle gezeigt, die du kennen solltest, um dich in der Git Bash zurechtzufinden.

Ich gebe nun noch einmal „clear“ ein, um die Konsole zu leeren und schreibe dann „cd“, um zurück ins User-Verzeichnis zu navigieren.

Wenn ich nun „pwd“ eingebe, siehst du, dass wir uns wieder im Verzeichnis /Users/Sorm befinden:

Zu guter Letzt möchte ich dir noch ein paar nützliche Tipps zeigen, wodurch du mit der Konsole schneller arbeiten kannst.

9. 3 nützliche Tipps für das Arbeiten in der Git Bash

Tipp 1: Text aus Zwischenablage einfügen

Zuerst einmal sehen wir uns an, wie du in der MINGW64 Bash einen Text aus einer Zwischenablage einfügen kannst. Wir können nun also beispielsweise den Pfad aus einem Ordner kopieren und diesen in der Konsole einfügen:

Wenn ich dafür nun STRG und V drücke, wie man das aus anderen Anwendungen gewohnt ist, stellen wir fest, dass das hier nicht funktioniert.

Um aus der Zwischenablage einen Text in der Konsole einzufügen, haben wir zwei Möglichkeiten:

1. Rechtsklick mit der Maus und „Paste“ auswählen.

2. SHIFT und die EINFG-Taste drücken.

Wie wir auf der folgenden Abbildung sehen, konnten wir den Text dadurch einfügen:

Zu wissen, dass man einen kopierten Text aus der Zwischenablage nicht mit STRG + V, sondern mit SHIFT + EINFG in der Konsole einfügt, ist also ziemlich wichtig.

Tipp 2: Letzten Befehl aufrufen und in die Konsole kopieren

Als Nächstes möchte ich dir den Befehlsverlauf zeigen. Mit der Pfeiltaste nach oben kannst du den letzten Befehl, den du geschrieben hast, noch mal direkt in die Konsole kopieren. Wenn du die Pfeiltaste weitere Male nach oben drückst, kannst du das sogar noch mit anderen Befehlen aus der Vergangenheit durchführen. Auf diese Art und Weise ist es möglich, durch vorherige Befehle, die du bereits geschrieben hast, nochmals zu navigieren und sie zu wiederholen. So sparst du dir die Zeit, sie erneut auszuschreiben.

Schreibe ich jetzt beispielsweise „pwd“, dann gibt das Programm mein aktuelles „working directory“ aus. Drücke ich nun aber noch mal die Pfeiltaste nach oben, schreibt das Programm direkt wieder „pwd“ in die Konsole. Weil das der letzte Befehl gewesen ist, den ich geschrieben habe. Wenn ich die Pfeiltaste hingegen nach unten drücke, wird der Befehl wieder entfernt.

Tipp 3: Autovervollständigung

Zu guter Letzt möchte ich dir die Autovervollständigung des Terminals vorstellen. Durch Drücken der Tab-Taste kann man den Text, den man gerade in der Konsole geschrieben hat, als Befehl autovervollständigen lassen.

Wir befinden uns gerade im Beispielordner, welcher sich auf meinem Desktop befindet. Dieser ist bei mir geöffnet und wir sehen dort rechts Ordner 1, Ordner 2 und Ordner 3:

Ich möchte nun mal in Ordner 3 navigieren. Dazu schreibe ich „cd“ für „change directory“, gefolgt von „Ord“ und drücke anschließend die Tab-Taste. Wie wir sehen, wird das Wort „Ordner“ auch direkt autovervollständigt:

Jetzt gibt es hier aber verschiedene Ordner mit unterschiedlichen Zahlen. Wenn ich nun noch 2-mal die Tab-Taste drücke, zeigt mir die Konsole die verschiedenen Optionen an:

Möchte ich beispielsweise den Ordner 2 auswählen, dann tippe ich die Zahl 2 ein und drücke anschließend die Enter-Taste:

Man kann also mit der Tab-Taste Texte autovervollständigen und genau das würde ich dir empfehlen, zur Gewohnheit zu machen. Damit kannst du nämlich wesentlich effektiver, schneller und mit mehr Spaß in der Konsole arbeiten. Denn: Man vertippt sich damit seltener.

An dieser Stelle sind wir auch schon am Ende dieses Beitrags angekommen. Du hast nun die Grundlagen des MINGW-Terminals kennengelernt und weißt, wie man sich durch das File-System navigieren kann. Im kommenden Artikel werden wir mit Git starten.

Inhaltsverzeichnis

1. Git installieren

Dann landen wir auch schon auf der Downloadseite. Du kannst Git installieren für MacOS, Windows oder Linux. Ich wähle Windows aus und daraufhin startet auch schon automatisch der Download:

Der Installer

Schritt 4:
Danach können wir den Start Menü Ordner wählen. Hier lasse ich auch alles so, wie es bereits ist und klicke wieder auf „Next“.

Schritt 5:
Jetzt müssen wir einen Texteditor für Git auswählen. Hier wird standardmäßig Vim verwendet, welcher meiner Meinung nach sehr kompliziert und nicht wirklich intuitiv ist. Ich wähle deshalb Visual Studio Code aus. Du kannst natürlich den wählen, der dir persönlich am meisten zusagt. Danach klicken wir wieder auf „Next“:

Schritt 6:
Nun müssen wir einstellen, wie Git den Hauptentwicklungszweig eines neuen Git-Projekts immer standardmäßig nennt. Früher nannte man den Hauptentwicklungszweig (default branch) immer Master Branch. Da dieser Name allerdings an die Sklavenhaltung erinnert und nicht inklusiv ist, forderten einige Stimmen eine Änderung des Namens.

Wenn du auf diesem Fenster auf „Let Git decide“ klickst, nennt das Programm den Hauptentwicklungszweig aktuell noch Master. Wie man dem Text darunter entnehmen kann, soll sich das in der Zukunft aber noch ändern.

Ich wähle hier „Override the default branch name for new repositories“ und nenne das Ganze „Main Branch“. Auch viele Entwicklerteams in zahlreichen Unternehmen haben das bereits so umgestellt und nennen ihre Hauptentwicklungszweige nicht mehr "Master" Branch, sondern "Main" Branch.

Ich persönlich finde auch, dass das etwas besser und aussagekräftiger klingt. Du kannst ihn natürlich auch anders nennen oder „Let Git decide“ auswählen. Nun klicke ich wieder auf „Next“:

Schritt 7:
Jetzt müssen wir einstellen, wie wir Git von unserer Kommandozeile aus verwenden möchten. Wir können oben also beispielsweise auswählen, dass wir Git nur von der „Git Bash“ aus benutzen wollen, die wir mit dem Installer zusammen mit Git installieren.

Oder wir wählen die empfohlene Option aus, die ermöglicht, dass wir Git von der Kommandozeile und von 3rd-party Software aus verwenden können. Dadurch wird eine minimale Änderung an unserer Path-Variable in Windows vorgenommen.

Darüber hinaus können wir auswählen, dass wir Git und optionale Unix-Tools von unserem Command Prompt verwenden möchten. Damit wird unsere Path-Variable so bearbeitet, dass es Git und optionale Unix-Tools hinzufügt.

Wir wählen nun aber einfach die empfohlene Option „Git from the command line and also from 3rd-part software“. In dieser Git-Tutorialreihe verwenden wir auch lediglich die Git Bash, die das Programm mitinstalliert. Dann klicken wir wieder auf „Next“:

Schritt 8:
An dieser Stelle müssen wir unseren SSH-client wählen, den Git verwendet. Wir wählen hier einfach die Standardeinstellung „Use bundled OpenSSH“. Diese liefert uns das Programm nämlich mit der Installation mit. Wenn du aber PuTTY für SSH-Aufgaben verwenden möchtest, dann wähle an dieser Stelle einfach die zweite Option.

Es gibt allerdings noch die dritte Option: „Use external OpenSSH“. Bei dieser Option verwendet man einen External OpenSSH-Client. Diesen liefert das Programm aber nicht mit dieser Installation mit. Stattdessen sucht es das Ganze auf der Path-Variable.

Wir wählen nun aber „Use bundled OpenSSH“ und klicken auf „Next“:

Schritt 9:
Auf dem nächsten Fenster müssen wir das HTTPS Transport backend auswählen. Wir wählen die Standardeinstellung „Open SSL“. Möglich wäre es auch, die native Windows Secure Channel Library zu nutzen. Wir setzen das Ganze aber mit „Open SSL“ fort und klicken auf „Next“.

Schritt 10:
Hier müssen wir nun auswählen, wie Git mit Line Endings, also dem Ende einer Zeile in Textdateien umgehen soll. Wenn wir auf der Tastatur die Enter-Taste drücken, legt eine Textdatei einen unsichtbaren Character an, der ein Zeilenende repräsentieren soll.

Verschiedene Betriebssysteme handhaben nun solche Zeilenenden unterschiedlich. Aus diesem Grund kann man hier einstellen, wie Git mit den Zeilenenden umgehen soll. Wir wählen nun die Standardeinstellung „Checkout Windows-style, commit Unix-style line endings“ aus. Anschließend drücken wir wieder auf den „Next“-Button:

Schritt 11:
Jetzt müssen wir auswählen, welchen Terminal Emulator die Git Bash verwenden soll. Uns stehen zwei Optionen zur Auswahl. Zum einen die Standardeinstellung „Use MinTTY“ und zum anderen „Use Windows‘ default console window“.

Weil MinTTY mehr Features besitzt und die Arbeit sich damit besser gestaltet, wählen wir dieses. Im unten stehenden Text sind die Unterschiede dazu noch aufgelistet. Ich werde darauf allerdings nicht eingehen, da das den Rahmen dieses Artikels sprengen würde. Wir wählen hier also einfach „Use MinTTY“ und klicken auf „Next“:

Schritt 12:
Als Nächstes müssen wir das Standardverhalten des Befehles „git pull“ einstellen. Dabei stehen uns wieder drei Optionen zur Auswahl. An dieser Stelle weißt du vermutlich noch gar nicht, welcher Befehl „git Pull“ ist und was man damit macht. Ich erkläre es dir mal ganz einfach:

Stell dir vor, du hast einen Remote Repository, also einen Git-Repository, der sich nicht auf deiner lokalen Maschine befindet und du möchtest die Daten von diesem Repository herunterladen. Wenn du jetzt dein eigenes lokales Repository, dein eigenes lokales Git-Projekt mit diesen heruntergeladenen Daten aktualisieren möchtest, machst du einen git pull.

Wir wählen an dieser Stelle „Default“ aus. Dabei handelt es sich um das Standardverhalten dieses Befehls. Anschließend klicken wir wieder auf „Next“:

Schritt 13:
Jetzt müssen wir den Credential Helper einstellen. Wir wählen wieder die Standardeinstellung, nämlich den „Git Credential Manager“ und klicken auf „Next“.

Schritt 14:
Auf dem nachfolgenden Fenster können wir nun noch ein paar zusätzliche Funktionen einstellen. Wir lassen den Haken bei „Enable file system caching“ gesetzt. Damit aktiviert das Programm file system caching, welches dafür sorgt, dass manche Operationen schneller sind. Das wird auch im Text darunter beschrieben.

„Enable symbolic links“ kann man auch auswählen. Das werde ich allerdings nicht tun, da wir diese Option aktuell nicht benötigen. Man kann damit symbolische Links verwenden. Das ist im Grunde so etwas wie eine Verknüpfung zu einer Datei. Im Anschluss klicken wir wieder auf „Next“.

Schritt 15:
Jetzt können wir noch weitere experimentelle Features aktivieren oder deaktiviert lassen. Ich lasse solche experimentellen Features generell immer deaktiviert. Abschließend klicken wir auf „Install“, wodurch wir schließlich Git installieren:

2. Git einrichten

Wenn wir die Git Installation nun abgeschlossen und zu Beginn im Installer den Desktop Shortcut ausgewählt haben, sehen wir nun auf unserem Desktop die Verknüpfung zu unserer Git-Bash.

Wenn wir diese doppelt klicken, öffnet sich ein Terminal, das wir uns nun einmal genauer ansehen werden. Dafür stellen wir zunächst den Vollbildmodus ein.

Den Text können wir vergrößern, indem wir die Strg-Taste gedrückt halten und das Mausrad scrollen:

Zum Abschluss möchten wir noch unseren Nutzernamen und unsere E-Mail konfigurieren. Der Benutzername und unsere E-Mail sind immer bei unseren Commits vermerkt.

Sprich: Wenn wir einen Commit machen, also eine Änderung an unserem Projekt vornehmen, ist diese durch unseren Namen und unsere E-Mail-Adresse gekennzeichnet.

Weil wir Commits im Nachhinein nicht mehr ändern können, tragen wir die Informationen direkt am Anfang richtig ein.

Um unseren Benutzernamen zu verändern, schreiben wir „git config --global user.name“. In Anführungszeichen schreiben wir dann den Namen. In meinem Fall ist das „Janek Pruin“:

Den Namen können wir uns jetzt auch einfach mal ausgeben lassen, indem wir schreiben: „git config --global user.name“:

Wie wir auf der Abbildung erkennen, steht darunter nun der richtige Benutzername.

Jetzt werden wir noch die E-Mail einstellen. Dazu schreiben wir „git config --global user.email  "beispiel@programmierenstarten.de“. Du kannst an dieser Stelle natürlich deine eigene E-Mail-Adresse eingeben. Anschließend bestätige ich das Ganze mit Enter und lasse mir diese auch noch mal mit der Zeile „git config --global user.email“ ausgeben:

Damit haben wir auch schon Benutzername und E-Mail eingestellt!

Da wir nun erfolgreich Git installieren konnten, werden wir uns im nächsten Beitrag zur Git-Tutorialreihe die Git-Bash noch genauer ansehen. Du wirst dort lernen, wie man darin richtig navigiert und mit der Konsole arbeitet. Denn diese Konsolen sind gerade für Neueinsteiger, die zuvor mit einer Bash noch nie gearbeitet haben, meist etwas verwirrend.

Ich werde dir also die Grundlagen der Git-Bash beibringen, damit du dich gut zurechtfinden und damit arbeiten kannst. Anschließend werden wir noch tiefer in die Materie eintauchen.

Inhaltsverzeichnis

1. Was ist Git?

2. Vorteil #1: Versionen

Mit Git hat man Versionen seiner Projekte. Git ist, wie bereits erwähnt, eine Versionsverwaltung. Das bedeutet, du kannst dir Git wie eine Zeitmaschine vorstellen. Sollte seit dem letzten hinzugefügten Update oder Feature etwas kaputt gegangen sein, kann man mit Git nämlich jederzeit zu einem früheren Stand eines Projekts zurückspringen und diesen wiederherstellen.

Wenn sich in unser Projekt also Fehler einschleichen, können wir diese wieder rückgängig machen.

Und das ist unheimlich wertvoll! Stell dir beispielsweise einmal das folgende Szenario vor:

Wir arbeiten an einem Grafikeditor wie Photoshop oder paint.NET und uns kommt die Idee für ein großartiges neues Feature in den Sinn, mit welchem man Effekte zu Bildern hinzufügen kann. Diese Idee setzen wir auch direkt in die Praxis um und veranlassen ein Update für unser Programm.

Komischerweise bekommen wir seit dieses neue Feature veröffentlicht ist plötzlich ständig E-Mails von Kunden, die Programmabstürze und andere Probleme beklagen.

Wir stellen also fest, dass unsere Software durch das letzte Effekte-Feature nicht mehr richtig funktioniert – irgendetwas ist schiefgelaufen.

Mithilfe von Git ist es jetzt möglich, einfach zu dem Punkt zurückzuspringen, an dem wir das Feature noch nicht implementiert hatten. Wir müssen also nicht unter Druck nach einer Lösung für das Problem aufgrund des neuen Features suchen, sondern können mit ein paar einfachen Befehlen wieder zu unserer vorherigen Version zurückkehren. So können wir das Ganze wieder sauber und strukturiert aufs Neue entwickeln und dafür sorgen, dass es diesmal fehlerfrei funktioniert.

Wir können durch Git also für jedes neue Feature, das wir implementiert haben, eine neue Version für unser Projekt erstellen. Das setzen wir mithilfe von sogenannten Commits um.

3. Was ist ein Commit?

Nun können wir im Verlauf dieses Zeitstrahls weitere Commits (Änderungen) zu unserem Projekt hinzufügen. Ein neuer Commit könnte beispielsweise sein, dass wir eine Benutzeroberfläche gestaltet haben:

Ein weiterer Commit könnte so aussehen: Wir haben ein Zeichnen-Feature zu unserer Software hinzugefügt. Man kann jetzt also in unserem Grafikeditor auch mit einem Pinsel malen.

Anschließend fügen wir zwei weitere Commits hinzu: eine Speicher- und eine Ladefunktion.

Und zu guter Letzt fügen wir noch das Effekte-Feature für unsere Grafiksoftware hinzu:

Genau an dieser Stelle mussten wir feststellen, dass im Programm etwas kaputt gegangen ist. Denn seit wir diesen Commit hinzugefügt haben, erhalten wir zahlreiche E-Mails, die uns darauf hinweisen, dass das Programm nicht mehr so funktioniert, wie es sollte.

Mithilfe von Git können wir jetzt also ganz einfach zu dem Punkt zurückkehren, an dem es zuletzt noch funktioniert hat und von dort aus weiterentwickeln.

An diesem Punkt behalten wir also noch alle Fortschritte der vorherigen Commits, das letzte Effekt-Feature ist nun aber nicht mehr enthalten.

Versionen sind allerdings nicht der einzige Vorteil, den Git zu bieten hat.

4. Vorteil #2: Branches

Jetzt haben wir eine Idee für ein neues Feature. Wirklich sicher sind wir uns allerdings noch nicht, ob dieses tatsächlich in unser Projekt passt. Genau deshalb möchten wir das Feature erst einmal unabhängig von diesem Hauptzweig entwickeln.

Wir können also einfach einen neuen parallelen Branch erstellen, der den Hauptentwicklungszweig nicht beeinflusst. Auf diesem Branch können wir unser neues Feature entwickeln.

Wenn wir das Feature dann irgendwann fertig entwickelt haben und es in unser Projekt passt, können wir den Nebenentwicklungszweig, auf dem wir nur das Feature entwickelt haben, mit unserem Hauptentwicklungszweig „mergen“. Sie also zusammenfließen lassen.

Dass wir auf diese Weise neue Features experimentell entwickeln können, ohne unser Hauptprojekt zu beeinflussen, ist ein weiterer großer Vorteil von Git.

5. Vorteil #3: Einfaches Zusammenarbeiten

Bei Projekten mit mehreren Entwicklern kann es bekanntermaßen hin und wieder zu Dateikonflikten kommen, wenn zwei Entwickler beispielsweise eine Codedatei bearbeiten. Oder sie möchten ihre Commits erstellen und die Änderungen stehen unbeabsichtigt in Konflikt miteinander.

Git erkennt solche Konflikte und hilft den Entwicklern dabei, diese relativ einfach zu lösen. Das ist gerade für die Teamarbeit ein weiterer enormer Vorteil.

Bei den drei Vorteilen, die du in diesem Beitrag kennengelernt hast, handelt es sich um die Hauptvorteile von Git. Damit stellt es ein unglaublich wertvolles Werkzeug dar. Es ist kostenlos und einfach in der Handhabung, sobald man es einmal gelernt hat. Und genau das wirst du auch in den weiteren Beiträgen zu diesem Thema.

Ich kann wärmstens empfehlen, Git für die eigenen Projekte zu nutzen.

6. Was ist GitHub?

Jetzt steht aber noch eine andere Frage im Raum: Wenn Git die Versionsverwaltung ist, was ist dann eigentlich GitHub?

Diesen Namen liest man auch nicht selten im Internet. Viele, die diesen Beitrag lesen, wissen sicherlich auch bereits, dass GitHub eine Website ist.

GitHub ist eine Online-Plattform, die auf github.com zu erreichen ist. Auf github.com kann man sich einen Account erstellen und darauf eigene Git-Projekte hosten oder sich ganz einfach an deren Open Source Projekten beteiligen. GitHub ist die größte Plattform für Programmierprojekte der Welt und diese nutzt eben Git.

Du weißt jetzt also, dass Git selbst die Software ist, die die Versionsverwaltung darstellt und dass es sich bei GitHub um eine Plattform handelt, auf der Entwickler Git-Projekte hosten können.

Auf GitHub werde ich noch in einem zukünftigen Beitrag eingehen.

Inhaltsverzeichnis

1. Ein Tkinter Entry Widget erzeugen

Um ein Tkinter Entry Widget zu erzeugen, definieren wir zunächst eine Variable, die wir beispielhaft entry1 nennen. Anschließend weisen wir dieser ttk.Entry zu und geben wieder root als Parent an. Damit das Ganze sichtbar ist, packen wir es mithilfe der pack-Methode in die GUI:

Um zudem direkt die verfügbaren Optionen für dieses Widget sehen zu können, greifen wir wieder auf unseren kleinen Trick mit der for-Schleife zurück. Wir schreiben also Folgendes:

An dieser Stelle führen wir das Programm einfach direkt mal aus:

Wie du sehen kannst, befindet sich jetzt in der GUI ein Eingabefeld, in welches wir klicken und einen beliebigen Text eingeben können.

Wenn wir jetzt einen Blick auf die Konsole werfen, sehen wir zudem alle verfügbaren Optionen für dieses Widget, da wir uns diese schließlich über die for-Schleife ausgeben lassen.

2. Die Option width

Unter anderem befindet sich in der Auflistung die Option width, welche standardmäßig aktuell auf den Wert 20 gesetzt ist. 

Damit können wir die Breite des Eingabefeldes festlegen. Der aktuelle Wert ist, wie bereits erwähnt, auf 20 gesetzt, was der Länge entspricht, die wir momentan in der GUI sehen. 

Um das Ganze zu verdeutlichen, erhöhen wir den Wert zu Beginn direkt auf das Doppelte, also auf 40. Dazu ändern wir die Option width auf den Wert 40:

Wenn wir das Programm erneut ausführen, wird das Eingabefeld doppelt so breit dargestellt:

Geben wir in das Eingabefeld viel Text ein und erreichen damit das Ende des Feldes, erkennen wir, dass wir auch dann noch weiter schreiben können.

Im Feld scrollt das Programm automatisch weiter, wodurch wir nicht auf eine gewisse Anzahl von Zeichen limitiert sind. Wenn wir uns nun noch die weiteren Optionen ansehen, dann tauchen unter anderem foreground und background auf:

Damit können wir jeweils die Schrift- und Hintergrundfarbe verändern.

3. Die Option foreground

Beginnen wir einfach mal mit der Schriftfarbe und ändern diese im Code auf den Wert rot:

Nachdem wir das Programm ausgeführt haben und etwas in das Feld eintippen, wird die Schrift tatsächlich in Rot dargestellt:

Das funktioniert also schon mal einwandfrei. Für die Hintergrundfarbe können wir jetzt noch die Option background setzen.

4. Die Option background

Dafür wählen wir beispielsweise die Farbe Schwarz, da rot und schwarz ganz gut zusammenpassen könnten. Wir setzen also background auf den Wert „black“:

Anschließend führen wir das Programm aus und bereits beim Schreiben in das Eingabefeld entdecken wir ein Problem: Die Hintergrundfarbe ist nach wie vor weiß und wurde damit nicht gesetzt:

Das hat den gleichen Grund wie im Beitrag zum Label Widget bereits beschrieben. Manche Optionen können mit bestimmten Themes und auch generell auf spezifischen Plattformen wie etwa Mac OS schlichtweg nicht gesetzt werden.

Deshalb löschen wir die Schlüsselwortargumente, die wir eben gesetzt haben, um die Farben zu ändern, einfach noch mal weg:

5. Die Option justify im Tkinter Entry Widget

Wenn wir erneut einen Blick auf die Konsolenausgabe werfen, können wir auch eine Option mit dem Namen justify sehen. Außerdem fällt auf, dass diese Option standardmäßig auf den Wert left, also links gesetzt ist.

Das bedeutet, beim Eingeben von Text in das Eingabefeld wird dieser automatisch linksbündig ausgerichtet. Führen wir das Ganze noch einmal aus und geben etwas Text ein, startet dieser von links:

Die Ausrichtung lässt sich aber auch über die Option justify ändern. Dazu bewegen wir uns in den Code, geben justify an und setzen die Option beispielsweise auf rechts:

Nachdem wir das Programm wieder ausgeführt und etwas Text eingegeben haben, ist dieser nun rechtsbündig:

Genauso könnten wir justify auch auf den Wert center setzen, um den Text mittig zu zentrieren:

Das ist also die Option justify. Bevor wir fortfahren, setzen wir justify allerdings wieder auf den Default-Wert linksbündig. Dafür löschen wir die Option, die wir gerade manuell gesetzt haben, einfach aus dem Code:

6. Die Nutzereingabe des Tkinter Entry Widgets verarbeiten

Bisher haben wir schon einige Modifizierungsmöglichkeiten gesehen. Die Frage ist nun aber, wie wir mit dem eingegebenen Text weiterarbeiten können, denn schließlich soll die Eingabe des Nutzers verwertet werden.

Das funktioniert ziemlich einfach, da wir auf den aktuellen Inhalt des Eingabefeldes zugreifen können, indem wir die get-Methode auf dem Entry-Objekt aufrufen. Das setzen wir jetzt mal an einem kleinen Beispiel um.

Wir erzeugen uns dafür einen zusätzlichen Button und packen diesen dann mithilfe der pack-Methode in die GUI, was wir im Code folgendermaßen umsetzen:

Jedes Mal, wenn wir diesen Button dann klicken, soll der Inhalt, der aktuell im Eingabefeld steht, auf der Konsole ausgegeben werden.

Eine Funktion für die Ausgabe des Inhalts erstellen

Wir definieren uns also eine Funktion und nennen diese beispielhaft print_entry_input. Wie bereits erwähnt, erhalten wir den Inhalt über die get-Methode. Das heißt, wir schreiben print und rufen auf entry1 die get-Methode auf:

Jetzt müssen wir die Funktion nur noch dem Button zuweisen, damit diese aufgerufen wird, sobald wir auf den Button klicken.

Eine Funktion an den Buttonklick koppeln

Das funktioniert über die Option command, indem wir Folgendes im Code schreiben:

An dieser Stelle führen wir das Programm einfach mal aus. Dadurch sehen wir in der GUI das Eingabefeld und darüber hinaus einen neuen Button mit der Aufschrift „Eingabe ausgeben!“. Wenn ich nun einen Text wie beispielsweise meinen Namen eingebe und auf den Button klicke, gibt das Programm diesen Text auf der Konsole aus:

Wir können den Text auch erweitern zu „Hendrik ist mein Name!“ und den Button erneut klicken. Auch dieser Inhalt wird auf der Konsole ausgegeben.

Ein Label anstelle der Konsolenausgabe erzeugen

Anstatt das Ganze auf der Konsole anzeigen zu lassen, könnten wir auch bei jedem Funktionsaufruf ein neues Label-Objekt erzeugen, welches wir dann direkt in die GUI packen. Dort weisen wir dann als Text den aktuellen Inhalt des Eingabefeldes zu.

Hierfür müssen wir lediglich den Inhalt der Funktion print_entry_input verändern und festlegen, dass ein ttk-Label erzeugt werden soll. Wir platzieren es beim Parent root und als Text weisen wir entry1.get() zu. Anschließend platzieren wir das Ganze mithilfe der pack-Methode in der GUI, damit wir es direkt sehen können:

Um den Code direkt auszuprobieren, geben wir einen Text wie beispielsweise meinen Namen „Hendrik“ ein, klicken auf den Button und sehen dann, dass der Text aus dem Eingabefeld in Form eines Labels in der GUI platziert wird:

Das Ganze funktioniert also einwandfrei.

Damit weißt du jetzt, wie du an den Text gelangen kannst, der sich aktuell im Eingabefeld befindet. Es gibt nun allerdings zwei weitere sehr nützliche Methoden, die ich dir ebenfalls noch vorstellen möchte.

7. Die insert-Methode

Dazu gehört zum einen die Methode insert. Mithilfe dieser können wir über unseren Code etwas in das Eingabefeld schreiben. Wenn wir also unter dem Aufruf der pack-Methode auf dem Tkinter Entry Objekt die insert-Methode aufrufen, indem wir beispielsweise entry1.insert angeben, haben wir die Möglichkeit, zwei Argumente zu übergeben.

Zuerst schreiben wir 0, wobei es sich um den Index handelt, den ich gleich noch genauer erklären werde. Als zweites Argument übergeben wir den String, der in das Eingabefeld geschrieben werden soll. Dafür wählen wir beispielsweise den Satz „Hier kannst du schreiben!“:

Wenn wir das Programm jetzt ausführen, sehen wir bereits direkt zu Beginn im Eingabefeld auf der GUI den String „Hier kannst du schreiben!“.

Der Text, der nun im Eingabefeld steht, kann vom Nutzer aber weiterhin beliebig verändert werden. 

Das heißt, wir könnten in das Feld klicken und sowohl etwas vom Text entfernen als auch etwas dazuschreiben. Die Funktionalität ist nach wie vor gegeben.

Was hat es aber nun mit dem Index auf sich, den wir innerhalb der insert-Methode zu Beginn als erstes Argument übergeben haben?

Mit diesem legen wir fest, an welcher Stelle wir beim bestehenden Text im Eingabefeld den String einfügen möchten, der als zweites Argument folgt.

Angenommen, wir rufen eine Zeile unterhalb des Methodenaufrufs noch einmal die insert-Methode auf, geben diesmal den Index 2 an und an der Stelle mit dem Index 2 möchten wir den String „TEST“ in Großbuchstaben einfügen.

Jetzt führen wir das Programm noch aus und überprüfen, was passiert:

Was geschieht, ist nun folgendes: Zunächst wird mit dem ersten Aufruf der insert-Methode der Text „Hier kannst du schreiben!“ in das Eingabefeld geschrieben.

Daraufhin rufen wir erneut die insert-Methode auf und geben an, dass wir bei Index 2 noch den String „TEST“ einfügen möchten. Folglich wird dieser bei Index 2, also nach dem zweiten Zeichen des Strings, der bereits im Eingabefeld steht, eingefügt. In diesem Fall mitten im Wort „hier“.

Das macht an dieser Stelle zwar keinen Sinn, aber schließlich sollte dir das Beispiel nur demonstrieren, welchen Zweck der Index innerhalb der insert-Methode erfüllt.

8. Die delete-Methode

Neben der get- und der insert-Methode existiert noch die Methode delete, welche sich in manchen Fällen als nützlich erweist. Damit wir uns diese genauer ansehen können, löschen wir zunächst einmal den gesamten Code bis auf das Tkinter entry-Widget und den Button. Wir löschen im Programm also die folgenden rot markierten Zeilen:

Auch die Funktion löschen wir erst mal:

Jetzt programmieren wir eine neue Funktion, die wir delete_input() nennen.

Innerhalb dieser Funktion führen wir auf dem entry-Objekt die delete-Methode aus und schreiben dazu entry1.delete:

Diese delete-Methode erwartet jetzt zwei Argumente.

Mit dem ersten Argument geben wir den Index an, ab dem der Text innerhalb des Eingabefeldes gelöscht werden soll. Hierfür wählen wir beispielhaft den Index 0. Mit dem zweiten Index geben wir den Endindex an, bis zu welchem gelöscht werden soll. 

Da wir möchten, dass der gesamte Inhalt des Eingabefeldes gelöscht wird, wählen wir als Start-Index wie gerade erwähnt 0 und als Endindex tk.END:

Mit tk.END teilen wir dem Programm mit, dass wir den letztmöglichen Index angeben möchten. Als command für den Button weisen wir nun diese neue Funktion zu. Die Funktion print_entry_input gibt es nicht mehr, weshalb wir diese aus den Klammern löschen und durch die neue Funktion ersetzen:

Da sich die Funktionalität des Buttons jetzt geändert hat, sollten wir auch dessen Text verändern, um Verwirrungen auszuschließen. Wir löschen also „Eingabe ausgeben!“ und schreiben stattdessen „Input löschen!“.

Nachdem wir das Programm anschließend ausgeführt haben, tippen wir testweise ein paar Buchstaben in das Eingabefeld:

Wenn wir daraufhin auf den Button klicken, sehen wir, dass alles gelöscht wird:

Geben wir danach wieder etwas ein und klicken auf den Button, löscht das Programm erneut den gesamten Inhalt des Eingabefeldes.

Wenn wir in den Klammern der delete-Methode nicht tk.END angegeben hätten, sondern beispielsweise einen spezifischen Endindex wie etwa 5, würde die Methode nur die ersten fünf Zeichen des Textes löschen, der sich im Eingabefeld befindet.

Probieren wir auch das einmal aus und öffnen das Programm. In das Eingabefeld geben wir nun beispielhaft „Hallo, das ist ein Test“ ein, klicken anschließend auf „Input löschen!“ und sehen dann, dass die ersten fünf Zeichen und damit das Wort „Hallo“ gelöscht wurden:

Danach folgen ein noch vorhandenes Leerzeichen und der restliche Text. Klicken wir jetzt erneut auf „Input löschen!“, werden wieder die ersten fünf Zeichen vom bestehenden String gelöscht. So ließe sich das dann fortführen, bis zu dem Punkt, an dem nichts mehr im Eingabefeld stehen würde.

Damit bist du nun mit dem nötigen Wissen ausgestattet, um auch das Tkinter Entry Widget innerhalb deiner Programme sinnvoll nutzen zu können. 

9. Abschließende Worte

Mit den Fähigkeiten, die du in dieser Tutorial-Reihe erworben hast, kannst du nun deine ersten einfachen Anwendungen mit grafischen Benutzeroberflächen in Python erstellen.

Ein Beispiel wäre ein Bitcoin-Preisrechner: Eine Anwendung, die die Anzahl der Bitcoins, die der Nutzer eingibt, aufnimmt und berechnet, wie viel diese zum aktuellen Kurs wert sind.

Das ist beispielsweise eines von mehreren Projekten, die wir gemeinsam im Tkinter-Masterkurs umsetzen werden.

Im Tkinter Masterkurs wirst du darüber hinaus noch wesentlich mehr lernen. Wir werden uns darin nämlich alle wichtigen Widgets ansehen, die in Tkinter existieren. In dieser Tutorial-Reihe hast du drei davon kennengelernt, allerdings gibt es noch einige mehr, die benötigt werden, um komplexere Anwendungen mit Tkinter zu erstellen.

Zu diesen Widgets zählen unter anderem die folgenden:

• Frame-Widget
• LabelFrame-Widget
• Checkbutton-Widget
• Radiobutton-Widget
• Separator-Widget
• Scrollbar-Widget
• Progressbar-Widget
• Combobox-Widget
• Spinbox-Widget
• Scale-Widget

Diese werden wir uns alle detailliert im Python-Tkinter-Masterkurs ansehen.

Neben den zahlreichen Widgets werde ich dir aber auch weitere Layout-Manager vorstellen, du wirst das Eventhandling lernen, wie du deine eigene GUI stylen kannst, wie du objektorientierte GUI-Anwendungen baust und vieles mehr.

All dieses Wissen werden wir dann in weiteren Praxisprojekten vertiefen, wie beispielsweise einer To-do-Listen-App, einem Nachrichtenverschlüsselungsprogramm und vielem mehr.