Git nutzen für Theme Entwicklung

Git nutzen für Theme Entwicklung

Alexander Wolf 18. September 2015 8

Wie kann eure Theme Entwicklung noch professioneller werden?

Ein großer Punkt ist:

Git.

Git ist ein Tool für Versionsverwaltung, d.h. wir verwalten damit verschiedene Versionen unserer Software.

In diesem Fall von unseren Themes.

Kurzes Beispiel:

Wir haben ein super tolles Theme.

Arbeiten fleißig an diesem Theme und merken irgendwann, dass wir etwas kaputt gemacht haben.

Ja, auch Profis machen mal was kaputt.

Haben wir keine Versionsverwaltung eingesetzt, hätten wir jetzt ein Problem.

Ich kann euch beruhigen: Ihr werdet kein Problem haben.

Weil ihr Git für eure Theme Entwicklung nutzt!

Warum solltet ihr Git nutzen?

Wie im Beispiel beschrieben, kann es einfach passieren, dass ihr etwas kaputt macht.

Da solltet ihr euch nicht verrückt machen, sondern einfach eine frühere Version wiederherstellen und weiter arbeiten.

Das ist jetzt sehr vereinfacht dargestellt.

Es gibt noch mehr Vorteile.

Falls ihr im Team arbeitet, ist es deutlich einfacher die Änderungen der anderen Teammitglieder zu verfolgen.

Außerdem ist es auch für euch wichtig einen Überblick über den Code bzw. über den Verlauf der Änderungen zu haben.

Das macht euch zu besseren Entwicklern.

Es verändert auch die Art und Weise wie neue Features eingebaut werden, je nach Workflow.

Mit Git werden wir auch später euren Shopware Shop deployen (hochladen).

Die Zeiten wo ihr per FTP Client den ganzen Shop hochgeladen habt, sind vorbei.

Dazu aber bald mehr.

Vorbereitung

Installation

Meistens wird Git mitinstalliert, wenn ihr euren Git Client installiert.

Also einfach Client aussuchen, runterladen und installieren.

Wenn ihr euch intensiver mit dem Thema Git auseinandersetzen wollt dann schaut euch folgende Links an:

Software / Client

Es gibt viele grafische Oberflächen für Git.

So könnt ihr es auch ganz einfach nutzen ohne alle Konsolenbefehle von Git auswendig zu kennen.

Eine Übersicht einiger Clients, probiert einfach etwas aus.

https://git-scm.com/downloads/guis

Wir bei 8mylez nutzen SourceTree.

Aber probieren demnächst GitHub Dekstop aus.

Schreiben gerne einen Erfahrungsbericht.

Bevor es los geht mit unserem ersten Repository, schauen wir uns noch an welche Dateien wir überhaupt versionieren wollen und welchen Workflow wir nutzen werden.

Welche Dateien versionieren?

Mit dieser Frage beschäftigt sich jeder Theme Entwickler irgendwann.

Wollen wir den ganzen Shop versionieren oder nur unser Theme?

Generell sollten wir nur Code versionieren der auch von uns geschrieben ist.

Alles andere macht nur Probleme bei Updates und Bugfixes.

Wenn ihr den ganzen Shop versioniert, dann werden einfach unnötig viele Dateien versioniert und das Hochladen usw. dauert länger.

Es gibt eine Ausnahme.

Einige Theme Entwickler nutzen Git zum deployen (hochladen). Ist super bequem, einfach und cool.

Schauen wir uns demnächst auf jeden Fall auch an.

Nur in diesem Fall müssen wir den ganzen Shop versionieren.

Für alle anderen Fälle gilt: Nur unser Theme.

Workflow

Es gibt verschiedene Workflows die ihr nutzen könnt um Git optimal zu nutzen.

Git ist ein Versionierungstool und nicht nicht nur Backuptool.

d.h. jeden Abend einfach einen Commit machen, sodass es ein Backup vom Theme gibt ist Quatsch.

Könnt ihr natürlich so machen, aber wir empfehlen was anderes:

Feature Branch Workflow

Es gibt den master Branch.

Dieser master Branch ist jederzeit bereit zum Hochladen und muss demnach immer funktionieren.

