Mit ein paar Tricks und einer handvoll Wissen wir dieses Zusammenspiel ein Hort der Freude! Dieser Artikel beschreibt das Zusammenspiel zwischen Versionsverwaltung und Framework.

Das Repository

Auf unserem Entwicklungsserver liegt das zentrale Coderepository. Hier wird es zum Projektstart angelegt und jeder beteiligte Entwickler kriegt bei bedarf Zugriff darauf. Zum starten wird nur eine leere Datei versionisiert, der Projektleiter legt dann alle benötigten Grundlagen von seinem Rechner aus an.

# Auf dem Server

$ mkdir PROJEKT.git

$ cd PROJEKT.git

$ touch init.txt

$ git init

$ git add .

$ git commit -m "Init"

Auf dem eigenen Rechner wird vom Projekt (eventuell per VPN von zuhause) eine Arbeitskopie erstellt.

# Zuhause

$ cd Ordner_fuer_alle_Projekte

$ git clone gitosis@SERVER:git/PROJEKT.git

Beim clonen legt git einen neuen Ordner mit dem Namen des Projektes an.

CakePHP

Im ersten Schritt werden alle Cake Dateien in den Ordner kopiert. Anschließend werden die benötigten Tabellen in der Datenbank angelegt. Über die Cake Console werden dann alle benötigten Dateien gebacken.

$ cd cake/console/

$ ./cake bake

Jetzt kommt der Trick! Um in Zukunft jeden Stress mit der Datenbank zu vermeiden, backt man das Datenbankschema mit in die Cake Applikation.

$ ./cake schema generate

Mit diesem Befehl liest Cake die Datenbank aus und legt die Struktur in der PHP Datei unter /config/schema/schema.php ab. Ändert ein Entwickler eine Tabelle auf seinem Rechner, muss er das Schema neu erstellen und in Git bekannt machen.

$ ./cake schema generate

$ cd ../..

$ git add .

$ git commit -m "Einiges ist passiert, inkl. neuer Datenbank"

Der Kollege oder alternativ der gleiche Entwickler zuhause holt sich die neuste Version vom Server und aktualisert mit Cake Magie seine Datenbank.

$ git pull

$ cd cake/console

$ ./cake schema update

Fertig ist die Datenbank!

Dateien ignorieren

Beim initialen anlegen macht es Sinn, Git einige Dateien und Ordner zu entziehen, die nicht versioniert werden müssen, da sie bei jedem Entwickler individuell vorhanden sind. Dafür legt man im Root Verzeichnis vom Projekt eine Datei Names .gitignore an.

Hier werden Dateien und Ordner festgehalten, die nicht eingebunden werden:

app/tmp/

config/database.php

Cache Dateien anlegen

Das Problem ist bei der oben verwendeten .gitignore Datei, dass die Caches leer sind und keine Zugriffsrechte darauf bestehen. Deshalb muss man beim erstellen des Projekts die nötigen Ordner anlegen und die entprechenden Zugriffsrechte vergeben.

# cd app/

# mkdir tmp

# mkdir tmp/cache/

# mkdir tmp/cache/models/

# mkdir tmp/cache/persistent/

# sudo chmod -R 777 tmp/

Nach dem das Administratorpasswort eingegeben wurde, wird eine sehr freundliche Berechtigung gesetzt (die zum testen okay ist, auf dem Liveserver aber tabu!) und Cake kann in die Order schreibenn. Da der Ordner aus der Versionisierung ausgeschlossen wurde, muss man diesen Schritt zum Glück nur ein einziges mal durchführen.

Die Datenbank

Weil ein frisch geclontes Cake Projekt noch keine Datenbankverbindung besitzt, muss man als erstes eine neue Datenbank über phpMyAdmin o.ä. erstellen. Anschließend wechselt man in die Konsole und erstellt anhand des Schemas alle benötigten Tabellen.

$ cd cake/console

$ ./cake bake

Da keine Datenbankverbindung besteht, werden die Zugangsdaten abgefragt. Anschließend

$ ./cake schema create

Jetzt noch die zwei Fragen mit y bestätigen und schon liegen alle Tabellen ordentlich in der frisch angelegten Datenbank.

Fazit

Was benutzt ihr um Demoinhalte zu übertragen? Im Schema gibt es zwei Callbacks: before() und after(); ich fürchte die werden beim neugenerieren überschrieben.

Ansonsten bleibt nur noch frohes Entwickeln zu wünschen übrig. Frohes entwickeln!

Super wichtig bleibt es natürlich auch, wenn man es nicht benutzt, deshalb möchte ich hier eine Idee einbringen, um sich selbst zu zwingen damit zu arbeiten und sogar noch etwas davon zu haben!

