Typologie der Git User in Entwicklerteams

Der Einsatz von Git, einer Software zur verteilten Versionsverwaltung von Dateien in Entwicklerteams, wird immer beliebter.

Ein großer Vorteil liegt darin, dass die einzelnen Developer gemeinsam an einem Projekt arbeiten können, selbst wenn Sie nicht mit dem gemeinsamen Netzwerk verbunden sind. Das funktioniert deswegen, weil mit Git jedes Teammitglied auf seinem lokalen Rechner seine eigene Kopie des Git-Repositories (darunter versteht man den Speicherort wo die Daten abgelegt sind) erhält.

Git User in Entwicklerteams - jeder ist anders

Änderungen am Code werden also immer erst in das lokale Repository des Entwicklers oder Webdesigners committet statt in das zentrale. Damit die anderen Teammitglieder die Änderungen mitbekommen, müssen diese vom lokalen Repository auf das öffentliche Git-Repository verschoben (committet) werden. Spätestens das ist dann der Moment, der im Taumel der Begeisterung oft der Stein des Anstoßes wird und ausschlaggebend dafür ist, das Git und dessen Nutzen in Frage gestellt wird. Denn nicht jedes Team-Mitglied hat die Angewohnheit seine Änderungen so zu committen, wie es eigentlich erforderlich wäre. Was weniger mit der Funktionalität von Git zu tun hat, sondern mehr damit, dass den einzelnen Mitgliedern der Sinn und Nutzen von Git noch nicht ganz klar ist und besser kommuniziert werden muss.

Schlechte Angewohnheiten

Aber wie überall im Leben gilt auch beim Einsatz von Git die Devise Gemeinsame Erlebnisse schweißen uns manchmal mit unmöglichen Menschen zusammen. Vor allem in Projektteams, die noch nicht lange mit Git arbeiten sind die folgenden drei Nutzertypen keine Seltenheit und erzeugen häufig Spannungen im Team, denen man längerfristig entgegen wirken muss.

Typ A: Der unaufmerksame Commiter

Daran erkennt man sie: Das sind Teammitglieder, die nicht wissen, was Sie da eigentlich committen und dann im Gruppenchat Sachen posten wie “Mist, jetzt hab ich aus Versehen ein paar zu Testzwecken privat abgelegte Fotos ins Verzeichnis mit hochgeladen.” Man erkennt sie an einem ruhelosen Blick und vorgetäuschtem Interesse das sie während der Einführungsveranstaltung in Git aufsetzen und meinen alles kapiert zu haben. Git-Anwender dieser Art sollten sich angewöhnen immer erst ein git diff zu verwenden. Mit diesem Befehl werden Änderungen zwischen Versionen, Version und Arbeitszweig, etc angezeigt. So wird diesen Anwendertypen bewusster gemacht, welche Aktualisierungen Sie mit ihrem git commit-Befehl eigentlich ins öffentliche Repository und somit ans restliche Team übermitteln.

Typ B: Der Gelegenheits-Commiter

Daran erkennt man sie: Noch häufiger vertreten als Typ A sind die Entwickler, die nur gelegentlich ein git commit ausführen. Sie haben oft einen schüchternen Blick, mit dem sie andere Team-Mitglieder mustern und arbeiten bevorzugt im stillen Kämmerlein mit möglichst wenige Außenkommunikation. Nicht selten commiten solche Mitglieder höchstens am Ende des Arbeitstages oder nur dann, wenn sie ihre Aufgabe als komplett abgeschlossen ansehen, oder mehrmals gebeten wurden Ihre Änderungen hochzuladen. Meist sind dann auch die Commit-Nachrichten wenig aufschlussreich und lauten beispielsweise einfach so: “Aufgabe abgeschlossen.” Die Gründe hierfür können vielfältig sein und reichen von Angst vor Kontrolle, Angst etwas falsch zu machen bis hin zu dem Glauben, dass man wichtigeres zu tun hat als seine Änderungen oft zu commiten. Gerade bei diesen Gelegenheits-Committern sind aussagekräftige Commit-Nachrichten wichtig. Weil wer weiß schon nach 3 Monaten noch, welche Aufgabe denn da abgeschlossen wurde? Gute commit-Messages sind kurz (weniger als 50 Zeichen) und Aussagekräftig und beziehen sich im Idealfall immer auf ein Ticket.

