Git Branch: Ein Leitfaden zum Erstellen, Verwalten und Zusammenführen von Zweigen

Wenn du schon einmal an einem Gruppenprojekt gearbeitet hast, weißt du, wie schnell die Dinge außer Kontrolle geraten können, wenn mehrere Personen gleichzeitig versuchen, die doppelten Dateien zu aktualisieren. Es kommt zu Konflikten, Bugs schleichen sich ein und der Fortschritt kommt zum Stillstand. Hier kommen die Git-Zweige ins Spiel - nicht als fortschrittlicher Trick, sondern als Grundlage für eine saubere, parallele Entwicklung.

In Git wird das Verzweigen nicht nur gefördert, sondern erwartet. Egal, ob du mit einer neuen Funktion experimentierst, einen Fehler behebst oder den Code einer anderen Person überprüfst, mit Zweigen kannst du arbeiten, ohne anderen auf die Füße zu treten. Sie ermöglichen es dir, Dinge zu brechen, zu iterieren und dann deine Änderungen sauber in die Hauptcodebasis zu integrieren.

Dieser Leitfaden führt dich durch die Grundlagen des Branching in Git. Wir beginnen mit git branch und git checkout und sehen uns dann genauer an, wie Zweige erstellt, verwaltet, zusammengeführt und gelöscht werden. Außerdem besprechen wir Best Practices, damit du deinen Arbeitsablauf konfliktfrei gestalten kannst. Ich hoffe, dass du am Ende dieses Leitfadens mehr weißt, als nur die Befehle auswendig zu lernen: Du wirst etwas mehr über den Ablauf der Arbeit verstehen. Wenn all das für dich interessant ist und du weiter üben möchtest, ist unser Kurs Einführung in die GitHub-Konzepte ein guter Startpunkt.

Git-Zweige verstehen

Nachdem wir nun die Voraussetzungen geschaffen haben, wollen wir uns ansehen, was ein Git-Zweig ist. Im Grunde ist ein Git-Zweig kein separater Ordner oder eine vollständige Kopie deiner Codebasis, sondern nur ein leichtgewichtiger Verweis auf einen bestimmten Commit. Das ist einer der Gründe, warum sich Git von älteren Versionskontrollsystemen abhebt: Verzweigungen sind schnell, billig und zentral für die täglichen Arbeitsabläufe.

Stell dir einen Zweig wie eine Zeitleiste vor. Wenn du einen neuen Zweig erstellst, sagst du im Grunde: "Lass uns von hier aus einen neuen Weg erkunden." Alle deine Änderungen bleiben auf diesem Pfad, bis du dich entscheidest, sie wieder in die Hauptlinie einzubinden oder nicht. Diese Flexibilität macht es unglaublich einfach, Ideen auszuprobieren, Funktionen isoliert zu entwickeln und mit anderen zusammenzuarbeiten, ohne den stabilen Code zu beeinträchtigen.

Git merkt sich deine aktuelle Position im Projekt mithilfe eines speziellen Verweises namens HEAD. Wenn du den Zweig wechselst, zeigt HEAD auf die Spitze des neuen Zweigs. Dieses Detail hinter den Kulissen ermöglicht es Git, den Kontext so schnell zu wechseln, und es ist auch der Grund, warum sich Befehle wie git checkout und git switch so nahtlos anfühlen, sobald du verstehst, was unter der Haube passiert.

Wenn du verstehst, wie Git-Zweige funktionieren, kannst du deinen Entwicklungs-Workflow mit Klarheit und Vertrauen organisieren. Wenn du diese Konzepte ausprobieren möchtest, kannst du im DataCamp-Kurs "Git für Fortgeschrittene" das Verzweigen mit vielen Übungen üben.

Auflisten und Anzeigen von Git-Zweigen

Du hast also Lernpfade erstellt und benutzt sie, aber wie behältst du den Überblick? Zum Glück bietet Git einfache, aber leistungsstarke Werkzeuge, um Zweige aufzulisten, zu sortieren und zu filtern, damit du deinen Arbeitsablauf nicht aus den Augen verlierst.

Prüfen des aktuellen Zweigs

Prüfen wir zunächst, welche Zweige in deinem lokalen Repository existieren und in welchem du dich gerade befindest.

git branch

