Der Wechsel von einem zentralisierten Versionskontrollsystem zu Git verändert die Arbeitsweise deines Softwareentwicklerteams. Wenn in deinem Unternehmen erfolgskritische Anwendungen auf diese Software angewiesen sind, wirkt sich eine Änderung des Entwicklungs-Workflows auf das gesamte Unternehmen aus.

Organisationsentwicklung

In diesem Artikel zeigen wir dir, welche Vorteile Git den einzelnen Unternehmensbereichen bietet – vom Entwickler- bis zum Marketingteam profitieren alle. Anschließend sollte dir klar sein, dass Git nicht nur für die agile Softwareentwicklung, sondern allgemein für agile Geschäftsprozesse gedacht ist.

Git für Entwickler

Feature Branch Workflow

Einer der größten Vorteile von Git ist die Branching-Funktion. Im Gegensatz zu zentralisierten Versionskontrollsystemen sind Git-Branches günstig und einfach zu mergen. Dies vereinfacht den bei so vielen Git-Benutzern beliebten Feature Branch Workflow.

Feature Branch Workflow

Feature Branches bieten eine isolierte Umgebung für jede Änderung an deiner Codebasis. Wenn ein Entwickler mit der Arbeit an einer Aufgabe beginnt – egal, wie klein oder groß – erstellt er einen neuen Branch. Dies sorgt dafür, dass der Master Branch immer nur Code in Produktionsqualität enthält.

Die Nutzung von Feature Branches ist nicht nur zuverlässiger als das direkte Bearbeiten von Produktionscode, sie bietet auch organisatorische Vorteile. Mit ihnen kannst du Entwicklungsaufgaben in genauso feine Teilaufgaben aufbrechen, wie in deinem Agile-Backlog. Wenn du beispielsweise eine Richtlinie implementieren möchtest, die festlegt, dass jedem Jira-Ticket ein eigener Feature Branch zugeteilt wird.

Verteilte Entwicklung

In SVN erhält jeder Entwickler eine Arbeitskopie, die auf ein einziges zentrales Repository zurückgeht. Git ist dagegen ein verteiltes Versionskontrollsystem. Statt einer Arbeitskopie erhält jeder Entwickler sein eigenes lokales Repository mitsamt einem vollständigen Commit-Verlauf.

Verteilte Entwicklung

Der vollständige lokale Verlauf macht Git schnell, da du keine Netzwerkverbindung benötigst, um einen Commit zu erstellen, ältere Dateiversionen anzusehen oder Diffs zwischen Commit auszuführen.

Verteilte Entwicklung erleichtert außerdem die Skalierung deines Entwicklungsteams. Wenn in SVN jemand den Produktions-Branch beschädigt, können die anderen Entwickler ihre Änderungen erst wieder einchecken, nachdem der Schaden behoben wurde. Bei Git gibt es keine solchen Blockaden. Alle Entwickler können in ihren eigenen lokalen Repositorys wie gewohnt weiterarbeiten.

Darüber hinaus entsteht durch verteilte Entwicklung ähnlich wie mit Feature Branches eine zuverlässigere Umgebung. Selbst wenn ein Entwickler sein eigenes Repository komplett zerstört, kann er einfach das Repository eines Kollegen klonen und neu anfangen.

Pull Requests

Viele Quellcodemanagement-Tools wie Bitbucket erweitern die Kernfunktionalität von Git mit Pull-Requests. Ein Pull-Request ist eine Möglichkeit, einen anderen Entwickler darum zu bitten, einen Merge deiner Branches in sein Repository durchzuführen. Auf diese Weise können nicht nur die Projektleiter Änderungen leichter verfolgen, sondern die Entwickler können auch über ihre Arbeit diskutieren, bevor sie die Ergebnisse in die übrige Codebasis integrieren.

Pull-Requests

Da sie im Prinzip ein an einen Feature Branch angehängter Kommentar-Thread sind, sind Pull-Requests extrem vielseitig. Wenn ein Entwickler mit einem schwierigen Problem nicht weiterkommt, kann er einen Pull-Request eröffnen, um das übrige Team um Hilfe zu bitten. Oder noch unerfahrene Entwickler können Pull-Requests als einen formalen Code-Review nutzen, um sicherzustellen, dass sie nicht das gesamte Projekt zerstören.

Community

In weiten Kreisen ist Git zum vorausgesetzten Versionskontrollsystem für neue Projekte geworden. Wenn dein Team Git nutzt, ist die Wahrscheinlichkeit groß, dass neu eingestellte Mitarbeiter euren Workflow bereits kennen, da sie mit der verteilten Entwicklung vertraut sind.

Git-Community

