Wie verwalte ich meinen Sourcecode?

  • Hallo!


    Meine Intention hinter diesem Tutorial ist es mehr Leute dazu zu bringen Versionskontrollsysteme (VCS) wie Git oder SVN einzusetzen.
    Ich werde in diesem Tutorial keine tiefgehenden Details zu Git beschreiben, denn Git Tutorials gibt es im Internet genug, sondern vielmehr die Vorteile und Möglichkeiten gegenüber "manuellen Methoden" aufzeigen.


    Bevor ich die Features eines VCS erkläre, möchte ich eine Situation beschreiben, die einen Schlimmstfall bei "manuellen Methoden" beschreibt:


    Wie es nicht geht...
    Das Projekt besteht aus 2 Entwicklern, die den Sourcecode über einen FTP Server teilen. Da es zu aufwendig ist und sie durcheinander kommen, wenn sie den Code erst lokal bearbeiten und erst wenn sie fertig sind hochladen, bearbeiten sie den Code direkt auf dem FTP Server und laden Änderungen sofort hoch. Damit sie den Code nicht gegenseitig kaputt machen, sprechen sie sich ab bevor sie an einer Datei arbeiten.


    Eines Nachts nun arbeitet Person A an einem größeren Feature, das sich über mehrere Dateien erstreckt. Person B möchte nun einen kleinen Bugfix machen und da Person A nicht in Skype online ist und die Uhr eh 4 Uhr nachts anzeigt, denkt sich Person B, dass es in Ordnung geht Person A nicht zu benachrichtigen. Nachdem Person A nun das Feature fertiggestellt hat, alles hochgeladen hat und schlafen geht, lädt Person B den Bugfix hoch, hatte die Datei aber schon um 3 Uhr geöffnet. Am nächsten Morgen möchte Person A das neu eingebaute Feature nochmals testen, wundert sich aber, dass all die Arbeit verschwunden ist.


    Die beiden merken schnell, dass dieser Fehler entstanden ist, weil sie sich nicht abgesprochen haben. Da sie dies aber in der Entwicklung erheblich zurückwirft, beschließen sie noch 3 weitere Entwickler ins Team zu holen.


    Mit 5 Entwickern sollte alles nun erheblich schneller laufen, doch die 5 merken schnell, dass nur 2 Entwickler effektiv arbeiten können, weil nur eine Person gleichzeitig an einer Datei arbeiten kann. Weiterhin gibt es einen Entwickler im Team, der sich nicht an Absprachen hält und einfach direkt an Scriptdateien arbeitet.


    Die Situation beginnt sich zuzuspitzen und der Frust über die Situation steigt zunehmend, weil die Hälfte der Entwickler nichts machen kann. Schließlich kommt es zwischen mehreren Parteien zum Streit, welcher eskaliert und woraufhin der Hauptentwickler das Script vom FTP Server löscht. Da das letzte Vollbackup schon 2 Wochen alt ist, ist der Ärger groß und eines der Spezialfeatures, in das Person A viel Arbeit investiert hat, ist endgültig verloren.


    Dies führt wiederum dazu, dass aus Frust das Script im MTA Forum veröffentlicht wird und @Doneasty sich schließlich um die Konfliktlösung kümmern muss.
    Da @Doneasty selbiges aber schon die ganze Woche über gemacht hat, hat er keine Lust mehr und beschließt dem Forum den Rücken zu kehren, wodurch es 2 Wochen später vom Rest des Teams geschlossen wird.
    Also gilt: Die Moral der Geschicht': Traue manuellen Methoden nicht.



    Die Erlösung: Versionskontrollsysteme
    Die vorher dargestellte Geschichte zeigt nicht nur, welche Folgen schlechte Organisation in anderen Bereichen als der Entwicklung haben kann, sondern auch, dass Versionskontrollsysteme gleich mehrere der dargestellten Probleme lösen:


    1. Teilen des Sourecodes
    Wie ich versucht habe darzulegen ist es bei 2 Entwicklern schon oft nicht ganz einfach den Code zu teilen, aber spätestens wenn noch weitere Entwickler dazu kommen, wird alles zwangsläufig schief gehen. Dazu stelle man sich eine Unternehmung vor, bei der 50 Entwicklern gleichzeitig an der gleichen Codebasis arbeiten. Dass das Teilen über einen FTP Server dort nicht mehr funktioniert dürfte jedem klar sein.


    Mit einem Versionskontrollsystem werden nicht ganze Dateien getauscht, sondern nur die Änderungen an den Dateien. Das bedeutet, dass mehrere Entwickler problemlos an einer Datei arbeiten können. Selbst wenn sie an der gleichen Zeile arbeiten, wird das VCS die Person, die die Änderungen als zweites hochlädt, mit der Meldung eines Konflikts informieren. Anschließend können die Konflikte in den meisten Fällen recht leicht mit einem dafür vorgesehenen sog. "Diff-Tool" gelöst werden.


    2. Versionierung
    In einem Versionskontrollsystem wird jede Version, die es je von einer Codebasis gab, gespeichert. Das bedeutet, dass zu jedem Zeitpunkt zurückgegangen werden kann. Dementsprechend kann Code nicht dauerhaft gelöscht werden (ohne das ganze Code-Repository zu löschen).


    Versionierung hilft auch Fehler zu finden, da zum einen durch die History bekannt ist wann bestimmte Änderungen gemacht wurden und zum anderen zu jeder Version zum Testen gewechselt werden kann.


    3. Leichtes parallele Arbeiten an größeren Features und anschließendem Zusammenführen
    Man stelle sich dazu ein laufendes Projekt vor. Ein Programmierer möchte ein neues, größeres Feature einbauen, welches mehrere Wochen an Zeit beansprucht und sich über viele Dateien erstreckt. Währenddessen muss auf dem Produktivserver ein kritischer Fehler behoben werden. Mit "manuellen Methoden" wäre dieser Sachverhalt nur mit sehr viel Aufwand lösbar, da in diesem Fall min. 2 Kopien des Codes existieren müssten, die nur mit sehr, sehr viel Aufwand und einem hohen Fehlerrisiko zusammengeführt werden können.


    Mit einem VCS geht das durch sog. Branching ganz einfach, da nur Änderungen geteilt werden und diese Änderungen sehr leicht übertragen werden können. So kann also an mehreren, großen Features gleichzeitig entwickelt werden, während der Produktivbetrieb dadurch nicht gestört wird.



    Git Crashkurs
    Mein persönlicher Favourit ist Git, vor allem weil Git sehr flexibel ist und es viele gute Hostinglösungen gibt.


    1. Beschaffung eines Git Servers
    Zunächst bedarf es einem Git-Repository auf einem Server, die entweder selbst gehostet oder von Drittanbietern sind.


    Self-hosted:

    Drittanbieter:

    Im allgemeinen Fall empfehle ich Hosting durch Drittanbieter, da der Wartungsaufwand entfällt. Wenn keine privaten Repos notwendig sind oder der Education Rabatt möglich ist, empfehle ich GitHub. Ansonsten sind GitLab.com und BitBucket.org ebenfalls in Ordnung.


    Natürlich kann auch ein Git Server ohne Weboberfläche installiert werden; in der Vergangenheit hat sich jedoch gezeigt, dass Weboberflächen gerade bei größeren Teams sehr nützlich sind.


    2. Installation eines Git Clients
    Bei Git (https://git-for-windows.github.io/) arbeitet man i.A. sehr viel mit der Kommandozeile. Als zusätzliche Unterstützung eignet sich aber TortoiseGit (https://tortoisegit.org/), meiner Meinung nach, gut. Von Tools wie "GitHub for Windows/Desktop" rate ich jedoch eher ab, da dabei die Internas von Git zu sehr verschleitert werden, was oft zu unnötigen Problemen führt.


    Am Anfang mag die Kommandozeilenbedienung von Git recht ungewohnt erscheinen, das ändert sich aber recht schnell, da der Ablauf fast immer der gleiche ist.


    3. Benutzung
    https://rogerdudler.github.io/git-guide/index.de.html
    https://www.atlassian.com/git/tutorials/

  • Schönes Tutorial! Jetzt fehlt nur noch der Bereich, wie man effektiv ein automatischen Checkout mit Kombination mit einem MTA Server aufsetzt, der bei jeden Commit den aktuellen Stand auf dem Server aktualisiert (auf meinem Clan Server läuft das so).

  • Dies führt wiederum dazu, dass aus Frust das Script im MTA Forum veröffentlicht wird und @Doneasty sich schließlich um die Konfliktlösung kümmern muss.

    Klingt blöd, kommt aber wirklich viel, viel, viel zu oft vor. Vielen Dank!

  • Gutes Tutorial. Wie sieht es mit deinem Lua Tutorial aus?

    If A equals success, then the formula is A equals X plus Y plus Z. X is work. Y is play. Z is keep your mouth shut.

  • Ich finde noch erwähnenswert, dass sich in einer Repository ausschließlich Code befinden sollte. Alles andere sollte unabhängig manuell in anderen Verzeichnissesn vorhanden sein. (Assets, Bilder, Sounds usw.)
    Das vergesse ich jedoch auch ständig.
    Ansonsten nicht schlecht ;)

    Mit freundlichen Grüßen

  • Zitat von Noneatme

    Ich finde noch erwähnenswert, dass sich in einer Repository ausschließlich Code befinden sollte.

    Mit Git LFS (https://git-lfs.github.com/) ist das im allgemeinen Fall kein Problem und bei MTA hat man im Normalfall ja eh nicht übermäßig große Dateien.

    Zitat von MegaThorx

    Wie sieht es mit deinem Lua Tutorial aus?

    Mache ich bald weiter.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!