Das ist wichtig, da ihr jederzeit eine funktionierende Version zur Hand habt.

Alle neuen Anpassungen sind Features.

Und jedes Feature bekommt einen eigenen Branch.

Wir passen unser Theme an und implementieren die neuen Features.

Zum Schluss müssen wir den erstellten Feature Branch in den master Branch mergen (zusammenführen).

Im besten Fall gibt es keine Konflikte und wir können das nächste Feature angehen.

Kurzes Beispiel:

Wir wollen die Logo Größe anpassen wie im Beitrag: http://8mylez.com/blog/logo-groesse-anpassen/

Dazu legen wir einen Branch an mit dem Namen update-logo-size.

Der Name sollte immer kurz beschreiben was gemacht wird.

So könnt ihr später super einfach danach suchen und andere wissen direkt was gemacht wurde ohne das sie den Code studieren müssen.

Nachdem wir alles angepasst haben und zufrieden sind wechseln wir in den master Branch.

Ihr bemerkt, dass sich auch die Dateien anpassen die in dem Ordner liegen.

Wir kriegen den aktuellen Stand vom master Branch.

Unseren update-logo-size Branch führen wir mit dem master Branch zusammen.

Und das neue Feature wurde eingebaut.

Der update-logo-size Branch kann gelöscht werden und wir bauen fleißig weiter.

Am Ende pushen wir den master auf ein Remote Repository, sodass unsere Teammitglieder den Code runterladen (pullen) können um damit zu arbeiten.

Außerdem ist es nochmal ein Backup für uns, falls unser Computer in Flammen aufgeht (oder ähnliches).

Git Hosting Service

Unser Code ist wichtig.

Daher sollten wir diesen online sichern und unseren Teammitgliedern zur Verfügung zu stellen.

Am einfachsten geht das mit Git.

Bevor wir wieder einen eigenen Server aufsetzen und alles verwalten müssen, entscheiden wir uns für einen Git Hosting Anbieter.

Wir nutzen hierfür Gitlab.

GitLab könnt ihr kostenlos nutzen und unendlich viele private Repositorys erstellen.

Wobei bei GitHub nach ein paar privaten Schluss ist.

Entweder veröffentlicht ihr euren Code oder bezahlt für mehr private Repositorys.

Bitbucket ist ebenfalls kostenlos.

Unser erstes Repository

In diesem Beispiel arbeiten wir mit dem Client SourceTree und dem Hosting Anbieter GitHub.

Das Repository legen wir in unserem Theme Ordner an.

Wir benutzen unser FlatResponsive Theme als Platzhalter.

themes/Frontend/FlatResponsive

Wenn ihr noch keins angelegt habt, dann checkt das aus: http://8mylez.com/blog/shopware-5-theme-erstellen/

Das Respository ist jetzt lokal auf unserem Computer.

Damit wir auch später den Code pushen können, legen wir bei GitHub auch ein Respository an.

Aber eines nach dem anderen.

Lokales Repository anlegen

Öffnet SourceTree.

Dazu einfach auf "Neues Repository". Wählt "Lokales Repository erstellen".

Neues Repository erstellen

Ein paar Informationen eintragen.

Den Ordner mit unserem Theme zuweisen.

Und fertig!

Remote Repository anlegen

Ruft github.com/ auf.

Anmelden oder registrieren.

Klickt auf "New repository".

GitHub new repository

Ein paar Informationen eingeben.

Wenn ihr nicht wollt, dass der Code öffentlich ist dann wählt private aus.

Informationen für das GitHub Repository

Kopiert euch den Link vom remote Repository.

Bei uns ist es

https://github.com/8mylez/flatresponsive.git

Die Repositorys sind angelegt und wir müssen diese noch verknüpfen.

Remote Repository verknüpfen

Ganz einfach in SourceTree unter Einstellungen.

SourceTree Einstellungen

Auf Hinzufügen klicken.

Als Name origin eintragen und den Pfad bei GitHub von unserem remote Repository rauskopieren.

SourceTree - Remote Repository hinzufuegen

Alles ist jetzt verknüpft und wir können den Code committen und pushen!

Der erste Commit und Push

Der erste Commit wird der Initial commit sein.