Darüber hinaus ist Git bei Open-Source-Projekten sehr beliebt. Dies bedeutet, dass mühelos Bibliotheken von Drittparteien genutzt werden und andere zum Forken ihres eigenen Open-Source-Codes ermutigt werden können.

Schnellerer Release-Zyklus

Das Ziel von Feature Branches, verteilter Entwicklung, Pull-Requests und einer stabilen Community ist letztendlich ein schnellerer Release-Zyklus. Diese Funktionen kommen einem Agile Workflow entgegen, bei dem die Entwickler ermutigt werden, kleinere Änderungen häufiger zu teilen. Im Gegenzug durchlaufen Änderungen die Deployment Pipeline schneller als die bei zentralisierten Versionskontrollsystemen üblichen monolithischen Releases.

Schnellerer Release-Zyklus

Wie du dir denken kannst, funktioniert Git sehr gut in Umgebungen, in denen Continuous Integration und Continuous Delivery praktiziert wird. Git-Hooks ermöglichen das Ausführen von Skripten, wenn bestimmte Ereignisse in einem Repository auftreten, sodass du das Deployment nach Belieben automatisieren kannst. Du kannst sogar Builds laufen lassen oder Code von bestimmten Branches an verschiedene Server ausrollen.

Es ist z. B. eine gute Idee, Git so zu konfigurieren, dass der neueste Commit vom Develop Branch an einen Testserver deployed wird, sobald jemand einen Pull-Request in ihn mergt. Die Kombination einer derartigen Build-Automatisierung mit gegenseitigem Review sorgt dafür, dass du höchstes Vertrauen in deinen Code setzen kannst, wenn dieser von der Entwicklung in die Staging-Umgebung und die Produktion überführt wird.

Git für das Marketing

Wie wirkt sich der Wechsel zu Git auf die Marketingaktivitäten deines Unternehmens aus? Nehmen wir an, in deinem Entwicklungsteam steht in den nächsten Wochen der Abschluss drei separater Änderungen an:

  • Das gesamte Team befindet sich auf der Zielgeraden zur Fertigstellung eines bahnbrechenden Features, an dem es die letzten sechs Monate gearbeitet hat.
  • Mary implementiert ein kleineres, nicht zugehöriges Feature, das nur Bestandskunden betrifft.
  • Rick nimmt dringend benötigte Updates an der Benutzeroberfläche vor.

In einem herkömmlichen Entwicklungs-Workflow auf Basis eines zentralisierten Versionskontrollsystems würden diese Änderungen alle in einem einzigen Release zusammengefasst. Das Marketingteam macht nur eine Ankündigung, die den Fokus hauptsächlich auf das bahnbrechende Feature setzt. Dabei gehen die beiden anderen beiden Updates nahezu vollkommen unter und ihr Potenzial wird verschenkt.

Der von Git ermöglichte kürzere Entwicklungszyklus erleichtert die Aufteilung in separate Releases. Hierdurch hat das Marketingteam mehr Gesprächsstoff für häufigere Mitteilungen. Im obigen Szenario kann das Marketingteam drei Kampagnen erarbeiten, die jeweils ein Feature behandeln, und dabei zielgerichtet auf das betroffene Marktsegment eingehen.

Git für das Marketing

Beispielsweise kann eine große PR-Aktion für das bahnbrechende Feature, ein offizieller Blogpost und kurzer Newsletter für Marys Feature und ein Gastbeitrag für externe Designblogs zur UX-Theorie, die Ricks Updates zugrunde liegt, vorbereitet werden. Alle diese Aktivitäten können synchron auf die separaten Releases ausgerichtet werden.

Git für das Produktmanagement

Die Vorteile von Git für das Produktmanagement sind im Prinzip dieselben wie für das Marketing. Häufigere Releases führen zu häufigerem Kundenfeedback und schnelleren Updates als Reaktion auf dieses Feedback. Anstatt auf den in acht Wochen angesetzten nächsten Release zu warten, kannst du dem Kunden eine Lösung bieten, so schnell deine Entwickler den Code schreiben können.

Prioritätsmanagement im Git-Workflow

Mit dem Feature Branch Workflow bist du auch bei wechselnden Prioritäten flexibel. Wenn du beispielsweise in einem Release-Zyklus auf halber Strecke ein Feature aufschieben möchtest, um ein anderes zeitkritisches vorzuziehen, ist dies kein Problem. Das ursprüngliche Feature wartet auf seinem eigenen Branch bis die Entwickler wieder Zeit haben, daran weiter zu arbeiten.

Diese Funktionalität erleichtert auch das Management von Innovationsprojekten, Betatests und schnellen Prototypen als unabhängige Codebasen.

Git für Designer

