Branching - Arbeitsstände verwalten

    Ein sogenannter Branch ist ein Arbeitsstand Ihres Dokuments. Sie können mehrere Branches erstellen, um verschiedene Versionen Ihres Dokuments parallel zu bearbeiten und zu koordinieren. Sie können etwa einen Branch für die Ergänzung einer neuen Begründung erstellen, während der Hauptbranch (main) die aktuelle abgestimmte Version Ihres Dokuments enthält.

    Empfohlene Strategie

    Branching

    Hauptbranch (main)

    Der Hauptbranch (main) sollte immer den stabilen und produktiven Zustand enthalten. Änderungen sollten nur in Form von Merge-Requests in den Hauptbranch gemerged werden, nachdem sie überprüft und getestet wurden.

    Merge Requests

    Siehe Merge Requests (Änderungsanträge).

    Tagging

    Siehe Versionierung der Dokumente.

    Weitere Benamungsregeln

    Es ist wichtig, ein konsistentes und verständliches Namensschema für Branches zu verwenden, um die Übersichtlichkeit und Nachvollziehbarkeit im Fortschreibungsprozess zu gewährleisten. Die Benennung sollte klar und beschreibend sein, damit alle AutorInnen schnell erkennen können, welche Art von Arbeit in einem Branch erfolgt.

    • fix/… Branches, die für Fehlerbehebungen verwendet werden. Sie sollten mit fix/ beginnen, gefolgt von einer kurzen Beschreibung des Bugs oder der ID des entsprechenden Issues (Tickets).

      Beispiel: fix/fussnote-av-01 oder fix/40_rechtschreibfehler

    • feature/… Branches, die für die Entwicklung neuer Features oder Funktionen verwendet werden. Sie sollten mit feature/ beginnen, gefolgt von einer kurzen Beschreibung des Features oder der Funktion.

      Beispiel: feature/ergaenzung-bund-av-05 oder feature/30_neues-kapitel

    • prerelease/v… Branches, die für die Vorbereitung auf eine bevorstehende Veröffentlichung verwendet werden. Sie sollten mit prerelease/v beginnen, gefolgt von der Versionsnummer (semantisch versioniert), auf die sie sich beziehen.

      Beispiel: prerelease/v1.1.0 oder prerelease/v2.0.0

    • update/… Branches, die für die Aktualisierung des Dokuments verwendet werden. Das ist besonders für Ableitungen, z. B. im Kontext der Nationalen IT-Architekturrichtlinie relevant. Sie sollten mit update/ beginnen, gefolgt von einer kurzen Beschreibung der Aktualisierung.

      Beispiel: update-1-0-1-foederale-it-architekturrichtlinie

    Schützen von Branches (Branch Protection)

    Es ist empfehlenswert, den Hauptbranch (main) und andere wichtige Branches zu schützen, um zu verhindern, dass unerwünschte Änderungen direkt in diese Branches gemerged werden.

    Wir empfehlen Ihnen unter “Settings” → “Repository” → “Branch rules” die folgenden Regeln zu definieren:

    Screenshot der Einstellungssektion eines Repositories für Branch Protections mit der Einstellung, dass ausschließlich maintainer pushen und mergen dürfen für die Branches 'main', 'prerelease' und 'update'