Damit fügen wir alle Daten hinzu die von Anfang an dabei sind, sodass wir eine Basis haben mit der wir arbeiten.

Ausstehende Änderungen

Oben Links auf Commit, eine kurze Beschreibung was wir gemacht haben (beim ersten Commit "Initial commit") eingeben und Dateien auswählen die versioniert werden bzw. die Änderungen.

Initial commit

Und abfeuern.

Beim Entwickeln macht ihr mehrere Commits.

Denkt immer daran eine Nachricht zu hinterlassen, sodass ihr und eure Teammitglieder später noch wisst was gemacht wurde.

Der erste Branch

Da wir den Feature Branch Workflow nutzen, legen wir für unser erstes Update einen Branch (Zweig) an.

Dazu klicken wir auf Zweig.

Wir wollen die Logo Größe anpassen.

Unser Branch heißt also update-logo-size.

Wie ihr das Logo anpassen könnt, erfahrt ihr in dem Beitrag: http://8mylez.com/blog/logo-groesse-anpassen/

Nachdem alle Anpassungen vorgenommen wurden, können wir einen Commit abfeuern.

Zum master Branch wechseln und auf Zusammenführen.

Den update-logo-size Branch anwählen, einen Haken setzen bei

"Einen neuen Commit erstellen, selbst wenn fast-forward möglich ist"

und das ganze mergen (auf ok klicken).

Jetzt ist alles im master Branch drin. Immer darauf achten, dass dieser immer funktionsfähig sein muss.

Rechtsklick auf den update-logo-size Branch und löschen.

Weg damit.

Zum Schluss den master Branch auf GitHub pushen (hochladen).

Dazu push auswählen.

Den master Branch anklicken. Und abfeuern.

Das war's auch schon!

Zusammenfassung

Uff.

War gar nicht so wenig was wir heute alles gemacht und gelernt haben.

  • Wir haben Git und etwas vom Drumherum kennengelernt
  • Repositories erstellt: lokal und remote
  • Den ersten Commit gemacht
  • Einen ersten Feature Branch erstellt
  • Alles auf GitHub gepusht

Es ist nicht so einfach und verwirrt am Anfang auch gern etwas.

Ich habe lange gebraucht es zu verstehen.

Aber es lohnt sich. Glaubt mir.

Wartet ab bis wir uns das deployen mit Git anschauen.

Weiterführende Links

