Branching, Zusammenführung und Tagging

Best Practices für GIT:

• Entwickler sollten mit anderen Branches als dem Haupt-Branch arbeiten.

• Bei jeder Entwicklung (Bug, neue Funktionen) wird ein Funktions-Branch erstellt. Die Entwickler arbeiten im lokalen Modus und fordern die Prüfung Ihrer Commits an, bevor sie ihre Änderungen in das dezentrale „Haupt“-Repository integrieren.

  Bei einem dezentralen Talend-GIT-Projekt werden standardmäßig lokale Branches (Local Mode (Lokaler Modus)) verwendet. Wenn die Entwickler an einem GIT-Projekt im lokalen oder Offline-Modus arbeiten, arbeiten sie mit dem lokalen Branch, der mit dem Branch verknüpft ist, an dem sie zuletzt gearbeitet haben. Die vorgenommenen Änderungen werden automatisch in das lokale GIT-Repository übertragen.

  Sobald die Funktion bereit ist, müssen die Entwickler die Commits an den dezentralen Entwicklungs-Branch übertragen, bevor sie diesen Remote Branch zum Test der Funktion herausnehmen und in den „Haupt“-Branch integrieren. In GIT wird ein Remote Branch für das gesamte Repository erstellt, sodass er in allen Projekten des Repository verfügbar ist.

  Weitere Informationen zur Verwendung von Branches finden Sie unter „Arbeiten mit projektspezifischen Branches und Tags“.

• Sobald bei der Entwicklung ein Meilenstein erreicht wird (für Releases, Funktionen, Sprints usw.), sollte ein Tag verwendet werden. Ein neuer Tag sollte erstellt werden, sobald die Funktion lieferbereit ist (Produktionsumgebung). Wenn für eine Version mit Tag Bugs behoben werden müssen, kann ausgehend vom Tag ein Branch erstellt und der Fix dann in den „Haupt“-Branch aufgenommen werden.

• Es wird empfohlen, Patches als Nebenversionen und komplette Releases als Hauptversionen zu definieren.

• Bei der Arbeit in einem bestimmten Branch, sollte das Projekt über die Allowlist-Option für GIT-Branches mit Bezug auf diesen Branch gefiltert werden, um die Beanspruchung der Speicherressourcen einzugrenzen und die Leistung zu verbessern.