Stash 2.4: Repository-Forks, persönliche Repos, Berechtigungen auf Repository-Ebene

Durch seine distributierte Natur bietet Git Entwicklungsteams eine Fülle von Auswahlmöglichkeiten, wie sie in Projekten zusammenarbeiten. Teams, die auf Git umsteigen, brauchen Flexibilität, um bestmöglich mit Code in einer verteilten Enterprise-Umgebung arbeiten zu können. Hier haben sich Praktiken auf der Grundlage von Branch- und Fork-basierten Workflows etabliert, was wiederum Debatten darüber entfacht hat, wie sich diese am besten in großen Unternehmen nutzen lassen.

Nun ist das Git-Repository-Management-Tool Stash von Atlassian in der Version 2.4 ausgeliefert worden, das die Wahlmöglichkeiten und die Flexibilität bietet, die Teams brauchen, um ihre Git-Entwicklungs-Workflows zu handhaben. Die neuen Schlüsselfunktionen stellen wir Ihnen vor.

Kollaborative Git-Entwicklung mit Forks

Einen Fork durchzuführen, bedeutet einfach, auf der Server-Seite einen Klon der Repository inklusive ihrer bisherigen Historie zu erstellen. Forks in Stash bieten Entwicklern einen Workflow, um Code zu einer Repository beizutragen, für die sie keinen Schreibzugriff haben, und bringen eine neue Ebene der Kontrolle in den Entwicklungsprozess.

Mit dem Klick auf den Fork-Button einer Repository wird eine Kopie erstellt, die von Stash getrackt und unabhängig von der Original-Repository modifiziert wird, um diese vor ungewollten Änderungen oder Fehlern zu schützen. Eine Repository lässt sich in jedes andere Stash-Projekt forken, für das Admin-Zugriff besteht. Zudem sind persönliche Forks möglich, für die anderen Entwicklern dann Zugriffsrechte erteilt werden können. Pull Requests erlauben das einfache Mergen von Änderungen zwischen Forks.

Stash_42_Forks

Warum Forks?

  • Projektpartner: Externe Entwickler können in ein Projekt integriert werden, während nur das Kernteam Schreibrechte für die Repository hat. Projektpartner können eine Repository einfach forken und Änderungen via Pull-Requests einbringen.
  • Große Teams: Wenn hunderte Entwickler an derselben Repository arbeiten, kann das Volumen an Branches und sonstiger Aktivität in der Repository schnell zu richtigem Lärm führen. Forks bieten Teams eine Möglichkeit, separat zu arbeiten, während neue Änderungen aus der Kern-Repository kontinuierlich in des Projekt synchronisiert werden.
  • Experimente: Ob man an ShipIt teilnimmt, ein Projekt einstellt oder einfach an Feature-Prototypen arbeitet – das Experimentieren mit Forks bietet Entwicklern die Option, Änderungen zu entsorgen, ohne dass die Haupt-Repository vermüllt wird, wenn das Experiment ins Leere führt.

Stash_42_Forks_Clones

Änderungen via Pull-Requests beisteuern

Das Schöne an Forks ist, dass Änderungen an der Fork-Repository die Haupt-Codelinie nicht tangieren. Sobald ein Fork soweit ist, kann er per dann Pull-Request in die Original-Repository gemergt werden. Stash und Pull-Requests erleichtern den Merging-Prozess solcher Änderungen. Das gibt anderen Entwicklern die Möglichkeit, Änderungen zu reviewen und zu diskutieren, ehe sie Teil der Haupt-Codebasis werden. Von dort aus lassen sich die Änderungen auf Basis der Pull-Request-Einstellungen und Branch-Berechtigungen in die Original-Repository mergen.

Stash 42 Pull-Requests

Persönliche Repositories

Stash 2.4 bietet die Option, eine persönliche Repository zu erstellen, die nicht mit anderen Projekten zusammenhängt. Dadurch haben Entwickler die Freiheit, Innovationen voranzutreiben und ihre privaten Arbeitsschnipsel abzulegen, Bugfixes zu einem Projekt beizusteuern, an dem sie sonst nicht beteiligt sind, oder Features zu einer verbreiteten Komponente hinzuzufügen, die von einer kleinen Gruppe im Unternehmen gewartet wird. Diese persönlichen Repositories können beliebig offen (oder geschützt) sein. Mithilfe der Repository-Berechtigungen können Entwickler dann mit anderen Nutzern und Gruppen zusammenarbeiten, sobald sie soweit sind.

