Wochentags, 9:45 Uhr im datenwerk: Im täglichen Kanban-Meeting fallen auch einmal Sätze wie "Ich habe gerade noch commited" oder "Da musst du noch pushen". Wenn sich das EntwicklerInnen-Team untereinander austauscht, verstehe ich nicht immer alles. Aber seit mir Melanie erklärt hat, was es mit Master, Working Copy, Branch, Fork, push, pull, merge und commit auf sich hat, ist es einfacher, der Sprache der EntwicklerInnen in der Softwareentwicklung zu folgen.
Hier ist meine Zusammenfassung, wie das mit der Versionskontrolle funktioniert:
Mehrspuriges Grundsetup für Developers
Bei Online-Projekten gibt es meist mehrere Ebenen:
- Da ist einerseits die Live-Umgebung. Bei einer Website handelt es sich dabei um jene Version, die für alle sichtbar und nutzbar ist.
- Dann gibt's die Dev- bzw. Test-Umgebung. Es ist eine Kopie der Website oder Software, in der man Änderungen (technisch oder redaktionell) vorab testen kann. Die Einstellungen sind so, dass Suchmaschinen diese Inhalte nicht durchsuchen können. Oft ist der Zugriff auch mit Passwörtern oder auf IP-Adressen beschränkt.
- Der Code für beiden Umgebungen wird in einem Versionskontrollsystem verwaltet. Auf Basis des dezentralen Versionskontrollsystems GIT gibt es mehrere Plattformen, wo EntwickerInnen ihren Code in sog. Repositories verwalten können – die bekanntesten sind GitHub und Bitbucket. Wer den Code bearbeiten darf, ist durch Zugriffsrechte definiert und oft auf wenige UserInnen beschränkt.
- JedeR EntwicklerIn hat außerdem eine lokale Kopie des Repository auf dem eigenen Computer – die Working Copy. In dieser programmiert er/sie und entwickelt neue Features.
Softwareentwicklung am eigenen Computer
JedeR EntwicklerIn holt per checkout eine lokale Kopie des Codes auf den Computer. Diese Working Copy kann eine Kopie des Masters – des ersten Branches – oder eines anderen Branches sein. Ein Branch beinhaltet ein Feature, mit dem der Master-Branch erweitert wird. Diese Vorgehensweise hat den Vorteil, dass zwei oder mehrere EntwicklerInnen parallel an unterschiedlichen Branches (Ästen) in einem Projekt arbeiten und damit Features parallel (weiter)entwickelt werden können.
In der Working Copy passieren verschiedene Schritte der Softwareentwicklung dann im Kleinen:
- Code wird manuell geändert und die Änderung in den Files laufend gespeichert.
- Möchte der/die EntwicklerIn die Änderungen so abspeichern, dass später auf diesen Stand zurückgedreht werden kann, wird ein Commit durchgeführt. Damit wird ein neuer Eintrag mit Zeitstempel und Notiz (der s.g. Commit-Message) im Log (Änderungsprotokoll) der Versionskontrolle erstellt. Das ist dann meist eine Stufe, auf die es sich lohnt zurückkehren zu wollen: Ein Bugfix ist erledigt oder ein stabiler Zustand in einer Feature-Entwicklung ist erreicht. Dieser Prozess passiert in einer Git-Versionskontrolle immer auf dem eigenen Computer, auch wenn der Begriff "commit" etwas anderes suggeriert. Das hat vielleicht damit zu tun, dass bei SVN (Subversion) ein "commit" immer gleich an den Server geht. Der technische Unterschied liegt daran, dass die Versionskontrolle zentralisiert oder verteilt erfolgen kann.
- Wie kommen die Änderungen nun zurück zum Server? Ganz klar: mit einem Push. Aber der Reihe nach ...
Beim Master läuft alles zusammen
Ist der Code am eigenen Computer lauffähig, geht es darum, die entwickelten Features oder Bugfixes wieder mit allen im Dev-Team zu teilen. Dazu wird in einem ersten Schritt ein Pull vom Server durchgeführt. D.h. das Programm vergleicht die aktuellste Version des ausgewählten Branches (z.B. Master) aus dem Remote-Repository (am Server) mit den Weiterentwicklungen in der Working Copy. Konflikte, die sich durch unterschiedliche Versionen von Dateien ergeben, behebt das Programm dabei oft automatisch. Manchmal muss eine manuelle Auswahl getroffen werden, indem man zwei Versionen einer Datei vergleicht und jeweils entscheidet, welche Code-Zeilen von wo übernommen werden sollen.
Sind alle Probleme behoben, kann man die Feature-Entwicklung, also die Änderungen der lokale Working Copy, ins Repository zurückpushen. Alle EntwicklerInnen haben damit Zugriff auf den neu geschriebenen Code. Das Pushen ins Repository verändert dabei alle geänderten Dokumente und speichert auch die vorangegangenen Versionen der Files.
Wurde ein Feature in einem neuen Branch weiterentwickelt, besteht dieser nach dem Push nicht nur in der Working Copy, sondern auch im Repository. Ist die Feature-Entwicklung abgeschlossen und das neue Feature Teil des Gesamtprojekts, wird der Feature-Branch in den Master gemerged. Danach ist die Verästelung wieder Teil des Hauptstammes. Damit das Repository übersichtlich bleibt, nicht auf das Löschen des Feature-Branches nach dem Merge vergessen.
Übrigens: Viele EntwicklerInnen verwenden für den gesamten Prozess des Zurückspielens den Begriff "commit". Das ist zwar inhaltlich nicht ganz korrekt, hat sich aber scheinbar in der Dev-Umgangssprache so eingebürgert.
Und die Gabeln in der Softwareentwicklung?
Forks (Gabeln) kommen bei datenwerk in der Softwareentwicklung selten zum Einsatz. Beim Forken nimmt man bestehenden Code und setzt damit ein paralleles System auf. Der große Vorteil dabei ist, dass einE EntwicklerIn zum Forken nur Leserechte auf den Code braucht. Daher kommt dieser Ansatz der Versionskontrolle häufig bei öffentlichen Repositories auf GitHub zum Einsatz: Wenn einE EntwicklerIn einen Bug im Code eines anderen entdeckt, kann er/sie das Repository kopieren (forken), den Bug beheben und dann dem/der ursprünglichen EntwicklerIn mit Schreibrechten im ursprünglichen Code einen pull-Request schicken. Mit diesem pull-Request geht quasi die Frage einher: "Magst du nicht meinen Bugfix zu dir übernehmen?"
Ich hoffe, ich konnte mit dieser Zusammenfassung auch bei dir einige Unklarheiten beseitigen. Kennst du Begriffe aus der Softwareentwicklung und Social-Media-Welt, die einer Erklärung bedürfen? Am besten schreibst du einen Kommentar unter diesen Blogbeitrag, ich versuch's dann zu erklären.