Werkzeuge bei Droptica – Teil 3 – Dateispeicher

Es ist offensichtlich notwendig, nach Werkzeugen zu suchen und diese zu nutzen, wenn man Drupal-Entwicklungsdienste anbietet. Es ist Zeit für eine weitere Dosis Informationen über unsere Arbeit bei der Droptica-Firma. Heute werden wir Dateiversionierung und Anwendungstests behandeln.

Subversion

Die ersten mit Drupal umgesetzten Projekte (noch als OPENBIT) nutzten das Subversion-System (auch bekannt als SVN, Projektwebsite) zur Dateiversionierung. Eines dieser Projekte war das Intranet-System für die Firma Telefonia Dialog S.A. (Fallstudie).

SVN, wie andere Versionierungssysteme, erlaubt Ihnen, eine Historie der Dateiversänderungen zu führen. Der Hauptunterschied zwischen SVN und GIT (auf das wir gleich näher eingehen werden) besteht darin, dass in SVN das Repository auf einem entfernten Server gehalten wird, auf den jeder Änderungen einführt. Dies zwingt Sie, nur auf dem entfernten Server zu committen; Sie können nicht nur lokal unbegrenzt Änderungen committen. Mit SVN entstanden manchmal schwer zu lösende Konflikte (zum Beispiel, wenn zwei Personen an denselben Dateien arbeiteten). Das Verwalten und Zusammenführen von Zweigen war auch unpraktisch.

GIT

Im Jahr 2012 starteten wir unsere ersten Versuche mit GIT, um an Projekten zu arbeiten. Die erste "seltsame" Sache war, dass, um Änderungen zum Server zu senden, der Befehl "commit" nicht ausreichte; es war ein zusätzlicher "push"-Befehl nötig. Dieser zusätzliche Schritt war in SVN nicht vorhanden. Das liegt daran, dass GIT ein verteiltes System ist, d.h. das Repository wird nicht auf einem Server, sondern an vielen Orten gehalten (z.B. auf den Computern der Programmierer, Testservern, etc.).

Bei der Verwendung von GIT committen wir zum lokalen Repository auf dem Computer und synchronisieren dann unsere Änderungen (Commits) mit einem anderen Repository. Gewöhnlich wird ein entferntes Repository als Hauptplatz für das Pushen von Änderungen festgelegt. Es spricht jedoch nichts dagegen, dass ein Programmierer seine Änderungen in das auf dem Computer eines anderen Programmierers befindliche Repository pushed (Zugriff notwendig, z.B. über SSH). Der zweite Programmierer schließt die Aufgabe ab und pushed die Änderungen zum entfernten Hauptserver.

GIT funktioniert sehr gut beim Zusammenführen von Änderungen, die in derselben Datei gemacht wurden. Es ist auch bequem, Zweige im Repository zu zusammenzuführen. Viele Nutzer finden GIT ein sehr gutes Versionierungssystem, und wir stimmen dieser Meinung voll und ganz zu.

GIT GUI

GIT ist eine Konsolenanwendung, d.h. um es zu verwenden, müssen Sie Befehle in ein Terminal eingeben. Das kann für Anfänger schwierig sein, daher empfehlen wir zunächst die Verwendung einer grafischen Oberfläche für GIT. Einige Beispiele für solche Programme finden Sie unten:

• Smartgit (Linux, Windows, MacOS), ein kostenpflichtiges Programm, das jedoch viele Optionen und eine klare Benutzeroberfläche bietet. Einige Leute bei Droptica nutzen dieses Programm.
• GitKraken (Linux, Windows, MacOS)
• GitEye
• Giggle

Es gibt viele andere Programme dieser Art, suchen Sie einfach mit Google nach GIT GUI. Allerdings funktionieren nicht alle von ihnen auf Linux, Windows sowie MacOS.

Git-flow

In GIT können wir Zweige erstellen. Mit diesen Zweigen ist es möglich, an der Aufgabe neben dem Haupt- und bereits getesteten Code zu arbeiten. Kurz gesagt, die Arbeit verläuft wie folgt:

• wir beginnen mit der Arbeit an einer neuen Programmieraufgabe
• wir erstellen einen neuen Zweig
• wir erledigen die Aufgabe im Zweig
• wir testen die Aufgabe im Zweig
• nach dem Bestehen der Tests und der Codeüberprüfung wird der Zweig mit dem Hauptzweig zusammengeführt

Solche Zweigoperationen erfordern mehrere wiederholte Befehle. Um dies zu vereinfachen, wurde git-flow entwickelt – eine Erweiterung für GIT, die neue Befehle hinzufügt. Eine detaillierte Beschreibung des von git-flow verwendeten Modells zur Zweigerstellung finden Sie unter http://nvie.com/posts/a-successful-git-branching-model/

Wir verwenden git-flow bei Droptica und finden es sehr nützlich. Es ermöglicht uns, Fehler in den zu implementierenden Aufgaben zu eliminieren, bevor der Code mit dem Hauptzweig zusammengeführt wird. Auf diese Weise können wir sicher sein, dass der Entwickler-Zweig nur die getesteten Codes enthält.

Github

Wir behalten den Großteil der Projektcodes in privaten Repositories auf GitHub.com auf. Wir nutzen Github, da es stabile Server für die Speicherung von Dateien bereitstellt und die "Pull request"-Option bietet.

Ein Pull Request ist ein Antrag, einen Zweig mit einem anderen zu verschmelzen, z.B. den Zweig eines Programmierers mit dem Hauptzweig der Anwendung. Während eines Pull Requests können wir eine Zusammenfassung der Änderungen zwischen den beiden Zweigen sehen. Wenn ein Programmierer in seinem Zweig mehrere Commits vorgenommen hat, werden alle Commits zu einer Änderung "zusammengeführt". Wir werden dann einen klaren Vergleich der Änderungen im Code sehen, die nach der Annahme eines Pull Requests (ein Merge-Vorgang wird durchgeführt) vorgenommen werden.

 
Diese Vorschau ermöglicht eine sehr einfache Überprüfung des Codes. Auf diese Weise kann der Hauptprogrammierer des Projekts schnell überprüfen, ob die von einem anderen Programmierer eingeführten Änderungen korrekt sind und zusammengeführt werden können. Eine Codeüberprüfung in einem Pull Request durch eine andere Person stellt sicher, dass der Anwendungscode immer von mindestens zwei Personen bekannt ist.

Wenn Sie mehr über Git erfahren möchten, sollten Sie das Buch "Pro Git" lesen. Eine digitale Version des Buches ist hier verfügbar. Sie können auch eine physische Kopie des Buches bestellen.

In unserer Drupal-Entwicklungsagentur können wir uns jetzt nicht mehr vorstellen, Webseiten mit Drupal und anderen Technologien ohne Git zu erstellen