Dieser Befehl listet alle deine lokalen Zweige auf. Du wirst ein Sternchen ( *) neben deinem aktuellen Zweig sehen. Für einen noch gezielteren Look probiere es aus:

git branch --show-current

Dies gibt nur den Namen des Zweigs zurück, in dem du gerade arbeitest, und zwar sauber.

Möchtest du auch abgelegene Zweige sehen? Verwenden:

git branch -r

Und wenn du sowohl lokale als auch entfernte Zweige gleichzeitig sehen möchtest:

git branch -a

So bekommst du einen vollständigen Überblick über die Verzweigungsstruktur deines Projekts, was besonders hilfreich ist, wenn du mit anderen auf Plattformen wie GitHub zusammenarbeitest. 

Sortieren und Filtern von Zweigen

Wenn dein Projekt wächst, wächst auch deine Liste der Zweige. Sortierung und Filterung helfen dir, diese Liste effektiv zu verwalten. Um Zweige nach dem letzten Übergabedatum zu sortieren, verwende:

git branch --sort=-committerdate

Du kannst auch nach anderen Kriterien sortieren, z. B. nach dem Namen des Autors, dem Erstellungsdatum oder der Upstream-Konfiguration. Hier ist eine praktische Funktion zum Filtern von Zweigen, die einen bestimmten Commit enthalten:

git branch --contains <commit>

Dies zeigt dir, in welchen Zweigen ein bestimmter Commit bereits enthalten ist. So kannst du überprüfen, ob eine Fehlerbehebung oder ein Feature bereits in diese Zweige eingefügt wurde. Umgekehrt zeigt dir der folgende Befehl, welche Zweige diesen Commit nochnicht abgeholt haben:

git branch --no-contains <commit>

Zur effektiven Verwaltung von Zweigstellen gehört es, sie zu schaffen und für Transparenz und Kontrolle zu sorgen. Diese Befehle helfen dir, deine Entwicklung sauber, organisiert und effizient zu halten.

Willst du wissen, wie sie sich auf die Zusammenarbeit auswirken? Der Kurs Foundations of Git bietet eine hervorragende Grundlage und behandelt reale Arbeitsabläufe, die du immer wieder verwenden wirst.

Einen neuen Git-Zweig erstellen

Da du jetzt weißt, wie du Zweige auflisten und zwischen ihnen wechseln kannst, gehen wir jetzt durch die Erstellung der Zweige. Branching ist ein zentraler Bestandteil des Git-Workflows und zum Glück ist das Erstellen neuer Branches ganz einfach, egal ob du einen Feature-Branch, einen Hotfix oder etwas ganz Neues ausprobieren möchtest.

Einen Zweig ohne Wechsel erstellen

Manchmal möchtest du einen Zweig erstellen, ohne ihn sofort zu betreten. Das ist nützlich, wenn du mehrere Zweige gleichzeitig vorbereitest oder wenn du Arbeitsabläufe für andere einrichtest.

git branch new-feature

Dieser Befehl erstellt einen Zweig mit dem Namen new-feature, aber du bist immer noch in deinem aktuellen Zweig. Du kannst später dazu wechseln, wenn du bereit bist, daran zu arbeiten.

Gleichzeitiges Erstellen und Wechseln zu einem Zweig

Wenn du direkt in die Entwicklung einsteigst, kannst du den neuen Zweig in einem Zug erstellen und zu ihm wechseln. In älteren Git-Versionen würdest du verwenden:

git checkout -b new-feature

Im modernen Git ist der Ansatz jedoch transparenter und intuitiver:

git switch -c new-feature

Dadurch wird nicht nur der Zweig erstellt, sondern er wird auch sofort ausgecheckt, sodass du mit der Arbeit beginnen kannst.

Upstream-Zweige setzen

Wenn du mit entfernten Repositories arbeitest, möchtest du oft, dass dein lokaler Zweig einen entfernten Zweig verfolgt. Das macht das Verschieben und Abrufen von Updates einfacher. Um einen Lernpfad zu erstellen, der von Anfang an einen entfernten Zweig verfolgt, benutze:

git branch --track new-feature origin/new-feature

Wenn du den Zweig bereits erstellt hast und den Upstream setzen oder ändern willst, ist dieser Befehl genau das Richtige:

git branch --set-upstream-to=origin/new-feature