Es geht um ein leeres Projekt (HTML, CSS, JavaScript) in dem neue Sachen schnell, lokal getestet werden können. Bisher hatte ich einfach eine index.html die ich alle paar Wochen gelöscht und neugeschrieben habe. Uncool!

Es geht viel besser, bequemer und zukunftsweisender mit Hilfe von Git! Und dieser Artikel zeigt eine Möglichkeit.

Ein leeres Projekt

Jeder Webentwickler wird wahrscheinlich seine eigenen Vorstellungen von einem leeren Projekt haben. Bei mir besteht es aus einer index.html, einem Ordner für Javascript und einem für CSS. Eine einfache style.css ist eingebunden und gibt dem ganzen ein nettes aussehen, ein paar Listen und Divcontainer und natürlich eine aktuelle jQuery Version sind eingebunden.

Testen, funktioniert, in einem Ordner zur Verfügung stellen (z.B. http://localhost/test/) und los gehts.

Ein Git Projekt initialisieren

Wie man Git unter OSX installiert, habe ich schon beschrieben. Für Windows gibt es sicher die eine oder andere gute Anleitung im Netz. Durchhalten! Nach der Installation ist der Umgang mit Git kinderleicht.

Undzwar über das Terminal. Mit dem Befehl cd wechselt man in den Ordner in dem das Testprojekt liegt:

cd Projekte/test/

Anschließend wird ein leeres Repositorie im Ordner erstellt, in dem man sich befindet:

git init

Wenn das Projekt leer und gut aussieht, dann wird es als erste Version ins Repositorie geschrieben. Dazu reicht eine Zeile:

git commit -a -m "Das leere Testprojekt"

Der Befehlt commit wird mit zwei Parametern aufgerufen: das -a zeigt an, dass alle Dateien und Ordner ins Repositorie aufgenommen werden sollen. Alternativ wäre die komplette Auswahl mit git add . oder statt dem Punkt einzelne Dateinamen.

Das -m und die folgende "Nachricht" wird zu dem Commit gespeichert und ist sehr praktisch.

Angucken, was im Repositorie gespeichert ist kann man sich auch ganz einfach:

git log

Sachen testen!

Das war es fürs Erste. Ein guter Zeitpunkt den Feedreader zu starten, den Twitterstream durchzuschauen und eine interessante Technik zu entdecken, welche man gerne ausprobieren möchte. Zum Beispiel die großartigen, neuen Module der neuen jQuery UI Version 1.8.

Im Testprojekt können jetzt alle Dateien gelöscht, hinzugefügt und verändert werden. Dein Platz zum austoben!

Testergebnisse speichern

Und jetzt wirds spaßig! Nehmen wir an, mitten im Testen der neuen Plugins kommt eine neue Twitternachricht an und verspricht eine noch tollere Technik, die wir auch ausprobieren müssen.

Also wird ein neuer Ast (Branch) in Git angelegt, der die UI Tests beinhaltet:

git branch "jQueryUI"

Wenn man den Namen weglässt (git branch) dann gibt git eine Übersicht über alle Branches aus. Der Branch der mit einem Sternchen gekennzeichnet ist, ist der in dem wir uns gerade befinden. Das sollte der neu angelegte sein.

Anschließend wird der aktuelle Zwischenstand ins Repositorie geschrieben:

git commit -a -m "jQuery UI 1.8 zickt noch ein bisschen rum"

Gespeichert!

Zurück zum leeren Testprojekt

Hier wirds jetzt spannend!

git checkout master

Mit diesem einfachen Befehl haben wir unser leeres Testprojekt zurück! Diese Anweisung überschreibt alle Daten in dem entsprechenden Verzeichnis. Möchte man die Ergebnisse behalten, sollte man diese in einem Branch speichern, damit der Master-Branch immer das leere Testprojekt enthält.

Weiterentwicklen

Das schöne ist, dass der Master sich weiterentwickeln kann. Soll jQuery UI also immer dabei sein (dann aber die stabile Version), dann muss sie nur im Testprojekt hinzugefügt werden und in Git bekannt gemacht werden (sofern wir uns im Master-Branch befinden):

git commit -a -m "Leeres Projekt mit jQuery UI"

Damit verliert man den alten Stand des Testprojekts nicht! Wenn man die alte Version wieder braucht, holt man sich die mit Hilfe des Dachs ^ aus dem Repositorie zurück:

git checkout master^

Die vorletzte Version gibts mit master^^ usw.

Fazit

Softwareversionisierung ist eine großartige Sache und sich damit zu beschäftigen erleichtert nicht nur die einsame Arbeit am eigenen Computer, sondern ermöglicht überhaupt erst eine effektive Zusammenarbeit im Team.

Ich kann also nur jedem wärmstens empfehlen mit kleinen, lokalen Projekten zu beginnen und dran zu bleiben. Demnächst kommen hoffentlich die nächsten Anleitungen. Stoff genug gibts ja.

Bis dahin wünsche ich frohes versionisieren!

• es muss sehr schnell sein, um mit der großen Code-Masse klarzukommen
• nicht jeder darf Patches integrieren, sie müssen vorher durch einen Maintainer kontrolliert werden
• das System muss dezentral arbeiten, um einerseits Bandbreite und Performance zu sparen und damit andererseits nicht bei einem Ausfall die ganze Entwicklung still steht

(Quelle: Online-Tutorials.de)

Nun stellt sich natürlich die Frage wie Git mit Mac OS X zusammenarbeitet, wie man es installiert und seine Projekte in ein Repository packt. Dieser Artikel will das verständlich, kurz und auf deutsch erklären.

Mein Anforderungen

Ich habe einen riesigen Haufen Projekte in einem riesigen Haufen Ordner. Jetzt liegt in einem Projektordner die Korrespondenz, angelieferte Daten und Informationen, sowie ein Ordner mit allen FTP Dateien die ich bearbeite, auf dem lokalen Server betrachte und bei bedarf komplett hochschiebe.

Auf meinem Rechner soll jetzt ein Git Repository entstehen um Änderungen nachvollziehen zu können, die Daten zu sichern und im Notfall alte Versionen wiederherstellen zu können.

Git unter Mac OS X Leopard installieren

Ehrlich gesagt bin ich kein Freund des Terminals, es macht zwar Spaß wenn man es kann, aber bis dahin ist es mühsam. Ich habe auch keine große Lust XCode zu installieren um MacPorts nutzen zu können um alles zu installieren, deshalb bin ich sehr froh einen automatischen Installer für OS X 10.5 gefunden zu haben. Also: Git installieren wie ein ganz normales Programm!

Funktioniert wunderbar. Um es zu testen muss man dann doch ins Terminal wechseln und den Befehl "git" eingeben. Darauf erhält man eine Liste der wichtigsten Befehle:

The most commonly used git commands are:

add        Add file contents to the index

bisect     Find by binary search the change that introduced a bug

branch     List, create, or delete branches

checkout   Checkout a branch or paths to the working tree

clone      Clone a repository into a new directory

commit     Record changes to the repository

diff       Show changes between commits, commit and working tree, etc

fetch      Download objects and refs from another repository

grep       Print lines matching a pattern

init       Create an empty git repository or reinitialize an existing one

log        Show commit logs

merge      Join two or more development histories together

mv         Move or rename a file, a directory, or a symlink

pull       Fetch from and merge with another repository or a local branch

push       Update remote refs along with associated objects

rebase     Forward-port local commits to the updated upstream head

reset      Reset current HEAD to the specified state

rm         Remove files from the working tree and from the index

show       Show various types of objects

status     Show the working tree status

tag        Create, list, delete or verify a tag object signed with GPG

See 'git help COMMAND' for more information on a specific command.

Dieser Befehl git help COMMAND ist ganz praktisch. Navigieren lässt sich mit den Pfeiltasten, zurück zur Eingabe gelangt man mit [q].

Mein erstes Git Repository

Damit Git einen Namen und Benutzer hat, macht es Sinn sich dem System zu erkennen zu geben. Das passiert im Terminal mit Hilfe von

git config --global user.name "Mein Name"

git config --global user.email email@adresse.hier

Für ein Projekt erstellt man jetzt ein Repository. Um nichts kaputt zu machen erstmal mit einem Testprojekt. Meins liegt in /Projekte/Server/Git. In diesen Ordner muss mit dem Befehl cd im Terminal gewechselt werden:

cd /Projekte/Server/Git

Wenn das geklappt hat (überprüfen mit dem Befehl ls - der zeigt alle Dateien die der Ordner beinhaltet), kommt der große Moment: Git wird initialisiert!

git init

Wie Sie sehen, sehen Sie nichts. Aber das trügt! Es wurde ein versteckter Ordner angelegt. Um die Inhalte anzusehen wird wieder in den Finder gewechselt, der entsprechende (leere) Ordner ausgewählt und mit der Tastenkombination [cmd] + [umschalt] + [g] der Dialog zum Ordner öffnen ausgewählt. Hier wird ".git" eingetragen, mit [enter] bestätigt und schon kann man sich die verteckten Inhalte ansehen.

Dateien hinzufügen

Um Dateien von Git verwalten zu lassen müssen sie als erstes in Git bekannt gemacht werden. Das ist der sogenannte "Index". Dateien fügt man diesem Index mit dem Befehl git add . hinzu. Der Punkt gibt an das alle Dateien in dem betreffenden Ordner hinzugefügt werden sollen.

Man befindet sich also im Terminal, immer noch im Projektordner, und fügt alle Dateien dem Index hinzu:

git add .

Als nächstes wird der Index ins Repository geladen. Das passiert über den Befehl commit.

git commit

Dieser Befehl öffnet einen Texteditor in dem man seinen Commit kurz beschreiben sollte (was ist passiert, was wurde geändert, usw.). Das geschieht über den Texteditor Vi. Für ungeübte "etwas" gewöhnungsbedürftig, aber so funktionierts:

1. Über die Taste [i] den "Insert"-Modus starten und die Nachricht eingeben.
2. Mit [esc] den Modus wieder verlassen.
3. Den Befehlsmodus mit [:] (Doppelpunkt) starten, [wq] eingeben und mit [enter] bestätigen - das schreibt die Datei und beendet den Editor (w = write, q = quit).

Das war ein bisschen anstrengend, aber man gewöhnt sich dran. Git müsste jetzt eine Meldung anzeigen das alles geklappt hat, wieviele Dateien aufgenommen wurden usw.

Weitere Dateien hinzufügen

Im Repository ist jetzt also eine Kopie vom gesamten Projekt gespeichert. Jetzt beginnt der Arbeitstag und man macht großartige Dinge. Wenn man das Gefühl hat den aktuellen Zwischenstand speichern zu wollen, wechselt man wieder ins Terminal, in den entsprechenden Ordner und "commited" die gemachten Änderungen.

git commit -a

Das -a am Ende fügt alle Dateien automatisch dem Index hinzu und publiziert die Änderungen.

Änderungen betrachten und wiederherstellen

Zu jedem Zeitpunkt kann man sich über git log den Status des Repositorys ansehen. Das listet alle Commits auf. Um genau zu sehen was sich geändert hat, wird der Befehl mit dem Parameter -p erweitert:

git log -p

An den Plus- und Minuszeichen kann man jetzt erkennen welche Zeilen geändert und welche hinzugefügt wurden. Über [q] verlässt man den Quelltextmodus.

Und jetzt wird es richtig spannend. Wenn eine Änderung nicht gelappt hat und die letzte Version wiederhergestellt werden soll, dann passiert das mit checkout.

git checkout master^

master gibt den sog. "Branch" / Ast an aus dem exportiert werden soll, "master" ist der Standardast der automatisch angelegt wird. Das Dach ^ gibt an das die letzte Version wiederhergestellt wird. Zwei Dächer (^^) zeigen dann auf die vorletzte usw.

Wird dieser Befehl ausgeführt werden alle Dateien im Ordner durch jene aus dem Repository ersetzt. Um wieder die aktuellste Version zu erhalten führt man den gleichen Befehl aus, allerdings ohne das Dach.

Fazit und Ausblick

Vielleicht klingt es für dein einen oder anderen nicht besonders Revolutionär und ehr unpraktisch mit dem Terminal usw., ich empfehle aber dringend sich damit auseinander zu setzen!

Die hier vorgestellten Grundlagen sind nur die Spitze des Eisbergs, Git bietet unglaublich viele Möglichkeiten, insbesondere bei der Zusammenarbeit mit anderen Programmierern. Es lassen sich verschiedene Versionen und Zweige definieren und richtig mächtig wird es wenn auf dem Server ein eigenes Repository läuft, als Backup und zur direkten Veröffentlichung.

Es lassen sich auch verschiedene Hooks einbauen, kleine Scripte die z.B. ein Copyright in die Datei einfügen oder Bedingungen prüfen, beim einchecken und auschecken uvm.

Das nächste Tutorial folgt dann hier im Blog. Wer es nicht mehr aushält, dem sein folgende Links ans Herz gelegt.

Weiterlesen

• Ein guter Einstieg auf Deutsch bei den Online-Tutorials.
• Das "offizielle" Getting Started Tutorial von den Machern (en).
• "A web-focused Git Workflow" von Joe Maller (en).
• Sehr ausführliche Anleitung inkl. Tipps und Tricks (en).
• Every Day Git beschreibt wichtige Arbeitsabläufe (en).
• Und natürlich die offizielle Git Homepage (en).
• Zweiter Arikel über Git in Pauls Blog: Ein sauberes Testprojekt mit Git.

Wie gesagt, hier im Blog geht es demnächst auch weiter. Über Hinweise und Korrekturen freue ich mich natürlich sehr, dass war mein erstes mal mit Git. Aber ich denke wir werden eine tolle Zeit miteinander haben und irgendwann mehr als Freunde sein!