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. # 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` |