Diese Konfiguration stellt sicher, dass deine lokale Zweigstelle weiß, von welcher entfernten Zweigstelle sie abrufen bzw. zu welcher sie pushen muss, damit dein Arbeitsablauf reibungslos funktioniert.

Wechseln zwischen Git-Zweigen

Wenn du ein paar Zweige erstellt hast, musst du oft zwischen ihnen hin- und herspringen, sei es, dass du zum main zurückspringst, um eine Korrektur zusammenzuführen, oder dass du zu einem Feature-Zweig wechselst, um weiter zu programmieren. Git macht diesen Prozess nahtlos, und wie bei den meisten Dingen, die mit Git zu tun haben, gibt es mehr als einen Weg, dies zu tun.

Git Checkout verwenden

Lange Zeit war git checkout das Mittel der Wahl, um den Zweig zu wechseln:

git checkout feature-login

Mit diesem Befehl wechselst du dein Arbeitsverzeichnis zum Zweig feature-login und aktualisierst alle deine Dateien auf den Snapshot dieses Zweigs. Sie ist zuverlässig und immer noch weit verbreitet. Aber die Sache ist die: git checkout macht eineMenge von Dingen. Er wird verwendet, um Zweige zu wechseln, Dateien wiederherzustellen und sogar Commits auszuchecken. Das kann verwirrend sein, vor allem, wenn du gerade anfängst.

Git-Switch verwenden

Um die Dinge intuitiver zu machen, hat Git in Version 2.23 the git switch eingeführt:

git switch feature-login

Diese Funktion macht genau das, was du erwartest: Sie schaltet Zweige um. Er berührt deinen Arbeitsbaum nicht und setzt deine Dateien nicht zurück, es sei denn, du sagst es ihm. Es ist einfacher, sicherer und leichter zu lehren und zu merken.

Wann solltest du also was verwenden?

• Verwende git switch, um zwischen den Zweigen zu wechseln - es ist klar und zweckmäßig.
• Verwende git checkout, wenn du Dateien wiederherstellen oder einen bestimmten Commit auschecken musst.

Git-Zweige zusammenführen

Du hast also an einem Feature in einem separaten Zweig gearbeitet. Jetzt kommt der Moment der Wahrheit: Du musst deine Änderungen im Hauptzweig zusammenführen. In Git wird dieser Prozess merging genannt. Abhängig von der Geschichte deiner Zweige gibt es verschiedene Möglichkeiten, an die Sache heranzugehen.

Schnelles Zusammenführen

Nehmen wir an, dein feature branch ist von the main ausgegangen, und während du daran gearbeitet hast, hat niemand sonst das main angefasst. In diesem Fall muss Git nicht viel nachdenken. Er verschiebt den Zeiger main einfach auf die letzte Übertragung in feature-branch.

git checkout main
git merge feature-branch

Es wird kein neuer Commit erstellt - Git spult vor main. Sauber, einfach und perfekt für Soloprojekte oder kurzlebige Zweige.

Dreifacher Zusammenschluss

Interessanter wird es, wenn sich beide Zweige unabhängig voneinander weiterentwickelt haben. Es kann sein, dass dein Teamkollege einige Änderungen an der main vorgenommen hat, während du in the feature branch programmiert hast. Jetzt muss Git drei Snapshots betrachten: den gemeinsamen Vorgänger, deinen Zweig und den Zielzweig.

git checkout main
git merge feature-branch

In diesem Fall erstellt Git einen neuen Merge Commit, um die beiden Zweige zu kombinieren. Wenn es Konflikte gibt, z.B. weil du und dein Teamkollege die gleiche Zeile in der gleichen Datei geändert haben, wird Git dich auffordern, sie manuell zu lösen. Du bearbeitest die Datei, markierst sie als gelöst und übergibst die Zusammenführung dann.

git add .
git commit

Wenn das ein bisschen einschüchternd klingt, schau dir unser Git Merge Tutorial an: Ein umfassender Leitfaden mit Beispielen ist ein hervorragender Leitfaden, der alles Wesentliche abdeckt, einschließlich des eleganten Umgangs mit Konflikten.

Rebasing statt Zusammenführen

Bist du kein Fan von Merge-Commits, die deinen Verlauf durcheinander bringen? Du bist nicht allein. Hier kommt Git rebase ins Spiel. Anstatt einen neuen Merge Commit zu erstellen, legt rebase deine Änderungen auf einen anderen Zweig, was zu einem sauberen, linearen Verlauf führt.

