Die Homepage

git

git ist ein Versionierungssystem, welches häufig für Websites verwendet wird. Dies ermöglicht paralleles Entwickeln mit mehreren Personen und Wiederherstellen oder Zugreifen auf alte Versionen. Wie das genau funktioniert, erfährst du hier:

Erst einmal musst du dir einen git-Client installerien. Für die Nutzung würde ich ein unixoides Betriebssystem, also Mac oder noch besser Linux, empfehlen, da Windows für unser Vorhaben nicht optimal ist. Du kannst aber auch, wenn du Windows hast, dort eine Virtuelle Maschine installieren (Weitere Infos). Git stellt hierzu wahlweise eine GUI-basierte (als Programm mit Benutzeroberfläche; bei Windows empfehlenswert) und eine CLI-basierte (über das Terminal) Lösung bereit.

Zunächst müssen wir das Repository (repo), das ist ein "Ordner" in welchem sich das Projekt im Account auf github/bitbucket befindet, klonen, das heißt, auf unseren PC ziehen, damit wir lokal daran arbeiten können. Damit stören wir niemanden, der daran arbeitet und können selbst genauso herumprobieren, ohne von anderen gestört zu werden, bis wir unser Ergebnis wieder auf bitbucket zur Verfügung stellen, damit die Besucher der Homepage es sehen können.

Repos Repos options

Oben rechts findest du den Button "Repositories". Wenn du darauf klickst, öffnet sich ein kleines Dropdown-Menü. Später kannst du hier zwischen deinen aktiven Repositorys wechseln. Ganz unten befindet sich noch ein Button namens "Manage Repositories". Dort klickst du ebenfalls drauf.

Manage repos New repo

Daraufhin wird sich ein neues Menü öffnen, welches sich Dashboard öffnet. Hier siehst du nun in Vollbild noch einmal deine Repositories. An der rechten Seite ist eine Reihe von Buttons. Wir benötigen erst einmal den Button "Clone Remote Repository".

Git fetch, pull, push Git fetch, pull, push (2)

Ist das geschehen, hast du das Repository heruntergeladen und hast ein sogenanntes "Lokales Repository" aus dem "Remote Repository" erzeugt. Das heißt nichts anderes, als dass du eine Kopie des Repositorys besitzt, auf das alle anderen Mitarbeiter auch zugreifen können. Deine Kopie allerdings kannst du bearbeiten, ohne dass sofort das Repository online gleich mit geändert wird und vielleicht Ändererungen verloren gehen würden.

Git branches

Auf der rechten Seite findest du die sogenannten Branches. Das sind quasi unterschiedliche Varianten des Repositories. Im master findest du zum Beispiel immer die Originalausgabe. Alles andere sind spezielle Kopien des master-branches, in dem gesondert Änderungen durchgeführt werden können. Dazu kommen wir aber noch im Abschnitt "git flow".

Tower changes stage

Die Dateien in dem Verzeichnis, in welches du das Repository heruntergeladen hast, kannst du nun wie gewohnt bearbeiten. Wie du im oberen Bild siehst, überwacht git deine Änderungen, die du an den Dateieien, die du in dem Ordner machst und zeigt dir an, was du geändert hast. Wenn du die Änderungen in das Repository online übertragen willst, musst du die Checkbox links neben der Datei anklicken. Ist das geschehen, gilt die Datei als "staged". Die "Staging Area" ist sozusagen ein Wartebereich.

Git commit, merge Git fetch, pull, push

Hast du alle zusammengehörigen Änderungen abgeschlossen und gestaged, klickst du auf den "Commit"-Button. Hiermit fasst du sie zu einem Paket zusammen und beschreibst kurz, was du geändert hast. Dies sollte in Stichworten bestehen und am besten Schlüsselwörter wie "new", "changed", "fixed", "deleted" oder so enthalten. Ist auch das geschehen, musst du auf den "push"-Button klicken, damit die Änderungen auch online sichtbar sind. Du kannst auch mehrere commits hintereinander machen, wenn es mehrere verschiedene Änderungen gab. Es ist zu empfehlen, nach dem "commit" und vor dem "push" kurz einen "pull" zu machen, damit deine Änderungen und mögliche Änderungen der anderen abgeglichen und zusammengefasst werden können, damit es nicht zu einem sogenannten "merge conflict" kommt. Sollte es zu einem solchen kommen, musst du diesen manuell lösen oder, wenn du dir unsicher bist, einen anderen Mitarbeiter um Hilfe bitten.

CAGF — casual advanced git flow

Zusammenarbeit in git — Was für Probleme können auftreten?

Nehmen wir einmal an, PersonA erstellt ein neues Feature im master-branch, der ja standardmäßig da ist und pusht erst einmal seine Änderungen am bisher noch unfertigen Feature. Jetzt kommt BenutzerB, macht ein paar kleine Korrekturen, pusht diese und spielt diese natürlich live. Doch was passiert dabei? Richtig: alle seit dem letzten Mal, bei dem die Daten live gegangen sind, getätigten Änderungen sind nun ebenfalls live. Auch die von PersonA, obwohl diese noch nicht fertig sind. Das lässt sich in einem Branch einfach so nicht wirklich machen. Einzige Möglichkeit wäre, dass PersonA solange nichts pusht, sondern nur commitet, bis sie fertig ist. Ist aber unschön.

