Angepinnt Wie verwalte ich meinen Sourcecode?

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • 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:
      • GitLab (about.gitlab.com/): Open-Source, viele Features, aber ressourcenfressend und recht aufwendige Installation
      • Gogs (gogs.io/): Open-Source, die wichtigsten Features, leichte Installation und sehr ressourcensparsam
      • BitBucket (bitbucket.org/): 10$ für bis zu 10 Benutzer (danach teuer)
      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 (git-for-windows.github.io/) arbeitet man i.A. sehr viel mit der Kommandozeile. Als zusätzliche Unterstützung eignet sich aber TortoiseGit (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
      rogerdudler.github.io/git-guide/index.de.html
      atlassian.com/git/tutorials/
    • Jusonex schrieb:

      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!
      PR/Marketing/Communtity Dude bei nanos.io
      "Cash rules everything around me: CREAM, get the Money Dollar, dollar bill y'all"
      Zitateliste auf meinem Profil-stets aktuell
      Zertifizierter Satanisten-Nazi-Ex-Admin
      twitter.com/dennismitzwein
    • Man kann in Gogs auch einen git-hook aktivieren, um automatisch das Repository in einen Ordner zu entpacken (post-receive).
      Hier ist der Gist dazu: gist.github.com/Necktrox/a0defb5c3933afbdf509b5c26acf5d2a
      Der Pfad muss natürlich existieren und dynamische Dateien/erzeugte Dateien müssen in der .gitignore stehen, damit diese bei einem Commit nicht gelöscht werden.
    • 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 ;)
      [Blockierte Grafik: http://i.imgur.com/526C4Hj.png] Mit freundlichen Grüßen,
      Noneatme
      WEBSITE | GITHUB | STACKOVERFLOW | E-MAIL | DONATE
    • Da es im Tutorialbereich angepinnt ist, ist es beim genaueren Betrachten doch relativ logisch, dass es ein Tutorial ist:P

      Aber kann man machen.
      PR/Marketing/Communtity Dude bei nanos.io
      "Cash rules everything around me: CREAM, get the Money Dollar, dollar bill y'all"
      Zitateliste auf meinem Profil-stets aktuell
      Zertifizierter Satanisten-Nazi-Ex-Admin
      twitter.com/dennismitzwein