Dieser Teil stellt eine Perspektive zum git Branching dar. Es gibt noch andere. Branches sind auch Thema im Kurs Agile Team Coding. (Spoiler Warnung: Die Botschaft lautet: Lass es!)
Wie du deine Branches strukturierst
Eine einfache Möglichkeit, deine Git-Projekte zu strukturieren, wenn du im Team arbeitest, besteht darin, einen Standard-Master-Branch, einen Entwicklungs-Branch und Feature-Branches zu haben.
Master-Branch
Dein Master-Branch ist der Hauptbranch, den du beim Erstellen eines Projekts verwendest. Dieser Branch enthält in der Regel eine funktionierende und getestete Version des Programms.
Historisch ist der Begriff "master"-Branch geläufig - seit einiger Zeit ist jedoch ein Trend erkennbar, den Hauptbranch eines Repositories "main" zu nennen. GitLab und GitHub erstellen mittlerweile standardmäßig den "main" anstelle des "master"-Branch.
Entwicklungs-Branch (Dev)
Ein Entwicklungs-Branch wird erstellt, um einen Arbeitszweig zu haben. Hier werden Änderungen vorgenommen und Feature-Branches zusammengeführt (gemerged). Erst wenn die aktuelle Version des Programms getestet ist und einwandfrei funktioniert, wird sie mit dem Master-Branch zusammengeführt (gemerged).
Feature-Branches
Feature-Branches werden erstellt, um an einer bestimmten Funktion eines Programms zu arbeiten. Zum Beispiel die Implementierung einer Schaltfläche zum Speichern. Für jedes neue Feature, das implementiert wird, wird ein neuer Feature-Branch erstellt. Wenn man in Teams an einem Projekt arbeitet, können Feature-Branches für jede einzelne Funktion, die implementiert wird, erstellt werden, um Konflikte bei der Zusammenführung (also beim Merging) zu vermeiden. Da jeder an seiner eigenen Version des Programms arbeitet und nicht alle an einer Version, die ständig geändert wird. Der Feature-Zweig wird immer aus dem Dev-Branch erstellt und dann auch wieder mit diesem zusammengeführt (gemerged).