Zusammenarbeit mit mehreren branches

Es gibt für dieses Problem eine Lösung: Den git flow. Das ist ein Standard, der sich bei vielen git-Nutzern etabliert und bewährt hat. Wir nennen unsere Variante den casual advanced git flow (kurz CAGF), da wir einige Schwächen des herkömmlichen Konzepts ausgleichen und uns dabei an verschiedenen Lösungsansätzen orientieren, die wir zu einer eigenen Variante kombiniert haben. Hierbei werden bestimmte, für einzelne Anwendungsfälle benötigte branches und branch-Typen erzeugt. Die am meisten verwendeten sind folgende:

  • master (= development)
  • feature/*
  • hotfix

Der letzte Punkt hat einen Stern, weil es sich dabei um einen Spezialfall handelt, da es bei diesem im Gegensatz zu den anderen mehrere branches geben kann. Es gibt immer nur einen master-branch, aber beispielsweise einen branch mit Namen "feature/super-neu" und einen branch mit dem Namen "feature/oldy-but-goldy" geben kann. Ich glaube, ihr seht, worauf ich hinaus will.

Das heißt: Wenn ihr was aufwendigeres macht, was über mehrere Tage und commits entwickelt wird, legt bitte lieber einen (feature-)branch zu viel an, als einen zu wenig, bevor noch was live geht, was nicht live gehen soll und sich dann verwunderte Benutzer an uns wenden, warum da ein Text in der Mitte aufhört oder dergleichen. Doch, wofür ist der Rest gut? Hotfixes sind Änderungen, die sofort live gehen sollen.

Du wirst also am meisten mit dem feature-branches und dem master zu tun haben. Wir verzichten auf vorgeschlagene branches wie "dev(elopment)" oder "release", da dies den git flow nur unnötig verkomplizieren würde. Der master ist schon der Entwicklungsbranch und der live-Stand ist nur der letzte live gestellte Stand des masters. Der deploy (master live stellen) noch manuell vorgenommen. Das soll allerdings in Zukunft noch geändert werden.

(Weitere Informationen)

Umsetzung

Erste gute Nachricht: Für Windowsnutzer ist die Funktion "Git-Flow" bereits in Tower mit inbegriffen; ihr braucht sie also nicht extra zu installieren.

Git flow

Dieses Symbol prangt jetzt oben rechts neben den pull-, push-, merge- und commit-Knöpfen auf. Wenn du darauf klickst, erscheint ein Dropdownmenü. Um ein neues feature zu entwickeln, brauchst du nur auf "Start feature" zu klicken und in dem sich öffnenden Fenster den Namen eintragen. Mit Klick auf "Start feature" im Fenster startest du einen neuen feature-branch, der auf der linken Seite unter den branches erscheint.

Um die Entwicklung des features abzuschließen und die Änderungen und commits wieder in den master zu integrieren, musst du nun dort auf der linken Seite unter branches auf deinen feature-branch einen Rechtsklick machen und auf "Git-Flow finish feature "an awesome feature"" klicken.

middleman

Middleman ist eine Arbeitsumgebung zum lokalen Entwicklen von Websites, welche auch precompiler wie Less, Sass, SCSS, Erb, Haml, Coffeescript und viele mehr unterstüzt. Wie unsere Homepage aufgebaut ist und wie du Artikel erstellst und bearbeitest, erfährst du hier:

Zunächst musst du middleman installieren. Auf unixoiden Betriebssystemen (Linux/Mac) ist die dafür benötigte Programmiersprache Ruby bereits vorinstalliert (auf Windows muss das noch gemacht werden) und wir können damit starten, die folgenden Sachen zu installieren:

sudo apt-get install ruby-dev make zlib1g-dev
sudo gem install middleman

Sobald middleman installiert ist, kannst du in den Ordner gehen, in welchem sich deine Website befindet (sofern du wie oben angegeben bereits das boypoint-Repository geklont hast) und anfangen, mit middleman zu arbeiten. Die Entwicklung mit middleman läuft in zwei Phasen: Der Entwicklungsphase und der live- oder static-Phase, also das, was du später als Besucher der Homepage tatsächlich siehst. So kannst du neue Seiten erstellen, ohne dass jeder dir dabei zuguckt und sich fragt, warum der Absatz nach einer halben Seite aufhört ;)

Um die Änderungen trotzdem live mitverfolgen zu können, bietet middleman die Möglichkeit, dir eine Vorschau auf einen lokalen Server zu generieren. Hier einfach den folgenden Befehl ins Terminal eingeben und dann sollte deine Seite über http://localhost:4567/ erreichbar sein.

bundle exec middleman server

So kannst du immer überprüfen, wie die von dir getätigten Änderungen aussehen. Middleman hat im root-Verzeichnis (Hauptverzeichnis, also im obersten Ordner deines Projekts) ein paar Dateien, welche middleman selbst benutzt und die du nur verändern solltest, wenn du weißt, was du tust, und diese Änderungen mit dem Team abgesprochen wurden, da sie grundlegende Änderungen an der Seite herbeiführen können. Dann gibt es da noch zwei (oder drei Ordner). Diese beiden heißen build und source. Im source-Ordner befinden sich die Dateien, die du bearbeiten kannst und deren Änderungen auf deinem lokalen Server wie oben beschrieben angezeigt werden, da wir uns in der Entwicklungsphase befinden. Das build-Verzeichnis enthält den aktuellen Stand, wie ihn die Benutzer sehen, und sollte, solange deine Änderungen noch nicht abgeschlossen sind, nicht verändert werden (dazu kommen wir später). Als letztes gibt es bei dir eventuell auch einen data-Ordner. Hier befinden sich (meist .json- oder .yml-) Dateien, welche zusätzliche Daten enthalten, welche an beliebiger Stelle auf der Seite angezeigt werden können.

Sofern du über HTML- und CSS-Kenntnisse verfügst, kannst du wie gewohnt auch in middleman Seiten erstellen. Hierfür sind nur ein paar Kleinigkeiten zu beachten. Middleman arbeitet mit Layoutdateien und Contentdateien. Die Layoutdateien beeinhalten den grundsäztzlichen Aufbau der Seite (Header, Footer, Navigation). Auch sie sollten mit Bedacht bearbeitet werden, da eine Änderung sich hier meistens nicht nur auf eine Seite auswirkt. An der Stelle, an welcher der jeweilige Seiteninhalt angezeigt werden soll, fügt man folgendes ein:

<%= yield %>

An dieser Stelle werden nun alle von dir in diesem Verzeichnis erstellen Seiten eingefügt. Layoutdateien enden immer auf .erb und befinden sich im layout-Ordner. Erb ist eine Templating Engine (zur Arbeit mit Platzhalten und Funktionen, die vor der live-Phase in Code umgewandelt werden), die middleman für einige Sachen nutzt. Deine Contentdateien enden auf .html.erb. Wenn du in deiner Contentdatei mehrere Abschnitte einfügen willst, kannst du sogenannte "Partials" benutzen. Das funktioniert folgendermaßen:

<%= partial "" %>

In den Anführungszeichen musst du dann nur noch den Namen deines Partials eintragen. Partialdateien fangen immer mit einem Unterschrich an und enden auf .erb. Den Unterstrich darfst du im oben genannten Code, mit dem du die Partials auf deine Seite einfügst allerdings nicht mitangeben. Er dient middleman nur zur Unterscheidung der Dateien und ist deshalb im Dateinamen nötig.

Für Bilder und Links nimmst du hiervon den jeweiligen Code (Das ist nötig, damit middleman die Pfade selbst richtig verlinken kann):

<%= link_to "Linktext", "URL" %>
<%= image_tag 'Dateiname des Bildes', :alt => "alt-Text" %>

So haben wir jetzt gesehen, wie du generellen Seiteninhalt erstellst. Wenn du soweit fertig bist, kannst du deinen aktuellen Stand von middleman umwandeln lassen, sodass du die Seite später im Browser ebenfalls korrekt angezeigt werden kann. Hierzu führst du nun folgenden Befehl aus und kannst die fertige Website (live-Phase)dann im build-Ordner aufrufen. Mache am besten vor und nach dem build einen push mit git. Den push nach dem build gibst du auch den Kommentar "build".

bundle exec middleman build

Wenn du nun noch ein paar fortgeschrittenere Sachen machen möchtest, hilft dir das hier sicher zum weiteren Verständnis:

  • <%= irgendwas %>  erzeugt eine Ausgabe (wie 'echo' in PHP), also zeigt den Inhalt einer Variable, den Text oder das Ergebnis einer Funktion (Rückgabewert) an
  • Wenn du das =-Zeichen hinter dem ersten %-Zeichen weglässt kannst du zwischen <% und %> Code schreiben, der nicht (direkt) ausgeführt wird (z.B. Variablen deklarieren, Schleifen anfangen (siehe unten), etc.)
  • Solltest du mehrere Variablen deklarieren wollen, tue dies aber lieber ganz oben auf der Seite in einem separaten Abschnitt:
---
title: boypoint.de - Backstagebereich - Die Homepage
---
  • Solltest du größere und/oder verschachtelte Arrays und/oder Objekte deklarieren wollen, tue dies wiederum eher in einer gesonderten Datei aus JSON (.json) oder YAML (.yml) und speichere diese Datei im data-Ordner. Dein Objekt/Array ist dann folgendermaßen aufrufbar (gehen wir davon aus, die Datei heißt "user.json" und enthält ein Array von Objekten mit Benutzern):
<ul>
	<% data.user.each do |user| %>
		<li><%= user.name %></li>
	<% end %>
</ul>
  • Das oben gezeigte Beispiel mit der Variable title lässt sich analog dazu aufrufen, mit der Änderung, dass vor data noch ein current_page. kommt, da sich die Variable ja in derselben Datei befindet.
(c) 2015 – 2017 Boypoint.de IMPRESSUM