© piick/Shutterstock.com
Branching-Modelle und Workflows für SCM-Systeme

Einfach den richtigen Flow finden


Source-Control-Management-Systeme (SCM) gehören zur Standardausrüstung eines Softwareentwicklers. Trotz der täglichen Verwendung dieser Werkzeuge gibt es viele hilfreiche Techniken, die weitgehend unbekannt sind. Es gibt eine große Anzahl von SCM-Werkzeugen [1]. Dieser Artikel bezieht sich auf das frei verfügbare, verteilte SCM-Tool Git, das wegen seiner starken Verbreitung eine sehr hohe Relevanz besitzt. Viele der vorgestellten Praktiken lassen sich mit wenigen Anpassungen auch auf andere Lösungen wie beispielsweise Apache Subversion anwenden.

Im Umgang mit SCM-Werkzeugen ist es essenziell zu wissen, worin deren Grenzen liegen. Diese Systeme wurden entwickelt, um Änderungen in ASCII-Textdateien zu protokollieren. Ein SCM speichert der Effizienz wegen für jede Datei, die unter Konfigurationsmanagement gestellt wurde, lediglich die Änderung zur Vorgängerversion, ein sogenanntes Delta. Daraus ergibt sich als interne Repräsentation eine Baumstruktur für jede Datei. Das hat aber auch zur Folge, dass bei Binärdateien, wie sie von Office-Suiten erzeugt werden, kein Delta bestimmt werden kann, sodass SCM bei jeder Änderung einer solchen Datei eine vollständig neue Version abspeichert. Das führt dazu, dass das Repository sehr schnell eine beachtliche Größe auf der Festplatte beansprucht. Die Übertragungszeit von Dateien zwischen dem Repository und einer lokalen Arbeitskopie ist direkt abhängig von der Größe des gesamten Repositorys, auch wenn nur eine kleine Untermenge der gespeicherten Dateien übertragen wird. Der Grund ist, dass das SCM bei jeder Abfrage den gesamten Baum des Repositorys erzeugt, um dann die verlangten Inhalte bereitstellen zu können. So lässt sich sehr schnell einsehen, dass die Größe des Source Repositorys aus Sicht der Performance möglichst gering gehalten werden sollte. Das erreicht man mit wenig Aufwand, indem man einige Regeln befolgt.

Binäre Artefakte wie externe Bibliotheken werden in speziellen Repository-Servern wie Sonatype Nexus oder Artifactory verwaltet und gehören aus diesem Grund nicht ins Git. Inhalte wie Präsentationen, Excel-Tabellen oder Word-Dokumente werden am besten auf einem zentralen Netzwerkspeicher aufbewahrt. In sogenannten Dokumentenservern wie Microsofts SharePoint sind Dokumente für kollaborative Anforderungen gut aufbewahrt. Man könnte der Idee nachgehen, mehrere Projekte in einem gemeinsamen Repository zu verwalten. Doch davon sollte man aus mehreren Gründen Abstand nehmen. Sicher ist eine solche Lösung sehr k...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang