Git Flow mit Visual Studio Team Services

Git Flow

Der Git Flow - früher ein Plugin, heute Bestandteil von Git - ist ein bewährter Workflow, wie mit Hilfe von Branches zusammen im Team an einer Software gearbeitet wird. Dies wird auch bei der Initialisierung eines git-Repositories abgefragt:

1# Initialisierung eines git Repositories
2git init
3
4# Initialisierung von git flow:
5git flow init

Anschließend wird man nach den entsprechenden Branches gefragt:

1Branch name for production releases: [master]
2Branch name for "next release" development: [develop]
3How to name your supporting branch prefixes?
4Feature branches? [feature/]
5Release branches? [release/]
6Hotfix branches? [hotfix/]

Die Konkurrenz von Visual Studio Team Services

Bei Open Source Projekten ist der Git-Flow der Quasi-Standard. Kein Repository lässt zu, dass unbeteiligte direkt auf das Quell-Repository/den jeweiligen Branch committen dürfen. Der übliche Weg ist über einen Pull Request.

Plattformen wie GitHub, BitBucket und Co unterstützen den Git Flow von Haus aus. Ein Kopfdruck und Git-Flow ist eingerichtet.

Visual Studio Team Services

Bei VSTS ist dem leider nicht so.

Technisch gesehen ist der Git Flow ein Schutz, dass nicht - ohne entsprechende Berechtigung - auf einen Branch committen werden darf. Genau dies muss in VSTS von Hand eingerichtet werden. Dazu gibt es in der Branch-Verwaltung des Repositories die Funktion der Branch Policies.

Anschließend muss folgendes aktiviert werden:

Jetzt kann nicht mehr direkt auf den - in meinem Beispiel - master-Branch committed werden, sondern nur nich mit Hilfe eines Pull-Requests zB. aus einem feature-Branch heraus. Ebenso muss eine Build-Definition erfolgreich sein, bevor ein anschließender Merge von feature auf master möglich ist.