Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Strategie zur Branchierung von Gitflow Gitflow ist ein Verzweigungsmodell, bei dem mehrere Zweige verwendet werden, um Code von der Entwicklung in die Produktion zu übertragen. Gitflow eignet sich gut für Teams, die Release-Zyklen geplant haben und eine Sammlung von Funktionen als Release definieren müssen. Die Entwicklung wird in einzelnen Feature-Branches abgeschlossen, die mit Genehmigung zu einem Entwicklungszweig zusammengeführt werden, der für die Integration verwendet wird. Die Funktionen in diesem Zweig gelten als produktionsbereit. Wenn sich alle geplanten Funktionen im Entwicklungsbereich angesammelt haben, wird ein Release-Zweig für Implementierungen in höheren Umgebungen erstellt. Diese Trennung verbessert die Kontrolle darüber, welche Änderungen nach einem festgelegten Zeitplan in welche benannte Umgebung übertragen werden. Bei Bedarf können Sie diesen Prozess beschleunigen und zu einem schnelleren Bereitstellungsmodell übergehen. Weitere Informationen zur Gitflow-Branching-Strategie finden Sie in den folgenden Ressourcen: + [Implementieren Sie eine Gitflow-Branching-Strategie für Umgebungen mit mehreren Konten DevOps ](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-gitflow-branching-strategy-for-multi-account-devops-environments.html) (Prescriptive Guidance)AWS + [Der ursprüngliche Gitflow-Blog (Blogbeitrag](https://nvie.com/posts/a-successful-git-branching-model/) von Vincent Driessen) + [Gitflow-Workflow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) (Atlassian) **Topics** + [Visueller Überblick über die Gitflow-Strategie](visual-overview-of-the-gitflow-strategy.md) + [Branchen in einer Gitflow-Strategie](branches-in-a-gitflow-strategy.md) + [Vor- und Nachteile der Gitflow-Strategie](advantages-and-disadvantages-of-the-gitflow-strategy.md) # Visueller Überblick über die Gitflow-Strategie Das folgende Diagramm kann wie ein [Punnett-Quadrat verwendet werden, um die Gitflow-Verzweigungsstrategie](https://en.wikipedia.org/wiki/Punnett_square) zu verstehen. Richten Sie die Zweige auf der vertikalen Achse mit den AWS Umgebungen auf der horizontalen Achse aus, um zu bestimmen, welche Aktionen in den einzelnen Szenarien ausgeführt werden sollen. Die eingekreisten Zahlen führen Sie durch die Reihenfolge der Aktionen, die im Diagramm dargestellt sind. Weitere Informationen zu den Aktivitäten, die in den einzelnen Umgebungen stattfinden, finden Sie in diesem [DevOps Handbuch unter Umgebungen](understanding-the-devops-environments.md). ![\[Zusammenfassung der Gitflow-Aktivitäten in den einzelnen Branchen und Umgebungen\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/choosing-git-branch-approach/images/gitflow-diagram.png) # Branchen in einer Gitflow-Strategie Eine Gitflow-Branching-Strategie besteht üblicherweise aus den folgenden Verzweigungen. ![\[Die Branches und Umgebungen in einer Gitflow-Branching-Strategie.\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/choosing-git-branch-approach/images/gitflow-branching-strategy.png) ## Feature-Zweig `Feature`Branches sind kurzfristige Branches, in denen du Funktionen entwickelst. Die `feature` Verzweigung entsteht durch eine Abzweigung von der `develop` Verzweigung. Entwickler iterieren, übertragen und testen den Code im `feature` Branch. Wenn die Funktion abgeschlossen ist, bewirbt der Entwickler die Funktion. Von einem Feature-Branch aus gibt es nur zwei Pfade vorwärts: + Mit dem `sandbox` Zweig zusammenführen + Erstellen Sie eine Anfrage zur Zusammenführung mit der `develop` Filiale | | | | --- |--- | | Benennungskonvention: | `feature/__` | | Beispiel für eine Namenskonvention: | `feature/123456_MS_Implement_Feature_A` | ## Sandbox-Zweig Der `sandbox` Branch ist ein nicht standardmäßiger, kurzfristiger Branch für Gitflow. Er ist jedoch nützlich für die CI/CD Pipeline-Entwicklung. Der `sandbox` Zweig wird hauptsächlich für folgende Zwecke verwendet: + Führen Sie eine vollständige Bereitstellung in der Sandbox-Umgebung durch, indem Sie die CI/CD Pipelines anstelle einer manuellen Bereitstellung verwenden. + Entwickeln und testen Sie eine Pipeline, bevor Sie Zusammenführungsanfragen für vollständige Tests in einer niedrigeren Umgebung, z. B. Entwicklung oder Tests, einreichen. `Sandbox`Zweige sind temporärer Natur und nicht für eine lange Lebensdauer konzipiert. Sie sollten gelöscht werden, nachdem die spezifischen Tests abgeschlossen sind. | | | | --- |--- | | Namenskonvention: | `sandbox/__` | | Beispiel für eine Namenskonvention: | `sandbox/123456_MS_Test_Pipeline_Deploy` | ## Zweig entwickeln Der `develop` Zweig ist ein langlebiger Zweig, in dem Funktionen integriert, erstellt, validiert und in der Entwicklungsumgebung bereitgestellt werden. Alle `feature` Zweige sind in der `develop` Filiale zusammengeführt. Zusammenführungen mit der `develop` Filiale werden über eine Zusammenführungsanfrage abgeschlossen, für die ein erfolgreicher Build und zwei Genehmigungen durch Entwickler erforderlich sind. Um das Löschen zu verhindern, aktivieren Sie den Branch-Schutz für den `develop` Branch. | | | | --- |--- | | Benennungskonvention: | `develop` | ## Zweig freigeben In Gitflow sind `release` Branches kurzfristige Branches. Diese Branches sind besonders, weil du sie in mehreren Umgebungen bereitstellen kannst, wobei du die Build-Once-Deploy-Many-Methode verwendest. `Release`Branches können auf Test-, Staging- oder Produktionsumgebungen abzielen. Nachdem ein Entwicklungsteam beschlossen hat, Funktionen in höheren Umgebungen einzuführen, erstellt es einen neuen `release` Branch und verwendet inkrementell die Versionsnummer der vorherigen Version. An den Eingängen in jeder Umgebung müssen Bereitstellungen manuell genehmigt werden, um fortzufahren. `Release`Für Branches sollte eine Merge-Anfrage erforderlich sein, damit sie geändert werden kann. Nachdem der `release` Branch in Betrieb genommen wurde, sollte er wieder mit den `main` Zweigen `develop` und zusammengeführt werden, um sicherzustellen, dass alle Bugfixes oder Hotfixes wieder in future Entwicklungsbemühungen einfließen. | | | | --- |--- | | Namenskonvention: | `release/v{major}.{minor}` | | Beispiel für eine Namenskonvention: | `release/v1.0` | ## Hauptzweig Der `main` Zweig ist ein langlebiger Zweig, der immer den Code darstellt, der in der Produktion ausgeführt wird. Nach einer erfolgreichen Bereitstellung aus der `main` Release-Pipeline wird Code automatisch aus einem Release-Branch mit dem Branch zusammengeführt. Um das Löschen zu verhindern, aktivieren Sie den Branch-Schutz für den `main` Branch. | | | | --- |--- | | Benennungskonvention: | `main` | ## Bugfix-Zweig Der `bugfix` Branch ist ein kurzfristiger Branch, der verwendet wird, um Probleme in Release-Branches zu beheben, die noch nicht für die Produktion freigegeben wurden. Ein `bugfix` Branch sollte nur verwendet werden, um Fixes in `release` Branches in der Test-, Staging- oder Produktionsumgebung weiterzuleiten. Ein `bugfix` Zweig ist immer von einem `release` Zweig abgezweigt. Nachdem der Bugfix getestet wurde, kann er durch eine Merge-Anfrage in den `release` Branch hochgestuft werden. Anschließend können Sie den `release` Branch weiterentwickeln, indem Sie dem Standard-Release-Prozess folgen. | | | | --- |--- | | Namenskonvention: | `bugfix/__` | | Beispiel für eine Namenskonvention: | `bugfix/123456_MS_Fix_Problem_A` | ## Hotfix-Zweig Der `hotfix` Zweig ist ein kurzfristiger Zweig, der zur Behebung von Problemen in der Produktion verwendet wird. Sie dient ausschließlich der Förderung von Problembehebungen, die schnellstmöglich in der Produktionsumgebung eingeführt werden müssen. Ein `hotfix` Zweig wird immer abgezweigt von. `main` Nachdem der Hotfix getestet wurde, können Sie ihn mithilfe einer Merge-Anfrage in den `release` Branch, aus dem er erstellt wurde, zur Produktion hochstufen. `main` Zum Testen können Sie den `release` Branch dann weiterentwickeln, indem Sie dem Standard-Release-Prozess folgen. | | | | --- |--- | | Benennungskonvention: | `hotfix/__` | | Beispiel für eine Namenskonvention: | `hotfix/123456_MS_Fix_Problem_A` | # Vor- und Nachteile der Gitflow-Strategie Die Gitflow-Branching-Strategie eignet sich gut für größere, stärker verteilte Teams, die strenge Freigabe- und Compliance-Anforderungen haben. Gitflow trägt zu einem vorhersehbaren Release-Zyklus für das Unternehmen bei, was häufig von größeren Organisationen bevorzugt wird. Gitflow eignet sich auch gut für Teams, die Leitplanken benötigen, um ihren Softwareentwicklungszyklus ordnungsgemäß abzuschließen. Dies liegt daran, dass in die Strategie mehrere Möglichkeiten zur Überprüfung und Qualitätssicherung integriert sind. Gitflow eignet sich auch gut für Teams, die mehrere Versionen von Produktionsversionen gleichzeitig verwalten müssen. Einige Nachteile von GItflow bestehen darin, dass es komplexer ist als andere Verzweigungsmodelle und die strikte Einhaltung des Musters erfordert, um erfolgreich abgeschlossen zu werden. Gitflow eignet sich aufgrund der starren Art der Verwaltung von Release-Branches nicht gut für Unternehmen, die eine kontinuierliche Bereitstellung anstreben. Gitflow-Release-Branches können langlebige Branches sein, in denen sich technische Schulden anhäufen können, wenn sie nicht rechtzeitig behoben werden. ## Vorteile Die GitFlow-basierte Entwicklung bietet mehrere Vorteile, die den Entwicklungsprozess verbessern, die Zusammenarbeit rationalisieren und die Gesamtqualität der Software verbessern können. Im Folgenden sind einige der wichtigsten Vorteile aufgeführt: + **Vorhersehbarer Release-Prozess** — Gitflow folgt einem regelmäßigen und vorhersehbaren Release-Prozess. Es eignet sich gut für Teams mit regelmäßigen Entwicklungs- und Veröffentlichungsrhythmen. + **Verbesserte Zusammenarbeit** — Gitflow fördert die Verwendung von `feature` und `release` Branches. Diese beiden Zweige helfen Teams dabei, parallel und mit minimalen Abhängigkeiten voneinander zu arbeiten. + **Gut geeignet für mehrere Umgebungen** — Gitflow verwendet `release` Branches, bei denen es sich um langlebigere Branches handeln kann. Diese Branches ermöglichen es Teams, einzelne Releases über einen längeren Zeitraum hinweg ins Visier zu nehmen. + **Mehrere Versionen in der Produktion** — Wenn Ihr Team mehrere Versionen der Software in der Produktion unterstützt, unterstützen `release` Gitflow-Branches diese Anforderung. + **Integrierte Überprüfungen der Codequalität** — Gitflow verlangt und fördert die Verwendung von Codeprüfungen und Genehmigungen, bevor Code in einer anderen Umgebung veröffentlicht wird. Dieser Prozess beseitigt Reibungspunkte zwischen Entwicklern, da dieser Schritt für alle Code-Werbeaktionen erforderlich ist. + **Vorteile für die Organisation** — Gitflow hat auch auf Organisationsebene Vorteile. Gitflow empfiehlt die Verwendung eines Standard-Release-Zyklus, der der Organisation hilft, den Release-Zeitplan zu verstehen und zu antizipieren. Da das Unternehmen jetzt weiß, wann neue Funktionen bereitgestellt werden können, gibt es weniger Reibungsverluste in Bezug auf Zeitpläne, da es feste Liefertermine gibt. ## Nachteile Die GitFlow-basierte Entwicklung hat einige Nachteile, die sich auf den Entwicklungsprozess und die Teamdynamik auswirken können. Im Folgenden sind einige bemerkenswerte Nachteile aufgeführt: + **Komplexität** — Gitflow ist ein komplexes Muster, das neue Teams erlernen müssen, und du musst dich an die Regeln von Gitflow halten, um es erfolgreich zu nutzen. + **Kontinuierliche Bereitstellung** — Gitflow passt nicht zu einem Modell, bei dem viele Implementierungen schnell für die Produktion freigegeben werden. Das liegt daran, dass Gitflow die Verwendung mehrerer Branches und einen strikten Workflow für den Branch erfordert. `release` + **Filialverwaltung** — Gitflow verwendet viele Branches, deren Wartung aufwändig werden kann. Es kann schwierig sein, die verschiedenen Branches nachzuverfolgen und den veröffentlichten Code zusammenzuführen, um die Branches korrekt aufeinander abzustimmen. + **Technische Schulden** — Da Gitflow-Releases in der Regel langsamer sind als die anderen Branching-Modelle, können sich bis zur Veröffentlichung mehr Funktionen ansammeln, was dazu führen kann, dass sich technische Schulden anhäufen. Teams sollten diese Nachteile sorgfältig abwägen, wenn sie entscheiden, ob eine GitFlow-basierte Entwicklung der richtige Ansatz für ihr Projekt ist.