Mit dem neuen Update halten Git-Forks im TFS 2018 Einzug. Egal ob es der Student oder der Kollege aus einer anderen Abteilung ist, welcher eine neue Funktion implementieren möchte und deshalb Zugriff auf mein Repository benötigt. Mögliche Anwendungsfälle für Git-Forks innerhalb von der TFS-Umgebung gibt es reichlich.
Ich, als Besitzer eines Repository möchte nicht, dass Personen, welche nur einen temporären Zugriff auf mein Repository benötigen, schreibend auf mein Repository einwirken können. Ein Grund dafür ist die erhöhte Administration dieser Benutzer. Zugriff geben und dann wieder nehmen, wenn die Zeit abgelaufen ist, erhöht den Administrationsaufwand.
Eine Lösung des Problems sind Git-Forks. Damit kann ich Personen, welche nur Leserechte auf mein Repository besitzen, an meinem Projekt mitwirken lassen. Jede Person, welche einen Fork erstellen möchte, muss das Recht besitzen Repositories im TFS anzulegen und benötigt Leserecht auf das gewünschte Projekt. Über einen Pull Request kann der Besitzer des Repositories die Änderungen aus dem Git-Fork übernommen werden.
Dadurch bleibt mein Repository übersichtlich und ich genieße trotzdem den Vorzug einer offenen Community innerhalb ihrer TFS Umgebung. Außerdem wird die Administration erleichtert.
Beispiel:
Im Folgenden zeige ich, wie ein Fork angelegt wird und wie Änderungen über einen Pull Request an das ursprüngliche Repository zurückgegeben werden.
Voraussetzung:
Der Benutzer muss mindestens das Recht besitzen sich eigene Repository in seinem Team Projekt (Studenten) anzulegen (Abbildung 1) und lesend auf das gewünschte Repository (CMMI) zugreifen zu können (Abbildung 2).
Abbildung 1: Rechte, auf das „Ziel“ Repository im eigenem Team Projekt
Abbildung 2: Ausschließlich Leserecht auf das „orginal“ Repository.
Über die Schaltfläche „Fork“ im Hub „Code“ wird ein neuer Fork erstellt.
Im folgenden Popup muss jetzt ein Name für das neue Repository (HelloWorldNewFork) und das Projekt (Studenten) ausgewählt werden.
Abbildung 4+5: Anlegen eines neuen Fork.
Wird das Team Projekt nicht geändert, so bekommt der Benutzer den Fehler, dass er keine ausreichenden Rechte im ausgewählten Projekt hat.
Nachdem ein neuer Name für das Repository festgelegt und ein Projekt zugewiesen werden konnte, kann damit wie gewohnt gearbeitet werden. Jetzt befindet sich eine Kopie des „orginal“ Repository im Projekt des Benutzers.
Abbildung 6: Neues Repository
Über einen Pull Request werden die Änderung wieder in das Team Projekt CMMI übernommen.
Abbildung 7 + 8: Pull Request nachdem Commit erstellen.
Der Pull Request verhält sich, wie es der Benutzer vom TFS bereits gewohnt ist.
Fazit
Mit Git-Forks genießt man den Vorzug einer offenen Community innerhalb einer geschlossenen TFS Umgebung.