git checkout feature-branch
git rebase main

Wenn du dann zusammenführst, sieht Git eine gerade Linie - ein Merge Commit ist nicht nötig. Verwende sie jedoch mit Vorsicht, vor allem wenn du mit gemeinsamen Zweigen arbeitest. Das Umschreiben der Geschichte kann gefährlich sein, wenn andere an demselben Code arbeiten.

Um zu lernen, wann es am besten ist, Merge vs. Rebase zu verwenden (und wie man sicher rebasiert), ist die Git für Fortgeschrittene Kurs eine praktische und praxisnahe Anleitung.

Löschen von Git-Zweigen

Nach einer erfolgreichen Zusammenführung ist es ratsam, alle nicht mehr benötigten Zweige zu bereinigen, sowohl lokal als auch per Fernzugriff. So bleibt dein Arbeitsbereich aufgeräumt und dein Git-Verlauf ist leichter zu navigieren. Wir zeigen dir, wie du das machen kannst, ohne den Schlaf zu verlieren, weil du aus Versehen etwas Wichtiges gelöscht hast.

Löschen von Zweigstellen

Wenn ein Zweig zusammengeführt wurde und seine Arbeit erledigt ist, kannst du ihn sicher aus deinem lokalen Repository löschen:

git branch -d feature-branch

Das Flag-d steht für "löschen". Git prüft, ob der Zweig bereits zusammengeführt wurde, um möglichen Datenverlust zu vermeiden.

Aber was ist, wenn du einen Zweig löschen willst, auch wenn er bereits zusammengeführt wurde? Hier kommt das große -D ins Spiel:

git branch -D feature-branch

Dadurch wird das Löschen erzwungen, auch wenn Git dich warnt, dass der Zweig noch nicht zusammengeführt wurde. Bevor du die Eingabetaste drückst, solltest du dich vergewissern, dass du die Änderungen nicht brauchst.

Möchtest du tiefer in die Verwaltung deines lokalen Arbeitsbereichs und deiner Filialen eintauchen? Schau dir unsere Git Pull Force an: Wie man einen lokalen Zweig mit einem entfernten Tutorial überschreibt. Es ist ein hilfreicher Begleiter, um sicherzustellen, dass du Zweige nicht nur löschst, sondern auch sicher verwaltest.

Löschen von entfernten Zweigen

Die Aufräumarbeiten vor Ort sind nur die Hälfte der Arbeit. Wenn der Zweig auch auf einem anderen Server (z.B. GitHub) liegt, solltest du ihn auch dort entfernen, vor allem, wenn du mit der Funktion oder der Fehlerbehebung fertig bist.

git push origin --delete feature-branch

Mit diesem Befehl wird Git angewiesen, den Zweig aus dem Ursprung remote zu entfernen . Sie ist sauber und direkt und verhindert, dass deine Fernbedienung mit ungenutzten Ästen überladen wird.

Wenn du entfernte Zweige gelöscht hast, solltest du auch deine lokalen Lernpfade aufräumen.

git fetch -p

Die -p steht für "Pflaume". Er entfernt alle veralteten Remote-Tracking-Zweige, die nicht mehr auf dem Server existieren.

Für weitere hilfreiche Git-Hygienegewohnheiten sind das Git Push and Pull Tutorial und das Complete Git Cheat Sheet die perfekten Schnellreferenzen.

Pushing und Pulling von Git-Zweigen

Wenn du deine Zweige lokal erstellt und organisiert hast, musst du sie im nächsten Schritt mit dem entfernten Repository synchronisieren. Das ist wichtig für die Zusammenarbeit und die Datensicherung. Wir zeigen dir, wie du Zweige effektiv schieben, ziehen und verfolgen kannst.

Einen neuen Zweig in die Ferne schieben

Du hast eine neue Funktion lokal erstellt und getestet und möchtest sie nun mit deinem Team teilen oder sichern. Um einen neuen Zweig in ein entferntes Repository (in der Regel mit dem Namen origin) zu verschieben, verwendest du:

git push -u origin new-feature