8 Kommentare

  • Hallo Alexander,
    super Beitrag, wird mir sehr weiterhelfen.
    Ich stehe noch am Anfang von der Nutzung mit Git, möchte Git nicht nur für Shopware benutzen sondern auch für andere Templates und Themes anderer CMS und Shop-System.
    Was ich mich frage, du sagst du erstellst für deine Änderungen Feature-Branches. Wenn man ein Theme von Grund auf neu entwickelt, wie gehst du dann vor, oder wie wäre der beste Weg? Macht es Sinn sich eine Webseite oder einen Online-Shop nach Bereichen aufzuteilen (Header, Footer, Startseite, Kategorieseite...) und für jeden Bereich ein Feature-Branch zu erstellen? Weil man erstellt ja nicht für jede tpl oder css Änderungen einen neuen Branch, oder sehe ich das falsch?
    Dann noch eine Frage, du legst ein Feature-Branch an, teste du dann lokal, oder kann man das auch auf einem Testserver testen? Ich habe oft einen Testserver für die jeweilige Webseite oder den jeweiligen Shop erstellt. Da habe ich dann den Shop und die Datenbank einmal dupliziert und entwickel dann auf dessen Basis das neue Template/Theme. Hast du da auch eine Lösung für?
    Ich danke erstmal für deine Rückmeldung und nochmals für den Beitrag, der ein wenig Licht ins Dunkle bringt.
    VG
    Marcel
  • Hey Marcel,

    vielen Dank! Anfangs entwickle ich erst einmal eine solide Basis. Im Prinzip kommt es auch darauf an ob du alleine oder mit anderen zusammen arbeiten musst. Wenn du alleine arbeitest, kannst du ruhig eine Basis schaffen und dann auch wirklich neue Features mit den Features Branches hinzufuegen.

    Wenn du etwas testen willst, kannst du auch den Branch entsprechend deployen. Muss nicht unbedingt spektakulaer sein, Theme / Plugin packen, hochladen, entpacken ist da auch in Ordnung.

    Wenn soweit alles passt, arbeite ich dennoch immer lokal daran weiter. Sonst koennte ich die Sachen nicht weiter versionieren.

    Da gibt es aber unzaehlige Workflows. Oft hilft es z.B. nach deinem System in Verbindung mit lokaler Entwicklungsumgebung und Git zu suchen. Dazu gibt es dann auch verschiedene Tutorials die alle moeglichen Workflows abdecken.

    Wir arbeiten uebrigens lokal mit Docker und Git. So brauchen wir keinen Testserver, ausser wenn wir das Theme jemandem praesentieren wollen. Dann kann mans einfach kurz packen und hochladen. Einfach und flexibel!

    Gruß
    Alexander
  • Hört sich gut an. Habt ihr für das Deployment per GIT auch schon eine Lösung?
    Stehe vor dem Deployment Problem, und Shopware scheint dafür noch nicht so recht gerüstet zu sein (z.B. es per composer zu machen, hab da nur ein Repo gefunden wo in diese Richtung experimentiert wird).
    Bin jetzt auch eher für diesen Weg: Eigenen Code ins GIT --> und auf einem Staging/Live Server ein Git-Checkout per rsync in die Docroot syncen. Plugins die die DB-Struktur ändern, sind dann halt auch immer wieder ein Problem.

  • Hey Siegi,

    für das Deployment haben wir mehrere Lösungen. Es kommt ganz darauf an wie die Ausgangssituation ist. Im Idealfall versionieren wir nur das Theme und einzelne Plugins.

    So können wir dann über einen Git Push alles entsprechend hochladen. Dafür muss das Repository auf dem Server vorher aber korrekt erstellt werden.

    Wir haben auch schon öfter von Capistrano oder Mina gehört, womit es wohl auch sehr einfach gehen soll.

    Nach einem erfolgreichen Deploy musst du die Plugins im Backend noch "updaten". Damit löst sich das Verändern der DB Struktur einschränken.

    Zwischen des Hochladens und dem Klick auf "Update" beim Plugin, entsteht zwar eine Lücke, jedoch machte dies bei uns bisher keine Probleme. Sollte das für dich keine Endlösung sein, gibt es im Internet sehr viele Möglichkeiten für diese Zero-Downtime Deployments. Docker könnte da evtl. auch interessant sein für dich.

    Andernfalls reicht es manchmal auch, wenn das Plugin übers Backend manuell hochgeladen wird.

    Gruß
    Alexander
  • Hallo Atilla,

    ich wünsche dir viel Erfolg! Bei Fragen einfach melden :)

    Gruß
    Alexander

Was denkst du?

Beliebt

Was du über die Shopware 5 Theme Struktur wissen musst und wie du ein eigenes Template erstellst
Social Media Icon mit Link im Footer
Shopware Theme: Eigenes Listing Layout erstellen
Logo Größe mit Less für Shopware 5 anpassen
Die größten Fehler bei der Entwicklung eines Shopware 5 Themes

Sicher Dir die besten Shopware 6
Tipps & Tricks

Trag Dich ein und Du erhältst unser Shopware 6 Whitepaper kostenlos!
Trag dich für unseren Newsletter an, im Anschluss erhältst Du das Whitepaper. 

Mit dem Abschicken Deiner Daten akzeptierst Du unsere Datenschutzerklärung.

Entdecke unsere ebooks

Unsere Standorte

Zentrale 

Technologiepark 23
33100 Paderborn


Leipzig
Bernhardstraße 34
04315 Leipzig

Kontakt

Über 8mylez

✓ 38 Mitarbeiter

✓ Shopware Gold Partner

✓ 40.000+ Plugin Downloads

✓ 160+ betreute Shops

✓ Full-Service Shopware Agentur

✓ 70 Shopware Videos auf Youtube

✓ Alle Shopware Zertifizierungen

Social


Unsere Partner
© 2024 by 8mylez GmbH //  Impressum + Datenschutz