Merge Requests (Änderungsanträge)

    Mit einem sogenannten Merge Request können Sie Änderungen mit einem geordneten Prozess von einem Branch in einen anderen übernehmen. Ein häufiger Anwendungsfall ist, wenn Sie z. B. in einem Feature-Branch gearbeitet haben und Ihre Änderungen in den Haupt-Branch übernehmen möchten.

    Wir empfehlen Ihnen ausdrücklich die Verwendung von Merge Requests.

    Vorgehen

    Ausgangslage: Sie haben ein möchten ein Issue bearbeiten und Änderungen in den prerelease/v6.2.1-Branch übernehmen.

    1. Sie erstellen einen neuen Branch fix/xyz ausgehend von dem prerelease/v6.2.1 Branch (siehe auch Branching).
    2. Sie können nun schon einen Merge Request anlegen, um die Änderungen zu diskutieren.
      1. Navigieren Sie unter Code zu Merge Requests.
      2. Klicken Sie auf New merge request.
      3. Wählen Sie als Source branch den fix/xyz Branch und als Target branch den prerelease/v6.2.1 Branch.
      4. Klicken Sie auf Compare branches and continue.
      5. Geben Sie einen Titel und eine Beschreibung ein. Hier empfehlen wir Ihnen das Issue zu referenzieren.
      6. Da Sie noch in der Bearbeitung sind, können Sie den Merge Request als Draft markieren. (Mark as draft)
      7. Klicken Sie auf Create merge request.
    3. Nehmen Sie die Änderungen auf dem fix/xyz Branch vor.
    4. Wenn Sie mit den Änderungen zufrieden sind, können Sie den Merge Request als Ready markieren.
    5. Ein Kollege kann nun den Merge Request prüfen und ggf. kommentieren. Nutzen Sie hierfür die Funktion, einen Reviewer hinzuzufügen.
    6. Wenn alle Änderungen besprochen und ggf. angepasst wurden, kann der Merge Request gemerged werden.

    Squashing

    Wir empfehlen Ihnen, Squashing NICHT zu verwenden.

    Beim Mergen von Merge Requests können Sie die Änderungen in einem Commit zusammenfassen. Dies wird als Squashing bezeichnet. Hierbei wird ein neuer Commit erstellt, der alle Änderungen zusammenfasst. Dies kann den Vorteil haben, dass die Historie übersichtlicher wird.

    Allerdings verlieren Sie hierdurch einen wesentlichen Teil der Nachvollziehbarkeit und Transparenz. Weiter benötigen insbesondere im Fall einer Ableitung die technischen Werkzeuge eine detaillierte Commit-Historie. So basiert z. B. die automatische Berechnung der zugrundeliegenden Version der Nationalen IT-Architekturrichtlinie auf einem Abgleich der Commit-Historie.