02 Wie arbeite ich mit GitHub und der Versionierung?

Ein umfangreiches Projekt wie der GC Wizard – das zudem noch im Team gepflegt wird – lässt sich nicht mehr nur am heimischen PC beherrschen.

Dies wird mit einem Programmpaket zur Versionskontrolle deutlich vereinfacht. Die grundlegende Idee ist einfach:

  • Auf der Webseite von GitHub wird ein zentrales Ablagesystem – Repository – gepflegt, welches alle Dateien des Projektes enthält; in der Regel als Master bezeichnet.
  • Jeder Mitarbeiter erstellt auf GitHub einen Klon – origin -, der die Arbeiten des Mitarbeiters speichert. Dieser Klon kann verschiedene Zweige – branches – enthalten.
  • Die eigentliche Arbeit erfolgt in einer lokalen Arbeitskopie. Hierzu wird mit checkout der Klon oder ein Branch in die lokale Arbeitskopie geschrieben.
  • Die lokalen Änderungen werden anschließend zu einem lokalen Transferspeicher – Stage – hinzugefügt – add – und mit einem comit in den Branch oder Klon zurückgeschrieben.
  • Die Übertragung der Änderungen des Klons oder Branch nach GitHub erfolgt mittels push.
  • Die Übertragung der Änderungen des Klons oder Branch in den Master erfolgt mittels pull request und merge. D.h. der Mitarbeiter beantragt, dass seine Änderungen in den Master übernommen werden und nach erfolgreichem review werden die Änderungen übernommen.

Im Projekt GC Wizard wird dies wie folgt umgesetzt:

  • Der Master enthält den jeweiligen Quellcode der aktuellen App.
  • Für die nächste Version wird ein Version-Branch erzeugt.
  • Für jede neue Funktion der nächsten Version wird ein Feature-Branch erzeugt. Wenn Du eine neue Funktion “IncreaseN” beitragen möchtest, erstelle bitte einen Branch mit dem entsprechenden Namen increasedn aus dem aktuellen Versions-Branch. Wenn Du gleichzeitig an zwei verschiedenen Funktionen arbeitest, musst Du zwei verschiedene Feature-Branches erstellen. Dies erlaubt Mark, die Features getrennt zu testen und zusammenzuführen. Wenn es nur eine kleine Fehlerkorrektur oder ein Tippfehler ist, ist es ok, dies pragmatisch zu machen, ohne einen speziellen Branch zu erstellen, aber das sollte eine Ausnahme für wirklich kleine Änderungen bleiben!

Commit

Jeder Commit ist mit einer kurzen Nachricht zu versehen, die einen Überblick über die Änderungen gibt.

Gute Commit-Nachrichten sind nicht nur für andere wichtig, mit denen Du vielleicht an dem Projekt mitarbeitest, sondern auch für Dich selbst, um den Überblick über alle Deine Commits zu behalten und genau zu wissen, welche Änderungen vielleicht während dieses bestimmten Commit gemacht wurden.

Ein gutes Format ist zum Beispiel:

<type> : <subject>
<body>
<footer>

typeEine kurze Beschreibung der Änderung
– Feature
– Bugfix
– Dokumentation
– Style/User Interface
– Refactor
– Test
– Systemumgebung
subjectEine kurze Beschreibung der vorgenommenen Änderungen. Sie sollte nicht länger als 50 Zeichen sein, mit einem Großbuchstaben beginnen und im Imperativ geschrieben sein: z. B. Add statt Added oder Adds.
bodyDer body dient dazu, zu erklären, welche Änderungen Du vorgenommen hast und warum Du diese Änderungen gemacht hast. Nicht alle Übertragungen sind so komplex, dass sie einen
body benötigen.
Zwischen dem body und dem subject ist eine Leerzeile erforderlich und jede Zeile sollte nicht mehr als 72 Zeichen enthalten.
footerDer footer ist ebenfalls optional und wird hauptsächlich verwendet, wenn Du einen Issue-Tracker verwendest, um auf die Issue-ID zu verweisen.
Zwischen dem body und dem footer ist eine Leerzeile erforderlich und jede Zeile sollte nicht mehr als 72 Zeichen enthalten.