Das -u Flag (kurz für --set-upstream) weist Git an, sich den entfernten Zweig für zukünftige Pulls und Pushs zu merken. Auf diese Weise kannst du beim nächsten Mal einfach git pull oder git push ausführen, ohne den Zweig anzugeben.

Wenn du dich fragst, was sonst noch bei einem Push oder Pull hinter den Kulissen passiert, erklärt dir unser Git Push und Pull Tutorial alles anhand von Beispielen.

Änderungen aus einem entfernten Zweig ziehen

Angenommen, jemand anderes hat Updates für denselben Zweig veröffentlicht, an dem du gerade arbeitest. Du solltest diese Änderungen nach unten ziehen, um synchron zu bleiben:

Git pull origin new-feature

Damit holst du dir die neuesten Commits vom Remote-Zweig und führst sie in deinem lokalen Zweig zusammen. Wenn du das Zusammenführen von Commits vermeiden willst, kannst du folgendes verwenden:

git pull --rebase origin new-feature

Wie im Abschnitt über das Zusammenführen erklärt, hilft --rebase dabei, deinen Commit-Verlauf sauber zu halten.

Lernpfad für einen entfernten Zweig

Wenn du mit einem Zweig arbeiten willst, der bereits auf der Gegenstelle existiert, ist es am einfachsten, alles einzurichten:

git checkout --track origin/feature-xyz

Dieser Befehl checkt den entfernten Zweig aus und richtet automatisch ein Tracking ein, damit zukünftige Pulls und Pushs ein Kinderspiel sind.

Häufige Probleme und Fehlerbehebung

Auch bei den besten Arbeitsabläufen läuft nicht immer alles reibungslos. Egal, ob ein Merge-Konflikt, ein versehentlich gelöschter Zweig oder nicht übertragene Änderungen im Weg sind, Git hat Werkzeuge, die dir helfen, das Problem zu lösen. Sehen wir uns einige der häufigsten Verzweigungsprobleme an und wie man sie behebt.

Umgang mit Konflikten beim Zusammenführen

Du hast gerade versucht, einen Zweig zusammenzuführen, und Git löst einen Merge-Konflikt aus. Das passiert, wenn zwei Zweige denselben Teil einer Datei unterschiedlich ändern und Git nicht entscheiden kann, welche Änderung beibehalten werden soll.

Hier erfährst du, wie du es angehen kannst:

git status

So erfährst du, welche Dateien in Konflikt stehen. Dann kannst du verwenden:

git diff

Um zu sehen, was die Ursache des Problems ist. Öffne dann die konfliktbehaftete(n) Datei(en) manuell, löse die Unterschiede auf und

git add <resolved-file>
git commit

Wenn du mehr über das Zusammenführen von Arbeitsabläufen und das Lösen von Konflikten erfahren möchtest, schau dir das Git Merge Tutorial an, das einen kompletten Durchgang bietet.

Gelöschte Zweige wiederherstellen

Du hast versehentlich einen Zweig gelöscht und spürst, wie die Panik einsetzt? Keine Sorge - es ist nicht für immer verloren, wenn du schnell handelst.

Du kannst sie mit git reflog wiederherstellen, das deine letzten HEAD-Positionen protokolliert:

git reflog

Finde den Commit-Hash, bevor du den Zweig gelöscht hast, und stelle ihn dann mit wieder her:

git checkout -b your-branch-name <commit-hash>

Und schon ist dein Zweig wieder da. Willst du besser verstehen, wie Git diese Referenzen verfolgt? Unser Git Reflog Guide erklärt es mit echten Beispielen.

Speichern von Änderungen vor dem Wechsel

Manchmal willst du den Zweig wechseln, aber du hast noch nicht bestätigte Änderungen. Git lässt dich nicht wechseln, wenn du dadurch Arbeit verlieren könntest. Hier kommt git stash ins Spiel.

git stash

Und Git wird deine Änderungen vorübergehend beiseite legen. Nach dem Wechsel der Zweige kannst du sie mit zurückbringen:

git stash pop

Das ist besonders hilfreich, wenn du zwischen Features oder Hotfixes springst.

Wenn du viele Änderungen verwaltest oder dein Arbeitsverzeichnis aufräumst, könnte dich auch Git Clean interessieren: Unverfolgte Dateien entfernen und Repos aufgeräumt halten.

Erweiterte Verzweigungsstrategien