Die Einführung persönlicher Repositories und Forks hat es erforderlich gemacht, eine einfach erreichbare Stelle zu schaffen, an der diese Informationen zusammengefasst sind. Also hat das Stash-Team auch die Nutzerprofile aufpoliert.

Stash_42_perönliche_Repositories

Repository-Berechtigungen

Berechtigungen in Stash sollen dafür sorgen, dass Code sicher ist, und Entwicklern die Gewissheit geben, dass die richtigen Kollegen den richtigen Zugriff haben. In frühen Stash-Versionen hat es zwei Kategorien von Berechtigungen gegeben: Globale Berechtigungen und Projekt-Berechtigungen, um den Lese- und Schreibzugriff zu kontrollieren.

Mit Stash 2.0 wurde das Rechtekonzept dann um die Branch-Permissions erweitert. Stash 2.4 bietet nun eine noch granularere Zugangskontrolle: Berechtigungen auf Repository-Ebene.

Stash_42_Repository-Berechtigungen

Administratoren können Projekte so weit öffnen oder schützen, wie sie wollen. Insbesondere können sie Zugriff auf individuelle Repositories in einem Projekt gewähren, ohne dass der User auf das gesamte Projekt zugreifen kann. Es gibt mehrere Szenarien, in denen dies von Vorteil ist:

  • Externe Entwickler: Wenn man mit externen Entwicklern arbeitet, ist es oft nicht gewünscht, dass diese großflächigen Zugriff auf die Repositories haben. Stash erlaubt es, dem Kernteam Zugang zu allen Repositories zu gewähren, während Externe nur auf ausgewählte Repos zugreifen können.
  • Zugang erweitern: Viele Teams beschränken die Schreibrechte auf eine kleine Gruppe von Entwicklern für spezifische Projekte. Um die Zusammenarbeit zu fördern, können Leserechte auf weitere Teile des Unternehmens ausgerollt werden, sodass auch Leute, die nicht zum Kernteam gehören, Forks durchführen und Beiträge leisten können.
  • Administration delegieren: Administratoren können signifikant Zeit einsparen, indem sie vertrauenswürdigen Teammitgliedern den Administrationszugriff für eine Repository in die Hände geben.

Fazit

Stash ist gerade mal ein Jahr am Markt - und Version 2.4 ist bereits das neunte Major-Release. Die Weiterentwicklung erfolgt in Riesenschritten, und dementsprechend ausgereift ist Atlassians Git-Repository-Management-Tool inzwischen. Stash lässt Entwicklern und Entwicklungsteams die Wahl, wie sie mit distributiertem Code arbeiten, und diese Flexibilität ist eine gute Grundlage, um effizienter zu entwickeln und schneller auszuliefern.

Stash testen und lizenzieren? Wir sind Ihr Partner!

Interessieren Sie sich für Stash und/oder andere Entwickler-Tools von Atlassian? Möchten Sie mehr erfahren? Wir sind offizieller Vertriebspartner von Atlassian und Atlassian Platinum Expert und unterstützen Sie gerne bei der Evaluierung und Lizenzierung. Und wenn Sie Atlassian-Lizenzen bei //SEIBERT/MEDIA kaufen, gewähren wir Ihnen einen Rabatt in Höhe von 10% der Lizenzkosten in Form von Beratungsleistungen. Bitte sprechen Sie uns einfach an.

Weiterführende Informationen

Git und Stash in der Software-Entwicklung: Eine Einführung
Stash in der Praxis
Stash Enterprise: Git-Repository-Management in großen Unternehmen
//SEIBERT/MEDIA ist Atlassian Platinum Expert
So funktioniert die Lizenzierung von Atlassian-Produkten

ACHTUNG!
Unsere Blogartikel sind echte Zeitdokumente und werden nicht aktualisiert. Es ist daher möglich, dass die Inhalte veraltet sind und nicht mehr dem neuesten Stand entsprechen. Dafür übernehmen wir keinerlei Gewähr.

Schreibe einen Kommentar