Feature Branch sind hervorragend dazu geeignet, schnelle Prototypen zu erstellen. Egal, ob deine UX/UI-Designer einen völlig neuen Benutzer-Workflow implementieren oder nur ein paar Symbole ersetzen möchten, ein neuer Branch stellt eine Sandbox-Umgebung bereit, in der sie sich frei ausprobieren können. Auf diese Weise sehen die Designer ihre Änderungen in einer echten Arbeitskopie des Produkts, ohne dabei die Beeinträchtigung bestehender Funktionen zu riskieren.

Nicht destruktive Versionierung in Git

Eine solche Einkapselung von Änderungen an der Benutzeroberfläche erleichtert die Präsentation von Updates anderen Stakeholdern gegenüber. Wenn z. B. der Entwicklungsleiter sehen möchte, woran das Designteam gearbeitet hat, muss er nur den entsprechenden Branch auschecken.

Pull-Requests gehen hier einen Schritt weiter und bieten einen formalen Ort für interessierte Parteien, über die neue Oberfläche zu diskutieren. Die Designer können die nötigen Änderungen vornehmen und die daraus resultierenden Commits werden im Pull-Request angezeigt. Auf diese Weise werden alle aufgefordert, sich am Iterationsprozess zu beteiligen.

Das vielleicht Beste am Erstellen von Prototypen auf separaten Branches ist, dass es ebenso einfach ist, die Änderungen in die Produktionsumgebung zu mergen wie sie zu verwerfen. Es gibt keinerlei Druck, eher zu einer der beiden Optionen zu tendieren. So werden Designer und UI-Entwickler zum Experimentieren angeregt und gleichzeitig sichergestellt, dass nur die besten Ideen den Weg bis zum Kunden finden.

Git für den Kundensupport

Der Kundensupport sieht bei Updates oft andere Schwerpunkte als Produktmanager. Wenn ein Kunde sich an den Support wendet, hat er in der Regel ein Problem. Sollte dieses Problem von der Software deines Unternehmens verursacht werden, muss sobald wie möglich eine Fehlerkorrektur ausgeliefert werden.

Der optimierte Entwicklungszyklus von Git sorgt dafür, dass Fehlerkorrekturen nicht erst bis zum nächsten monolithischen Release aufgeschoben werden. Ein Entwickler kann einen Patch für das Problem erstellen und diesen direkt in die Produktion pushen. Schnellere Korrekturen führen zu zufriedeneren Kunden und weniger Supporttickets immer wieder zum gleichen Problem. Dein Kundensupportteam muss Anfragen nicht mehr mit Antworten abspeisen wie "Tut uns leid, wir kümmern uns darum", sondern kann antworten: "Das haben wir schon behoben!".

Git für die Personalabteilung

In gewissem Maße bestimmt dein Softwareentwicklungs-Workflow, welche Mitarbeiter du einstellst. Es ist immer sinnvoll, Entwickler einzustellen, die mit deinen Technologien und Workflows vertraut sind, aber die Verwendung von Git bietet noch andere Vorteile.

Die Bewerber fühlen sich besonders von Unternehmen angezogen, die Karrieremöglichkeiten bieten, und Git-Kenntnisse sind für jeden Programmierer äußerst nützlich, egal ob in großen oder kleinen Abteilungen. Wenn du dich für Git als Versionskontrollsystem entscheidest, ziehst du zukunftsorientierte Entwickler an.

Git für alle, die ein Budget verwalten

Bei Git ist Effizienz zentral. Mit Git vergeuden die Entwickler ihre Zeit weder mit dem Weiterleiten von Commits über eine Netzwerkverbindung noch mit der Integration von Änderungen in ein zentralisiertes Versionskontrollsystem. Selbst noch unerfahrene Entwickler werden besser eingesetzt, da sie in einer sicheren Umgebung arbeiten können. All dies wirkt sich positiv auf die Bilanz deiner Entwicklungsabteilung aus.

Git und das verteilte Team

Aber vergiss nicht, dass diese Effizienz auch über dein Entwicklerteam hinausgeht. Im Marketingteam wird keine Energie für unpopuläre Features verschwendet. Designer testen neue Oberflächen ohne viel Aufwand im tatsächlichen Produkt. Du reagierst umgehend auf Kundenbeschwerden.

Bei Agile geht es darum, so schnell wie möglich herauszufinden, was funktioniert, erfolgreiche Bemühungen zu intensivieren und weniger erfolgreiche Aktivitäten zu beenden. Git dient als Multiplikator all deiner Unternehmensaktivitäten, da es sicherstellt, dass alle Abteilungen mit maximaler Effizienz arbeiten.

Du möchtest mit Git arbeiten?

Sieh dir dieses interaktive Tutorial an.

Jetzt loslegen