Inzwischen hast du gesehen, wie du mit Leichtigkeit Git-Zweige erstellen, wechseln und verwalten kannst. Aber wie nutzen Teams diese Zweige in realen Projekten? Die Antwort liegt in der Wahl der richtigen Verzweigungsstrategie - eine Struktur dafür, wie und wann du Verzweigungen in deinem Entwicklungsworkflow verwendest. Schauen wir uns einige der beliebtesten Ansätze an.

Arbeitsablauf für Feature-Zweige

Der Arbeitsablauf der Feature-Zweige ist eine der gängigsten Strategien, vor allem bei gemeinschaftlichen Projekten. So funktioniert es:

Jedes neue Feature bekommt einen eigenen Zweig, der aus dem Hauptzweig (oder dem Entwicklungszweig) erstellt wird . So können Entwicklerinnen und Entwickler unabhängig arbeiten, ohne den produktionsreifen Code zu beeinträchtigen.

git switch -c feature/login-page

Sobald die Funktion fertiggestellt und getestet ist, wird sie über einen Pull-Request wieder in den Hauptzweig (oder einen Staging-Zweig) eingebunden.

Dieses Modell hilft dabei, die Arbeit zu isolieren, macht Code-Reviews überschaubarer und verhindert, dass dein Hauptzweig mit halbfertigen Funktionen überladen wird. Damit die Zusammenarbeit aus der Ferne reibungslos funktioniert, darfst du nicht vergessen, deine Zweige zu pushen:

git push -u origin feature/login-page

Brauchst du eine Auffrischung beim Schieben und Ziehen von Ästen? Das Git Push und Pull Tutorial führt dich durch den gesamten Prozess.

GitFlow Arbeitsablauf

Wenn du an einem Projekt mit regelmäßigen Releases arbeitest, könnteGitFlow eine gute Wahl sein. Dieser Workflow führt strukturierte Rollen für verschiedene Zweigarten ein:

• main: enthält immer produktionsreifen Code.

• develop: Integrationszweig für Funktionen.

• feature/*: Kurzlebige Zweige für neue Funktionen.

• release/*: Vorproduktionszweige zum Testen.

• hotfix/*: Schnellreparaturen basieren auf der main.

Hier ist ein kurzes Beispiel für das Starten eines neuen Zweigs mit den GitFlow-Tools:

git flow feature start payment integration

Diese Strategie ist zwar etwas komplizierter, aber sie eignet sich gut für größere Teams, in denen eine klare Struktur und Stabilität wichtig sind. Wenn du dich für Workflows jenseits von GitHub interessierst, schau dir What GitLab Is an: Features, Benefits, and How to Get Started für eine andere Sichtweise auf strukturierte Git-Praktiken.

Trunk-basierte Entwicklung

Bevorzugst du minimale Verzweigungen und eine schnelle Lieferung? Trunk-basierte Entwicklung könnte dein Stil sein. Bei dieser Strategie verpflichten sich alle Entwickler zu einem einzigen Zweig, in der Regel dem main, mit kleinen und häufigen Übertragungen. Anstelle von langlebigen Feature-Zweigen fördert dieser Ansatz kurzlebige Zweige oder direkte Commits an den main Zweig.

Es ist schnell und einfach, erfordert aber Disziplin, eine starke Testautomatisierung und gute Kommunikation. Dieses Modell ist in Startups und Teams, die DevOps oder CI/CD praktizieren, Standard. Die Wahl einer Verzweigungsstrategie hängt von der Größe deines Teams und der Veröffentlichungshäufigkeit ab, und natürlich auch vom Grad der Zusammenarbeit.

Fazit

Branches sind das Herzstück des Versionskontrollsystems von Git. Sie ermöglichen es Entwicklern, isoliert an neuen Funktionen, Fehlerbehebungen und Experimenten zu arbeiten, ohne die Hauptcodebasis zu stören. Diese Flexibilität führt zu saubereren, besser organisierten Arbeitsabläufen und einer besseren Zusammenarbeit im Team.

Indem du häufig Commits machst, verantwortungsbewusst zusammenführst und eine saubere Branch-Struktur pflegst, reduzierst du das Risiko von Konflikten und machst deine Codebasis übersichtlicher und einfacher zu pflegen. Zweifellos hilft dir die Beherrschung von Git-Zweigen dabei, mit der Zeit bessere Software zu liefern.