3.4 Git Branching - Branching-Workflows

Da Git ein einfaches 3-Wege-Merge verwendet, ist mehrmaliges Zusammenführen von einem Branch in einen anderen über einen langen Zeitraum generell einfach zu bewerkstelligen. Das bedeutet, du kannst mehrere Branches haben, die immer offen sind und die du für unterschiedliche Stadien deines Entwicklungszyklus verwendest; du kannst sie regelmäßig mit anderen zusammenführen.

Viele Git-Entwickler folgen einem Workflow, welcher den Ansatz verfolgt, nur stabilen Code im master Branch zu haben – möglicherweise auch nur Code, der released wurde oder werden soll. Sie haben einen weiteren parallele Branches namens develop oder next, auf denen Sie arbeiten oder die Sie für Stabilitätstests nutzen. Diese sind nicht zwangsläufig stabil, aber wann immer sie einen stabilen Zustand erreichen, können sie mit dem master Branch zusammengeführt werden. Sie werden genutzt, um Features (kurzlebige Branches, wie der früher genutzte iss53 Branch) einfließen zu lassen, wenn diese fertiggestellt sind. Damit wird sichergestellt, dass sie alle Tests bestehen und keine Fehler einführen.

Eigentlich reden wir gerade über Zeiger, die sich in der Reihe der Commits, die du durchführst, vorwärts bewegen. Die stabilen Branches sind weiter hinten und die allerneuesten Branches sind weiter vorn im Verlauf.

Es ist einfacher, sich die verschiedenen Branches als Silos vorzustellen, in denen Gruppen von Commits in stabilere Silos aufsteigen, sobald sie vollständig getestet wurden.

Du kannst das für mehrere Stabilitätsgrade einrichten. Einige größere Projekte haben auch einen Branch proposed (vorgeschlagen) oder pu (proposed updates – vorgeschlagene Updates), in welchem Branches integriert sind, die vielleicht noch nicht bereit sind in den Branch next oder master einzufließen. Die Idee dahinter ist, dass Ihre Branches verschiedene Stabilitäts-Level repräsentieren. Sobald sie einen Grad höherer Stabilität erreichen, werden sie mit dem nächsthöheren Branch zusammengeführt. Zur Erinnerung: Langfristig verschiedene Branches parallel laufen zu lassen, ist nicht notwendig, aber oft hilfreich. Insbesondere dann, wenn man es mit sehr großen oder komplexen Projekten zu tun hat.

Feature-Branches sind in Projekten jeder Größe nützlich. Ein Feature-Branch ist ein kurzlebiger Branch, welchen du für eine ganz bestimmte Funktion oder zusammengehörende Arbeiten erstellst und nutzt. Das ist etwas, was du wahrscheinlich noch nie zuvor mit einem Versionsverwaltungssystem gemacht hast, weil es normalerweise zu aufwändig und mühsam ist, Branches zu erstellen und zusammenzuführen. Aber bei Git ist es vollkommen üblich, mehrmals am Tag Branches zu erstellen, an ihnen zu arbeiten, sie zusammenzuführen und sie anschließend wieder zu löschen.

Du hast das im letzten Abschnitt an den erstellten Branches iss53 und hotfix gesehen. Du führst mehrere Commits auf diesen Branches durch und löschst sie sofort, nachdem du sie mit deinem Hauptbranch zusammengeführt hast. Diese Technik erlaubt es dir, schnell und vollständig den Kontext zu wechseln – da deine Arbeit auf verschiedene Silos aufgeteilt ist, wo alle Änderungen auf diesem Branch unter diese Thematik fallen, ist es leichter nachzuvollziehen, was bei Code-Überprüfungen und Ähnlichem geschehen ist. Du kannst die Änderungen darin für Minuten, Tage oder Monate aufbewahren und sie einfließen lassen (mergen), wenn diese fertig sind, ungeachtet der Reihenfolge, in welcher diese erstellt oder bearbeitet wurden.

Betrachten wir folgendes Beispiel: Du erledigst gerade einige Arbeiten (auf master), zweigst davon ab wegen eines Problems (iss91), arbeitest daran eine Weile, zweigst davon den zweiten Branch ab, um eine andere Möglichkeit zur Handhabung desselben Problems auszuprobieren (iss91v2), wechselst zurück zu deinem master Branch und arbeitest dort eine Zeit lang, und zweigst dann dort nochmal ab, um etwas zu versuchen, bei dem du dir nicht sicher bist, ob es eine gute Idee ist (dumbidea Branch). Dein Commit-Verlauf wird in etwa so aussehen:

Angenommen, du hast dich jetzt entschieden, dass dir die zweite Lösung für dein Problem (iss91v2) am besten gefällt; und du hast den dumbidea Branch deinen Mitstreitern gezeigt und es hat sich herausgestellt, dass er genial ist. Du kannst also den ursprünglichen iss91 Branch (unter Verlust der Commits C5 und C6) wegwerfen und die anderen beiden einfließen lassen. Dein Verlauf sieht dann so aus:

In Kapitel 5 Verteiltes Git werden wir die verschiedenen möglichen Arbeitsabläufe für dein Git-Projekt noch detaillierter betrachten. Bevor du dich also entscheidest, welches Branching-Modell du für dein nächstes Projekt nutzen willst, solltest du unbedingt dieses Kapitel gelesen haben.

Es ist wichtig, sich bei all dem daran zu erinnern, dass diese Branches nur lokal existieren. Wenn du Branches anlegst und zusammenführst, geschieht das alles nur in deinem lokalen Git-Repository – es findet keine Server-Kommunikation statt.