Typ C: Der selbstbewusste Merger

Merge Konflikte passieren häufiger als man denkt, vor allem je mehr Mitglieder in einem Projekt zusammen arbeiten. Das liegt vor allem auch darin, dass Entwickler Formatierungen ändern, Klassen verschieben, Code refaktorisieren, oder andere Dinge anpassen. Der selbstbewusste Merger hat damit kein Problem. Daran erkennt man sie: Sie wirken selbstbewusst, nicken während der Einführung oftmals zustimmend, fragen nicht ständig nach, sondern probieren gleich selbstsicher den entsprechenden Workflow aus. Sie machen einfach ein git pull, lösen den Merge Konflikt manuell und entscheiden nach eigenem Ermessen, was übernommen wird. Im schlimmsten Fall kommt es dazu, dass durch das manuelle Eingreifen Änderungen anderer Teilnehmer verloren gehen. Was dann oftmals für Unmut sorgt, vor allem wenn dies den anderen Team-Mitgliedern nicht gleich auffällt wird.

Das Arbeiten mit Git klappt nur dann relativ problemlos wenn man Regeln aufstellt, die von allen Mitgliedern beachtet werden.

• Befehle wie add, commit, push sollten häufig verwendet werden.
• Die Commit-Message muss aussagekräftig sein.
• Alle Veröffentlichungen und neue Features sollten immer mit einem Tag (Versionsnummer) versehen sein.

Git ist einfach zu erlernen

Es gibt mittlerweile viele Tutorials und Tools zum Erlernen von Git im Netz. Eine tolle Webseite ist beispielsweise Code School - Try Git, welche unter folgender URL zu finden ist https://try.github.io/levels/1/challenges/1. Auch die Git Hilfe ist mittlerweile sehr ausgereift und listet alle allgemein verwendeten Git-Kommandos auf, wenn man mal gerade nicht weiter weiß:

   add        stellt Dateiinhalte zur Eintragung bereit
   bisect     Findet über eine Binärsuche die Änderungen, die einen Fehler verursacht haben
   branch     Zeigt an, erstellt oder entfernt Zweige
   checkout   Checkt Zweige oder Pfade im Arbeitszweig aus
   clone      Klont ein Projektarchiv in einem neuen Verzeichnis
   commit     Trägt Änderungen in das Projektarchiv ein
   diff       Zeigt Änderungen zwischen Versionen, Version und Arbeitszweig, etc. an
   fetch      Lädt Objekte und Referenzen von einem anderen Projektarchiv herunter
   grep       Stellt Zeilen dar, die einem Muster entsprechen
   init       Create an empty Git repository or reinitialize an existing one
   log        Zeigt Versionshistorie an
   merge      Führt zwei oder mehr Entwicklungszweige zusammen
   mv         Verschiebt oder benennt eine Datei, ein Verzeichnis, oder eine symbolische Verknüpfung um
   pull       Fordert Objekte von einem externen Projektarchiv an und führt sie mit einem anderen Projektarchiv oder einem lokalen Zweig zusammen
   push       Aktualisiert externe Referenzen mitsamt den verbundenen Objekten
   rebase     Baut lokale Versionen auf einem aktuellerem externen Zweig neu auf
   reset      Setzt die aktuelle Zweigspitze (HEAD) zu einem spezifizierten Zustand zurück
   rm         Löscht Dateien im Arbeitszweig und von der Bereitstellung
   show       Zeigt verschiedene Arten von Objekten an
   status     Zeigt den Zustand des Arbeitszweiges an
   tag        Erzeugt, listet auf, löscht oder verifiziert ein mit GPG signiertes Markierungsobjekt

Auch wenn der Anfang mit Git zuerst schwierig erscheint wird bei der täglichen Arbeit damit jedem so nach und nach die Vorteile immer bewusster. Es ist also durchaus einen Versuch Wert sich besser in Git einzuarbeiten und seine schlechten Angewohnheiten mit der Zeit abzulegen.